[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42844 ]
Eugene Kuleshov commented on MNG-521:
-------------------------------------
Just for the record. Above structure for EAR module is not flexible. I actually
ended up with multiple ears on a same project, they may include different
modules, depends in the need. For example:
Project
|-pom.xml
|- App EAR
| |- pom.xml
|- Int Testing/Cactus EAR
| |- pom.xml
|-WAR1
| |- pom.xml
|- WAR2
| |-pom.xml
|- EJB
|- pom.xml
The major difference is that root project doesn't build/deploy/publish anything
except its own pom.xml
It is also possible that paren pom also inherited, so resolving should work all
the way up to root and should not be limeted to one level of hierarchy. If I'm
not mistaken I've seen such project hierarchy in Geronimo or ActiveMQ.
I regards to 3rd note. I think that you should be resolve dependencies just by
their names and no need to specify relative path. So, it should be possible to
scan local project structure (in assumption that entrire project is avaliable
locally) and collect all locally available artifacts.
Also, it would be nice if m2 would fall down to repository if it can resolve
dependencies locally (e.g. if project is not comletely present locally), but
maybe you can just disable release goal in this case.
> Version inheritance from the parent pom
> ---------------------------------------
>
> Key: MNG-521
> URL: http://jira.codehaus.org/browse/MNG-521
> Project: Maven 2
> Type: Improvement
> Components: design
> Reporter: Eugene Kuleshov
> Assignee: John Casey
> Fix For: 2.0-beta-1
>
>
> Currently m2 pom require to have explicit version of the parent pom in all
> submodules. This should work fine for "standalone" artifacts. However there
> is different type of projects (e.g. EAR) that is usually stored in version
> control as a whole thing and may contain multiple modules (ejb jars, rar,
> war, etc) that are build with the same version as entire EAR. So, EAR
> application released with a single global version for all submodules. In m1
> this was possible to specify relative path to parent pom and use version
> substitution in child modules and deployer goal was substituting values for
> version numbers upon deployment.
> For this kind of modules it is very important to have single palce that will
> have global version number, which then used for submodules. It is also make
> sense to kee optional relative path (that can be also removed/replaced with
> concrete parent id/version upon deployment) to support local build. I believe
> this is very important for J2EE builds as well as any other projects that are
> releasing multiple artifacts/jars under the same version (e.g. ASM, XDoclet).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
