Moving onto user-list. Thanks
2012/10/15 [email protected] <[email protected]> > 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] > > -- > Baptiste <Batmat> MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > nbsp;! > <[email protected]> >
