Hmm ... but if the effective defaults are as you claim, why does this even work correctly, if the versions of every artifact is completely different?
Unfortunatley this unintentional working feature currently seems to be the only "feature" allowing me to define a really nicely working build. The problem is that in the project I am working on there are a lot of modules each one with a individual version. There are inter-module dependencies, so the release process was a total nightmare. Using this approach I was able to configure all versions in the master pom and release all modules without any trouble. Without being able to define the parent without a version, every other concept I tired blew up when it came to the parent pom relation. If this is the place where I would start running over kittens with a tank ... what would be the solution for this problem be, in which hundreds of alive kittens don't make my life during a release a total nightmare? 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]
