maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Shum (JIRA)" <j...@codehaus.org>
Subject [jira] (MNG-624) automatic parent versioning
Date Mon, 09 Dec 2013 09:45:45 GMT

    [ https://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336980#comment-336980
] 

Adrian Shum edited comment on MNG-624 at 12/9/13 3:44 AM:
----------------------------------------------------------

For all suggestion/workaround proposed here using a property for parent version, they all
suffer from one issue: This will work for build, but will fail on using the result as dependency.

Assuming I have a very simple structure like this:
{code}
foo-parent
foo-lib
{code}
assume the POm of foo-lib contains

{code}
    <parent>
        <groupId>foo</groupId>
        <artifactId>foo-parent</artifactId>
        <version>${foo.version}</version>
        <relativePath>../foo-parent/pom.xml</relativePath>
    </parent>
{code}

(foo.version can be provided by any means, by command line or by property defined in parent
etc)

Because Maven is deploying/installing the POM as-is.  That means, if I put foo-lib in the
repository, when people is using it as dependency, the POM is containing only 
{code}${foo.version} {code}
string literal as the parent version.  There is no way that it can resolve the correct parent
POM to refer to.

May I suggests, instead of deploying the POM as-is, we are creating an "effective" POM to
use to deploy? In the "effective" POM, we have all necessary properties replaced and use that
for install/deploy.  
                
      was (Author: adrianshum):
    For all suggestion/workaround proposed here using a property for parent version, they
all suffer from one issue: This will work for build, but will fail on using the result as
dependency.

Assuming I have a very simple structure like this:
{code}
foo-parent
foo-lib
{code}
assume the POm of foo-lib contains

{code}
    <parent>
        <groupId>foo</groupId>
        <artifactId>foo-parent</artifactId>
        <version>${foo.version}</version>
        <relativePath>../foo-parent/pom.xml</relativePath>
    </parent>
{code}

(foo.version can be provided by any means, by command line or by property defined in parent
etc)

Because Maven is deploying/installing the POM as-is.  That means, if I put foo-lib in the
repository, when people is using it as dependency, the POM is containing only ${foo.version}
string literal as the parent version.  There is no way that it can resolve the correct parent
POM to refer to.

May I suggests, instead of deploying the POM as-is, we are creating an "effective" POM to
use to deploy? In the "effective" POM, we have all necessary properties replaced and use that
for install/deploy.  
                  
> automatic parent versioning
> ---------------------------
>
>                 Key: MNG-624
>                 URL: https://jira.codehaus.org/browse/MNG-624
>             Project: Maven 2 & 3
>          Issue Type: Improvement
>          Components: Inheritance and Interpolation
>            Reporter: Brett Porter
>            Assignee: Ralph Goers
>            Priority: Blocker
>             Fix For: 3.2
>
>         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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message