Re: Is it a bug? (install plugin deploys poms with variables in artifact.version and parent.version)

[Baptiste MATHUS <ml...@batmat.net>]

Moving onto user-list.

Thanks

2012/10/15 christofer.dutz@c-ware.de <ch...@c-ware.de>

> Just did a little digging ... so assuming I have only two projects ... one
> master and one module.
> If I define two properties in my master pom: "my.cool.master.version" and
> "my.cool.alternate.master.version"  and set both to the same value of
> "1.2-SNAPSHOT".
>
> In szenario 1: I ´hard code the version of the master to "1.2-SNAPSHOT"
> but use the property to reference the parent from the moule ... when
> running a build, maven tries to download
> "de/mycompany/test/${my.cool.master.version}/mycoolmaster-${my.cool.master.version}.pom"
> --> Failure
>
> In szenario 2: I use the same variable for defining the masters version.
> This time the maven build runs fine and the parent version is correctly
> resolved.
>
> In szenario 3: I use the first property to define the version of the
> master and the second one for referncing the parent from the module ...
> when running a build, maven tries to download
> "de/mycompany/test/${my.cool.alternate.master.version}/mycoolmaster-${my.cool.alternate.master.version}.pom"
> --> Failure
>
> So to me it looks as if there was some sort of intention behind
> everything. To mee it looks like one teeniewienie loophole allowing
> properies in versions while closing the usage range so much that possible
> harm is reduced to it's absolute minimum, while allowing that one usecase I
> was intending to use it for. After all ... this is a problem users are
> begging for maven to provide a solution since maven 2.0 (When looking at
> the forums).
>
> Chris
>
>
>
>
> ________________________________________
> Von: Stephen Connolly [stephen.alan.connolly@gmail.com]
> Gesendet: Montag, 15. Oktober 2012 17:35
> An: Maven Developers List
> Betreff: Re: Is it a bug? (install plugin deploys poms with variables in
> artifact.version and parent.version)
>
> Those are edge cases where things unintentionally work, probably falling
> out of the way the model is built in memory.
>
> e.g.
>
> /project/version has an effective default value of
> ${project.parent.version}
> /project/groupId has an effective default value of
> ${project.parent.groupId}
>
> I say "effective" as the actual handling is IIRC a straight copy.
>
> Also if you are using System properties, there may be some unintended
> expansion of those in /project/parent
>
> BUT I REPEAT... STOP!
>
> Don't do it.
>
> Many kittens will be killed if you persist in trying to square this circle
>
> On 15 October 2012 16:18, christofer.dutz@c-ware.de <
> christofer.dutz@c-ware.de> wrote:
>
> > I know that property substitution in those places seems to be
> unavailable.
> >
> > But there seems to be one case where it's seems to be explicitly allowed:
> > If the parent artifacts version is defined by the same variable used to
> > reference the parent pom, maven doesn't complain about anything (So I
> guess
> > this case is explicitly allowed). The artifacts are built, named and
> > deployed at the absolutely correct place. If I define the version of the
> > parent without a property (or a property with a different name), maven
> > doesn't resolve the version and I get all sorts of errors, even if I set
> it
> > to the same value. So I guess there must be some sort of support for it?
> >
> > Just have a look at the tiny project I attached to the issue. It builds
> > just fine, except for the fact that the poms deployed in the local maven
> > repo.
> >
> > Chris
> >
> > ________________________________________
> > Von: Stephen Connolly [stephen.alan.connolly@gmail.com]
> > Gesendet: Montag, 15. Oktober 2012 16:32
> > An: Maven Developers List
> > Betreff: Re: Is it a bug? (install plugin deploys poms with variables in
> > artifact.version and parent.version)
> >
> > On 15 October 2012 15:13, christofer.dutz@c-ware.de <
> > christofer.dutz@c-ware.de> wrote:
> >
> > > Hi,
> > >
> > > I just opened an issue regarding the install plugin (I think that's the
> > > module responsible).
> > > http://jira.codehaus.org/browse/MNG-5358
> > >
> > > The general problem is that I am using variables for defining the
> > versions
> > > of artifacts, dependencies and parent projects.
> >
> >
> > STOP!
> >
> > Property substitution is not supported at the following XPath locations
> >
> > /project/parent/groupId
> > /project/parent/artifactId
> > /project/parent/version
> > /project/groupId
> > /project/artifactId
> > /project/version
> > /project/packaging
> >
> > If your issue is that Maven is failing to report
> > groupIds/artifactIds/versions at these XPath locations containing ${...}
> > characters as being invalid, then you have a valid bug. Otherwise you are
> > doing something wrong.
> >
> > Note we are investigating at some point in the future allowing
> > /project/parent/version to be optional where the parent is available on
> > disk at the specified /project/parent/relativePath but that is not a
> > feature in Maven 3.0.x
> >
> > -Stephen
> >
> >
> >
> > > The install plugin installs the poms in the correct place, but the
> > > deployed poms contain variables, which could cause major problems. I
> > would
> > > assume that because the artifact is deployed in a diectory containing a
> > > real version, so should the corresponding pom-file.
> > >
> > > Is there any known workaround for this or is someone allready working
> on
> > > this? If there is no known workaround and you would say this is a bug
> and
> > > there is noone working on it, I would start fixing it myself and
> attach a
> > > patch to the issue as soon as I've finished it.
> > >
> > > Chris
> > >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
> nbsp;!
>  <de...@maven.apache.org>
>