Re: [Springframework-developer] adding eclipse files to cvs

[Rod J. <rod...@in...>]

Sounds fine to me. I considered checking in the Eclipse project file myself,
but was worried about the J2EE absolute path. You seem to know Eclipse
better than I so I'm happy with your suggestion.

Please don't use /target as the output directory. This conflicts with the
default for Maven, a build tool we may use for some tasks. No other special
requests. I don't mind /build myself.

If you want to check this in, please go for it. It's useful.

Also: can we check in excludes, formatting settings...

Regarding Eclipse or other IDEs, how about we standardize on @todo to mark
tasks in the source? Eclipse handles this very nicely.

The mo.ejb package isn't really necessary, in my opinion. I actually tried
to delete it last night. I'd be inclined to delete it rather than move it.
But moving the other mock objects makes sense.

Regards,
Rod

----- Original Message -----
From: "Trevor Cook" <tc...@in...>
To: "Spring Developers (E-mail)"
<spr...@li...>
Sent: Thursday, February 13, 2003 4:10 PM
Subject: [Springframework-developer] adding eclipse files to cvs


> I hope I'm not being too forward or aggressive in making some
> recommendations for this project.  My experience so far has mainly been
> working solo or in small teams as lead developer, so my experience with
open
> source (as a contributor) and large project management is nil.  If I'm out
> to lunch, just let me know.
>
> I think that the suggestion by "William G. Thompson, Jr." on the Wrox
board
> about adding eclipse files is a good one.  It sounds like those so far
> involved (Rod, Yann, and me - not sure what Juergen is using) are using
> eclipse, so adding the few eclipse specific files (.project and
.classpath)
> make sense to me.  I would also recommend standarizing on an eclipse
> variable for the one jar we don't distribute (j2ee) as being "J2EE_HOME".
> Finally, we would need to specify the eclipse output folder.  I prefer
> "target" and eclipse defaults to "build", but I'll use whatever the team
> decides.  To get started though, the files would be as follows (subject to
> any changes recommended by the team):
>
> .project
> <?xml version="1.0" encoding="UTF-8"?>
> <projectDescription>
> <name>springframework</name>
> <comment></comment>
> <projects>
> </projects>
> <buildSpec>
> <buildCommand>
> <name>org.eclipse.jdt.core.javabuilder</name>
> </buildCommand>
> </buildSpec>
> <natures>
> <nature>org.eclipse.jdt.core.javanature</nature>
> </natures>
> </projectDescription>
>
> .classpath
> <?xml version="1.0" encoding="UTF-8"?>
> <classpath>
>     <classpathentry kind="src" path="src"/>
>     <classpathentry kind="src" path="test"/>
>     <classpathentry kind="con"
> path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
>     <classpathentry kind="lib" path="lib/clover/clover.jar"/>
>     <classpathentry kind="lib" path="lib/easymock/easymock.jar"/>
>     <classpathentry kind="lib" path="lib/junit/junit.jar"/>
>     <classpathentry kind="lib"
> path="lib/mockobjects/mockobjects-0.07-core.jar"/>
>     <classpathentry kind="lib" path="lib/velocity/velocity-1.3.jar"/>
>     <classpathentry kind="lib" path="lib/log4j-1.2.jar"/>
>     <classpathentry kind="lib"
> path="lib/mockobjects/mockobjects-0.07-j1.3-j2ee1.3.jar"/>
>     <classpathentry kind="lib"
> path="lib/mockobjects/mockobjects-0.07-jdk1.3.jar"/>
>     <classpathentry kind="lib" path="lib/velocity/velocity-dep-1.3.jar"/>
>     <classpathentry kind="var" path="J2EE_HOME/lib/j2ee.jar"/>
>     <classpathentry kind="output" path="target"/>
> </classpath>
>
> My other suggestion is partly a question which is adding .cvsignore to
cvs.
> I'm not sure if this is normal/good practice, or just something I've been
> doing.  If we did add it, as a start it would look like:
>
> junit-reports
> .classes
> .testclasses
> spring-core-0.8.jar
> spring-ejbimpl-0.8.jar
> spring-jdbc-0.8.jar
> spring-web-0.8.jar
> target
>
> My last suggestion is actually a response to an email from Rod, which I'll
> quote here to get it out to the team.
>
> >>I'm not sure about mo.whatever: maybe com.interface21.mockobjects
> >>would be better--I didn't think very hard about the naming.
>
> I think that "com.interface21.mockobjects" makes a lot more sense. I was
> just recommending mo.xxx to try to match the mo.ejb which already existed.
> I'll use "com.interface21.mockobjects.jdbc" for the tests I'm refactoring.
> When the other tests are refactored, we should probably move mo.ejb into
an
> equivelent package, and possibly move servletapi as well (haven't looked
> closely enough at those test objects to comment).
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
>
>