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 [[email protected]]
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, [email protected] <
[email protected]> 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 [[email protected]]
> 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, [email protected] <
> [email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
