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: [email protected] <javascript:;> > For additional commands, e-mail: [email protected]<javascript:;> > >
