Kaiser, Hans wrote:
workspace
|-- my-app (is also the CVS-module)
|-- presentation
|-- common
|-- web
|-- pom.xml (the master pom)
Eclipse does not support nested projects, so that structure won't work
(or at least won't work well in an Eclipse-friendly way). It is best to
have a separate Eclipse project for each module. And by "best", I mean
it is the only sane choice, even though this Eclipse limitation drives
me mad. :-)
To be able to edit the top-level pom.xml, you must move it into another
"peer module". Let's call it "master". You will need to adjust the paths
to the modules in the master pom. "presentation" will change to
"../presentation", etc.
my-app
|-- presentation
|-- common
|-- web
|-- master (the master pom.xml is in this directory)
Then setup an Eclipse workspace, and checkout the presentation, common,
web, and master modules as Eclipse projects. Done.
Personally, I prefer to checkout the project from the root (my-app)
outside of Eclipse, and create an Eclipse workspace that DOES NOT
overlap my project working directories. Then I create a new Eclipse
project for each module by pointing Eclipse to the existing directories
in the my-app working directory tree. I use a bunch of different tools
when working on projects, so I don't want the working files to be
"owned" by Eclipse (and stashed away in a workspace somewhere). This
arrangement also allows you to commit changes to more than one module in
the same transaction, though you have to use something other than
Eclipse to do the commit. And you could even keep the pom.xml file at
the top level and avoid creating the master directory -- however, in
doing so you lose the ability to edit the pom.xml in Eclipse, so I still
use the "master" directory technique anyway.
-Max
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
