You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "christofer.dutz@c-ware.de" <ch...@c-ware.de> on 2012/10/15 16:13:07 UTC
Is it a bug? (install plugin deploys poms with variables in
artifact.version and parent.version)
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. 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
Re: Is it a bug? (install plugin deploys poms with variables in
artifact.version and parent.version)
Posted by 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>
>
AW: Is it a bug? (install plugin deploys poms with variables in
artifact.version and parent.version)
Posted by "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
Re: Is it a bug? (install plugin deploys poms with variables in
artifact.version and parent.version)
Posted by Stephen Connolly <st...@gmail.com>.
On 15 October 2012 16:56, christofer.dutz@c-ware.de <
christofer.dutz@c-ware.de> wrote:
> 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?
>
Well at this point in time I suggest taking this up on the user list as it
is more a question for that context.
>
> 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
>
>
AW: Is it a bug? (install plugin deploys poms with variables in
artifact.version and parent.version)
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
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 [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
Re: Is it a bug? (install plugin deploys poms with variables in
artifact.version and parent.version)
Posted by Stephen Connolly <st...@gmail.com>.
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
>
>
AW: Is it a bug? (install plugin deploys poms with variables in
artifact.version and parent.version)
Posted by "christofer.dutz@c-ware.de" <ch...@c-ware.de>.
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
Re: Is it a bug? (install plugin deploys poms with variables in
artifact.version and parent.version)
Posted by Stephen Connolly <st...@gmail.com>.
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
>