You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Gebhardt, Joern" <jo...@sap.com> on 2012/09/13 10:41:18 UTC
Discussion: Does a variable replacement in the POM before the
repository upload make sense?
Hi,
I created a resolve-pom-maven-plugin (http://goo.gl/HfHth) that can be
used to replace all variables inside a POM by their actual build settings
and use this resolved POM in the further processing, especially for
uploading it into the local and remote repository.
A famous use case would be that the central build system injects the
project's incremental version from the outside. In this case your POM
would look like this:
<project>
...
<parent>
<groupId>my.group</groupId>
<artifactId>parent</version>
<version>1.0.${injectedBuildNr}</version>
</parent>
<artifactId>child</version>
<properties>
<injectedBuildNr>0-SNAPSHOT</injectedBuildNr>
</properties>
...
</project>
If you call "mvn clean deploy -DinjectedBuildNr=42" a version 1.0.42 of
the "child" would be created and uploaded into the repository. The
artifact does have the correct path
/my/group/child/1.0.42/child-1.0.42.pom in the repository, however if you
look inside the uploaded POM you'll discover that the source POM got
uploaded where the version is still "1.0.${injectedBuildNr}". Any usage of
this "child" module with version "1.0.42" will fail as the dependency
resolution is looking for the "parent" version "1.0.${injectedBuildNr}"
which is not available in the repository.
By using the resolve-pom-maven-plugin like this
<build>
<plugins>
<plugin>
<groupId>com.sap.prd.mobile.ios.maven.plugins</groupId>
<artifactId>resolve-pom-maven-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>resolve-pom-props</id>
<goals>
<goal>resolve-pom-props</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
the resolved POM will be uploaded and you can use the version "1.0.42" of
the "child" module as regular dependency.
My question now is if it is a good idea to upload resolved POMs, i.e. POMs
where all property-placeholders got replaced by their actual build
settings?
What are the drawbacks of this approach?
Would it make sense to extend the install and deploy plugin by the
functionality to upload resolved POMs instead of the source POMs?
Kind regards,
Jörn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Discussion: Does a variable replacement in the POM before the
repository upload make sense?
Posted by Barrie Treloar <ba...@gmail.com>.
On Thu, Sep 13, 2012 at 9:44 PM, Stephen Connolly
<st...@gmail.com> wrote:
> Beware the gpg signatures. Also some people use properties in the depMgmt
> section of a parent Pom to allow bulk dep changes, so inheritance can be
> screwed over.
>
> Tl;dr this is a hard problem that looks easy
Also read the fine print about the order of evaluation for variable
interpolation.
Simple things like using ${pom.version} work fine when your modules
work in "lock-step", but if you tease them apart things start failing
apart.
There is some stuff in the maven books about resolved and source poms.
Might want to check that out.
My 2c would be you want stuff locked down if its in an external repository.
So that would mean the variables are replaced with actual values.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Discussion: Does a variable replacement in the POM before the
repository upload make sense?
Posted by Stephen Connolly <st...@gmail.com>.
Beware the gpg signatures. Also some people use properties in the depMgmt
section of a parent Pom to allow bulk dep changes, so inheritance can be
screwed over.
Tl;dr this is a hard problem that looks easy
On Thursday, 13 September 2012, Gebhardt, Joern wrote:
> Hi,
>
> I created a resolve-pom-maven-plugin (http://goo.gl/HfHth) that can be
> used to replace all variables inside a POM by their actual build settings
> and use this resolved POM in the further processing, especially for
> uploading it into the local and remote repository.
>
> A famous use case would be that the central build system injects the
> project's incremental version from the outside. In this case your POM
> would look like this:
>
> <project>
> ...
> <parent>
> <groupId>my.group</groupId>
> <artifactId>parent</version>
> <version>1.0.${injectedBuildNr}</version>
> </parent>
> <artifactId>child</version>
>
> <properties>
> <injectedBuildNr>0-SNAPSHOT</injectedBuildNr>
> </properties>
> ...
> </project>
>
>
> If you call "mvn clean deploy -DinjectedBuildNr=42" a version 1.0.42 of
> the "child" would be created and uploaded into the repository. The
> artifact does have the correct path
> /my/group/child/1.0.42/child-1.0.42.pom in the repository, however if you
> look inside the uploaded POM you'll discover that the source POM got
> uploaded where the version is still "1.0.${injectedBuildNr}". Any usage of
> this "child" module with version "1.0.42" will fail as the dependency
> resolution is looking for the "parent" version "1.0.${injectedBuildNr}"
> which is not available in the repository.
>
>
>
> By using the resolve-pom-maven-plugin like this
>
> <build>
> <plugins>
> <plugin>
> <groupId>com.sap.prd.mobile.ios.maven.plugins</groupId>
> <artifactId>resolve-pom-maven-plugin</artifactId>
> <version>1.0</version>
> <executions>
> <execution>
> <id>resolve-pom-props</id>
> <goals>
> <goal>resolve-pom-props</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
>
>
> the resolved POM will be uploaded and you can use the version "1.0.42" of
> the "child" module as regular dependency.
>
> My question now is if it is a good idea to upload resolved POMs, i.e. POMs
> where all property-placeholders got replaced by their actual build
> settings?
> What are the drawbacks of this approach?
> Would it make sense to extend the install and deploy plugin by the
> functionality to upload resolved POMs instead of the source POMs?
>
> Kind regards,
> Jörn
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>