[
http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146353#action_146353
]
ralphgoers edited comment on MNG-624 at 8/28/08 6:23 PM:
----------------------------------------------------------
If you are doing a multiproject build the projects will be cached internally by
their full path. As the various projects are built they will find the fully
resolved projects in the cache. Then, as the projects are processed their
pom.xml files will be modified so that there are no variables for the
artifactId, groupId and version and they will be placed into their respective
target directories. If you then do a build from a subproject it will find the
pom in the parent's target directory. Since the variables have been replaced
there is no need to recurse.
What the comment about the variables not being known means is that before
looking for the parent an attempt is made to resolve the version. If they
variable for the version is defined in the current pom or a system property it
will be resolved. Since the parent hasn't been located yet the variable can't
be resolved from there. If the version is resolved by doing this no attempt is
even made to look for the parent project. If it isn't then the other steps are
followed.
was (Author: ralphgoers):
If you are doing a multiproject build the projects will be cached
internally by their full path. As the various projects are built they will find
the fully resolved projects in the cache. Then, as the projects are processed
their pom.xml files will be modified so that there are no variables for the
artifactId, groupId and version and they will be placed into their respective
target directories. If you then do a build from a subproject it will find the
pom in the parent's target directory. Since the variables have been replaced
there is no need to recurse.
What the comment about the variables not being known means is that before
looking for the parent an attempt is made to resolve the variables. If they
variables are defined in the current pom or a system property they will be
resolved. Since the parent hasn't been located yet they can't be resolved from
there. If the version is resolved by doing this no attempt is even made to look
for the parent project. If it isn't then the other steps are followed.
> automatic parent versioning
> ---------------------------
>
> Key: MNG-624
> URL: http://jira.codehaus.org/browse/MNG-624
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
> Reporter: Brett Porter
> Assignee: Ralph Goers
> Priority: Blocker
> Fix For: 3.0
>
> Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see
> MNG-521)
> currently, you have to specify the parent version when extending which makes
> a project stand alone very easily, but has the drawback of being a
> maintainance problem when you start development on a new version. Tools can
> help, but it would be nice not to have to rely on them.
> One alternative is to allow the parent version to be omitted, and when it is
> it is assumed you want the latest. The parent is used from the reactor or the
> universal source directory. IT may also be read from a LATEST in the
> repository though this is contentious - it may be better to simply fail in
> that environment and require builds be in a known checkout structure for
> building individual projects.
> This also introduces the need for tool support to populate the version on
> release and deployment for reproducibility.
--
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
