[ http://jira.codehaus.org/browse/MNG-521?page=comments#action_42867 ]
Rafal Krzewski commented on MNG-521:
------------------------------------
Please keep in mind that Eclipse does not allow nesting projects. It is
possible to have a signle Eclipse project containg a whole Maven project
hierarchy with multiple Java source folders. Kind of weird and counterintuitive
to Eclipse user but works. At the same time, Eclipse WTP (Web Standard Tools)
project developers were discussing lately wether to allow multiple J2EE modules
per Eclipse project or not, and the consensus was 1 module - 1 project, along
with no project nesting principle. Therefore making nested project structure a
requirement for version inheritance would make it incompatible with WTP.
>From Eclipse perspective, the "natural" organization of project folders looks
>like that:
<workspace>
|-xyz-parent
| |-pom.xml
|-xyz-shared-jar
| |-pom.xml
|-xyz-war1
| |-pom.xml
|-xyz-war2
| |-pom.xml
|-xyz-ear
| |-pom.xml
|-xyz-reactor
|-pom.xml
If we assume that projects directory names in the workspace correspond to
project's artifactId, a project's descriptor can be reached from workspace by
following ${proj.artifactId}/pom.xml, and the workspace directory can be
reached from project's $basedir by following ${basedir}/../ path.
Consider another example: DamageControl CI system that I happen to be using
also uses a workspace abstraction. The layout looks like that:
<workspace>
|-xyz-parent
| |-checkout
| |-pom.xml
|-xyz-war1
| |-checkout
| |-pom.xml
...
In this layout workspace-to-project path is ${proj.artifactId}/checkout/pom.xml
and project-to-workspace path ${basedir}/../../ Notice that
project-to-workspace path can be easliy inferred from workspace-to-project path
by counting forward slashes in the former.
What I am proposing, is inclusion information about project descriptor location
relative to the workspace into each project's descriptor.
This way it will be possible to determine the path to the parent project's
descriptor in the local workspace in a portable way. Let me give you some
examples:
1) nested projects
<workspace>
|-EAR
|- pom.xml path=EAR/pom.xml, artifactId=EAR, currentVersion=1.0
|-WAR1
| |-pom.xml path=EAR/WAR1/pom.xml, extends=EAR
|-WAR2
| |-pom.xml path=EAR/WAR2/pom.xml, extends=EAR
|-EJB
|-pom.xml path=EAR/WAR1/pom.xml, extends=EAR
when building WAR1, basedir=<workspace>/EAR/WAR1, count / in path for WAR1,
infer workspace=${basedir}/../.., check path for WAR1 parent = EAR, infer path
to parent descriptor = ${basedir}/../../EAR/pom.xml
2) non nested-projects
<workspace>
|-xyz-parent
| |-checkout artifactId=xyz-parent, path=${pom.artifactId}/pom.xml,
currentVersion=1.0
| |-pom.xml
|-xyz-war1 artifactId=xyz-war1, parent=xyz-parent
| |-checkout
| |-pom.xml
...
let path be inherited. when building xyz-war1, basedir=<workspace>/xyz-war1.
evaluated path=xyz-war1/pom.xml, count / infer workspace = ${basedir}/../,
check path for xyz-war1 parent = xyz-parent, infer path to parent descriptor
${basedir}/../xyz-parent/pom.xml
3) adding CI into the mix
<workspace>
|-xyz-parent
| |-checkout artifactId=xyz-parent, path=${pom.artifactId}${ciInfix}/pom.xml,
currentVersion=1.0
| |-pom.xml
|-xyz-war1 artifactId=xyz-war1, parent=xyz-parent
| |-checkout
| |-pom.xml
...
let ciInfix be defined as empty string in the parent project properties
definition, and inherited. On the build machine overeride ciInfix=/checkout in
the user's preferences. The scheme still works :-)
For the nested projects EAR path=EAR${ciInfix}/pom.xml, WAR1 path =
EAR${ciInfix}/WAR1/pom.xml etc.
I think introducing information about relative path betwen workspace directory
and project descriptor solves the problem or reaching parent pom because it
gives a lot of flexibility both in workspace and project organization.
Of course the user can still shoot himself in the foot by checking out the
parent project from different branch than the child modules :-)
> 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]
