You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Bill Dudney <bd...@apache.org> on 2006/07/21 14:08:14 UTC
[m2] directory structure
HI All,
Part 2 of the Maven 2 move discussion...
We have 5 logical repositories
examples - what you'd expect
main - where just about everything lives
sandbox - future stuff, experiments
site - static docs and java doc (why are the java doc's checked in?)
soc - eclipse plugin(s)
In main we need to add a top level pom
groupId - org.apache.cayenne
arifactId - cayenne-parent
This pom will contain all the 'over all' info like mailing list info,
license info, repositories etc.
I'd like to leave site for later as I'm not quite as sure what to do
there and it will take a bit of playing around with to get it right
but essentially I'd like to remove the javadoc and other generated
content, keep only the unique content and have it generate the 'root'
site with the rest of the subprojects hanging off that root.
I will also send main out in another email as this one is already too
long...
examples;
1) add a pom to the root of the examples tree
parent - org.apache.cayenne:cayenne-parent
groupId - org.apache.cayenne.examples
artifactId - examples-parent
2) each example gets its own artifactId but shares the groupId with
examples-parent
3) directory changes - lots to do here
3t-example - change to reflect the maven layout for web applications
(src/main/java, src/main/webapp, etc)
3t-example-client - add main/java to the src dir and move all the
code under that
cayenne-jpa-annotations-example - already an m2 layout, just update
the pom
cayenne-petstore - web layout, remove the dependencies and the
generated war
cross-db-example - move source and resources for m2 layout - make a
manifest so this can be run with java -jar
generic-mapping-example - move source and resources - make a
manifest so this can be run with java -jar
The examples all have Eclipse .project & .classpath files checked
in. We can get rid of that after we finish the move to maven.
I think examples is the place to start so we can get our feet wet but
not impact too much. If everyone is in agreement I'll get started
later today.
sandbox;
1) add a pom
parent - org.apache.cayenne:cayenne-parent
groupId - org.apache.cayenne.sandbox
artifactId - sandbox-parent
2) each module gets its own artifactId sharing the parent groupId
3) derby-pool gets lib removed and src moved to reflect maven 2 layout
soc;
1) add a pom
parent - org.apache.cayenne:cayenne-parent
groupId - org.apache.cayenne.soc
artifactId - soc-parent
of the 3 modules in here only cayenne-rop seems to have anything in it.
2) each module again shares the groupId and has its own artifactId
3) directory changes -
from what I can tell based on what is there we can drop the rob-
browser directory and move everything in there up one level to
cayenne-rop.
a) remove lib, dist, .classpath, .project, .settings
b) move META-INF, icons, and cayenne to the src/main/resources
directory
c) move the src/org director to src/main/java
I've not used m2 for an eclipse plugin but from what I have Geronimo
has so I'll check with them to make sure this is all a good thing
before moving the stuff around.
That is all for now.
TTFN,
-bd-
Re: [m2] directory structure
Posted by Mike Kienenberger <mk...@gmail.com>.
> On Jul 21, 2006, at 8:08 AM, Bill Dudney wrote:
> > a) remove lib, dist, .classpath, .project, .settings
On 7/21/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> BTW, the .settings dir contains lots of nice things for Eclipse, such
> as code formatting "standard" for Cayenne, the new class templates
> with Apache license headers, etc. It would be nice to preserve it.
> Also I don't see any harm in Eclipse project files.
>
> What's considered to be the "best practices" when working with
> Eclipse and Maven.
In theory, Maven can recreate .project and .classpath with "maven
eclipse:eclipse"
In practice it doesn't always work out this nicely -- MyFaces is an
example of that, although maybe it's just a misconfiguration issue in
maven.
Maven is not going to provide useful things like .setting. I
wouldn't get rid of these.
Re: [m2] directory structure
Posted by Andrus Adamchik <an...@objectstyle.org>.
I am using the same procedure. It works fairly well. The best part
(compared to Ant) is that both command-line Maven and Eclipse work
off of the same descriptor (pom.xml). At times the plugin gets
confused after command line changes to the local repository, but
source refresh and full workspace rebuild fix most issues.
Andrus
On Jul 21, 2006, at 11:59 AM, Bill Dudney wrote:
> The M2 plugin for eclipse is cool and works fairly well. There is
> an incompatibility between mvn eclipse:eclipse and the plugin. When
> you do mvn eclipse:eclipse it fills the .classpath with references
> to M2_REPO/foo.jar but the plugin knows and understands your
> pom.xml file so all that is not needed. The way I manage it is to
> mvn eclipse:eclipse then delete all the M2_REPO stuff then add the
> M2 Library. Tedious until the plugin is updated (for all I know it
> already is, I'm just to lazy to figure out how to fix it so if
> anyone knows please let me know) but it works. And once you get the
> setup done the plugin is really cool allowing you to add and manage
> your dependencies etc.
>
> http://m2eclipse.codehaus.org/
>
> is the update site for the eclipse plugin.
Re: [m2] directory structure
Posted by Andrus Adamchik <an...@objectstyle.org>.
> However, I don't think they have to remain in a directory named
> .settings, do they?
I think this is an Eclipse naming convention, so it has to be .settings.
> And even if they do, we can always go back to
> our original process where we kept these in a contrib/eclipse
> directory.
True. I'd say keep .classpath, .project and .settings in each project
root directory until it cases a problem to somebody. This allows to
quickly restore the workspace from scratch, so it is about
productivity and consistency.
Andrus
On Jul 21, 2006, at 12:03 PM, Mike Kienenberger wrote:
> On 7/21/06, Bill Dudney <bd...@mac.com> wrote:
>> I'd prefer to keep the .settings stuff on the wiki as exported xml
>> files. Anyone using Eclipse could then import the xml files.
>>
>> But I'm open to keeping the .settings file around, only problem
>> would be if NetBeans or whatever decided they also used the same
>> name directory and we had a conflict.
>
> No, I'd rather see these in the repository.
>
> However, I don't think they have to remain in a directory named
> .settings, do they? And even if they do, we can always go back to
> our original process where we kept these in a contrib/eclipse
> directory.
>
Re: [m2] directory structure
Posted by Mike Kienenberger <mk...@gmail.com>.
On 7/21/06, Bill Dudney <bd...@mac.com> wrote:
> I'd prefer to keep the .settings stuff on the wiki as exported xml files. Anyone using Eclipse could then import the xml files.
>
> But I'm open to keeping the .settings file around, only problem would be if NetBeans or whatever decided they also used the same name directory and we had a conflict.
No, I'd rather see these in the repository.
However, I don't think they have to remain in a directory named
.settings, do they? And even if they do, we can always go back to
our original process where we kept these in a contrib/eclipse
directory.
Re: [m2] directory structure
Posted by Bill Dudney <bd...@mac.com>.
I'd prefer to keep the .settings stuff on the wiki as exported xml files. Anyone using Eclipse could then import the xml files.
But I'm open to keeping the .settings file around, only problem would be if NetBeans or whatever decided they also used the same name directory and we had a conflict.
Either way is fine with me.
Not sure what best practice (or that there even is a set yet :-)
The M2 plugin for eclipse is cool and works fairly well. There is an incompatibility between mvn eclipse:eclipse and the plugin. When you do mvn eclipse:eclipse it fills the .classpath with references to M2_REPO/foo.jar but the plugin knows and understands your pom.xml file so all that is not needed. The way I manage it is to mvn eclipse:eclipse then delete all the M2_REPO stuff then add the M2 Library. Tedious until the plugin is updated (for all I know it already is, I'm just to lazy to figure out how to fix it so if anyone knows please let me know) but it works. And once you get the setup done the plugin is really cool allowing you to add and manage your dependencies etc.
http://m2eclipse.codehaus.org/
is the update site for the eclipse plugin.
TTFN,
-bd-
On Friday, July 21, 2006, at 11:22AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
>On Jul 21, 2006, at 8:08 AM, Bill Dudney wrote:
>
>> a) remove lib, dist, .classpath, .project, .settings
>
>BTW, the .settings dir contains lots of nice things for Eclipse, such
>as code formatting "standard" for Cayenne, the new class templates
>with Apache license headers, etc. It would be nice to preserve it.
>Also I don't see any harm in Eclipse project files.
>
>What's considered to be the "best practices" when working with
>Eclipse and Maven.
>
>Andrus
>
>
>
Re: [m2] directory structure
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jul 21, 2006, at 8:08 AM, Bill Dudney wrote:
> a) remove lib, dist, .classpath, .project, .settings
BTW, the .settings dir contains lots of nice things for Eclipse, such
as code formatting "standard" for Cayenne, the new class templates
with Apache license headers, etc. It would be nice to preserve it.
Also I don't see any harm in Eclipse project files.
What's considered to be the "best practices" when working with
Eclipse and Maven.
Andrus
Re: [m2] directory structure
Posted by Andrus Adamchik <an...@objectstyle.org>.
Some general notes on the top-level stuff. I suggest we ignore
sandbox and soc directories for the purpose of the Maven conversion.
I'd like to keep "sandbox" free-form, so that committers could check
in whatever they want in there. It should not be a part of any
automated build either. "soc" is a sandbox for the Google Summer of
Code projects, so it also doesn't fit into the Maven tree.
> site - static docs and java doc (why are the java doc's checked in?)
We had ant-based automation for javadocs generation in the past.
Since the build systems (and repositories) across 1.0/1.1/1.2/3.0 are
incompatible, I ended up checking in the static docs to avoid cross-
version build nightmare. Once we start talking about migrating the
site to Maven (it will be migrated later per your comment), let's re-
think it.
> In main we need to add a top level pom
>
> groupId - org.apache.cayenne
> arifactId - cayenne-parent
+1
see cayenne/cayenne-ant/maven/ directory for templates with general
info. But are probably past that point already.
> examples;
>
> 1) add a pom to the root of the examples tree
>
> parent - org.apache.cayenne:cayenne-parent
> groupId - org.apache.cayenne.examples
> artifactId - examples-parent
>
> 2) each example gets its own artifactId but shares the groupId with
> examples-parent
>
> 3) directory changes - lots to do here
> 3t-example - change to reflect the maven layout for web
> applications (src/main/java, src/main/webapp, etc)
> 3t-example-client - add main/java to the src dir and move all the
> code under that
> cayenne-jpa-annotations-example - already an m2 layout, just
> update the pom
> cayenne-petstore - web layout, remove the dependencies and the
> generated war
> cross-db-example - move source and resources for m2 layout - make
> a manifest so this can be run with java -jar
> generic-mapping-example - move source and resources - make a
> manifest so this can be run with java -jar
>
> The examples all have Eclipse .project & .classpath files checked
> in. We can get rid of that after we finish the move to maven.
> I think examples is the place to start so we can get our feet wet
> but not impact too much. If everyone is in agreement I'll get
> started later today.
+1.
> sandbox;
> ....
> soc;
> ...
See my comment above - I suggest that we leave them out.
Andrus