[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42839 ]
John Casey commented on MNG-521:
--------------------------------
I'm starting design work for this one, and I'd like to put forth the things I
can remember from the meeting after JavaOne (brett, jason) and have people
(anyone) comment on the viability/correctness of my approach. This is going to
have to happen kind of fast in order to keep it from monopolizing the -beta-1
release, but we need to get this straight...
NOTE: This is just a first-pass, from some notes I've been working on this
morning. I'm not going to start implementation until we hash some of this out
better...
======================================================
As a starting use case, I've chosen to look at an EAR file:
* EAR
|- pom.xml
|-WAR1
| |- pom.xml
|- WAR2
| |-pom.xml
|- EJB
|- pom.xml
Goal: Maintain application version information in only one place.
Requirements
----------------------------
* The parent pom (EAR/pom.xml) should specify the application's version
* The WARs and EJB should be 'slave' projects, in that their versions ALWAYS
match that of EAR/pom.xml
* WARs and EJB projects CANNOT be built from a filesystem location external to
the entire EAR source directory
Implementation Notes
-----------------------------
1. Child pom (WARs, EJB) will specify a parent WITHOUT a version
2. Child pom WILL NOT specify a version for themselves (this version is
provided by the parent)
3. It is assumed that the child's parent-pom will live in the parent directory
(parent-pom == ../pom.xml) (see questions/notes below)
4. If #'s 1, 2 hold, and ../pom.xml is non-existent or doesn't match the parent
specification, throw an exception and stop the build.
Questions/Notes
------------------------------
* Resolving RELEASE in the absence of ../pom.xml has been discussed. I think
this is dangerous, particularly since the parent-pom can specify dependencies
for use in the build. Using RELEASE when there is a newer but unreleased
parent-pom in SCM will lead to inconsistent builds (build-in-context vs.
build-in-isolation). It would be much more consistent to require the whole
project hierarchy to be in the work directory in these cases. In this case,
versioning information becomes non-deterministic, particularly when the child
pom.xml doesn't provide a version. This inconsistency will be a problem for
development teams.
* ../pom.xml doesn't really work in a reactor situation, I don't think...we'll
have to add some sort of logic to either (a) resolve from ../pom.xml or (b)
resolve from cache, but NEVER resolve from repository in these cases.
* how do we handle non-nested lineages? Do we need something like <path/> in
the parent specification, and if so, do we enforce relative pathing on that
element to guard against projects that depend on filesystem attributes external
to the project directory? Even if we do enforce relative pathing, we cannot
easily guard against
../../../../../../../../../../libraries-on-CD/something/pom.xml. I'M AGAINST
SUPPORTING NON-NESTED HIERARCHIES IN THIS SCENARIO.
> 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]
