maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: Is it a bug? (install plugin deploys poms with variables in artifact.version and parent.version)
Date Mon, 15 Oct 2012 15:35:57 GMT
Those are edge cases where things unintentionally work, probably falling
out of the way the model is built in memory.


/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


Don't do it.

Many kittens will be killed if you persist in trying to square this circle

On 15 October 2012 16:18, <> 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 []
> 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, <
>> wrote:
> > Hi,
> >
> > I just opened an issue regarding the install plugin (I think that's the
> > module responsible).
> >
> >
> > The general problem is that I am using variables for defining the
> versions
> > of artifacts, dependencies and parent projects.
> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message