If it helps matters, here is what I'm currently considering as a
compromise between the two approaches (flat vs. hierarchical). This is
for a source tree that will contain, as an example, all of the "web"
related ears in the system; in a full use, we might expect to see an
expansion of directories at the top level to cover other systems.
.
|-- global-build-config
| `-- pom.xml
+-- web
| |-- web-build-config
| | `-- pom.xml
| +-- ac
| | |-- ac-build-config
| | | `-- pom.xml
| | |-- ac-domain
| | | |-- pom.xml
| | | `-- src
| | | |-- main
| | | `-- test
| | |-- ac-ear
| | | `-- pom.xml
| | |-- ac-par
| | | `-- pom.xml
| | `-- ac-war
| | |-- pom.xml
| | `-- src
| | `-- main
| | |-- resources
| | `-- webapp
| +-- ecomm
| | |-- ...
| +-- mail
| |-- ...
`-- ...
At each level I create a self-contained project that I can load into
eclipse that contains only a POM; this is equivalent to putting the pom
directly in the levels' directory, but allows me to manipulate it
without having a tree of all children open in Eclipse (meaning I can
work independently on any project at any level). The only time this
rule is breached is at the leaves, where mvn is much happier if the POM
is colocated (I don't want to have to specify where the POM is every time).
Each directory under "web", except for the web-build-config directory,
is an EAR project (though other project types would be quite acceptible
too). These then break down into a build-config for that project and
the separate components that will be assembled into a final EAR.
Reasons I like this structure:
- almost as simple as a pure hierarchy for understanding where POMs will
come into a build from
- organizes related artifacts together neatly
- doesn't require dummy projects: everything can be a true project in
Eclipse
- expands cleanly to arbitrary depth
Reasons I don't like this structure:
- doesn't really solve the source management problem of potentially
wanting to commit something atomically across project boundaries (though
Eclipse seems to handle this better than I previously thought)
- still suffers the problem of not having automatic .project generation
for pom-only artifacts (though this could readily be fixed with some
tweaking of maven-eclipse-plugin).
Thoughts?
Cheers,
Chris
Srepfler Srgjan wrote:
These are really good remarks and it reflects the show-stopper that we
received after we realized there is slim chance on sharing our ear
application modules between maven 2 and eclipse's WTP.
I think more discussion on this subject could be useful and some help on
how to manage code base between the environments and hints on how do
maven/eclipse developers might evolve their environments would be useful.
Chris Tucker wrote:
Hi,
The page http://maven.apache.org/guides/mini/guide-ide-eclipse.html
explains how to use Eclipse with a multi-module Maven2 project.
Specifically, it gives instructions to "handle maven multiple module
projects with eclipse while keeping the recommended hierachical
project layout.". I'd be interested to hear why the hierarchical
project layout is preferred. So far, I can see the following pros and
cons:
1) The hierarchical structure is more natural: it's not necessary for
users to dig around in POMs to see what other POMs are likely to play
a part in the build.
2) The hierarchy nicely deals with organizing a set of artifacts that
combine to produce another (e.g. for organizing the war/jar/par/ejb3
modules that make up an ear in a EE 5 app)
3) As a corollary to (2) you can create changesets against a tree
spanning multiple projects in Eclipse where appropriate (as it can be
in, for example, an EAR project). With a flat structure, this is much
more cumbersome.
4) The hierarchy does not map cleanly into Eclipse: if the hierarchy
gets deep, you end up with lots of "dummy" directory projects that
house other projects. Eclipse isn't really aware of the relationship
between the "dummy" projects and the "real" projects, increasing the
chances of Eclipse getting confused.
5) It's a pain to set up a freshly checked out tree in the
hierarchical model: mvn eclipse:eclipse won't generate .project files
for <packaging>pom</packaging> type projects.
I'm sure there are other arguments for and against that I'm missing,
but right now I'm finding it hard to determine one as being superior
to the other: indeed, both seem to have significant downsides.
Ideally Eclipse would support a more structured project model, but it
seems unlikely that's going to happen any time soon so I'd be
interested to hear how others have solved this problem.
Cheers,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
