influenceing the pom that is deployed

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

influenceing the pom that is deployed

Christian Domsch-3
Hi,

in our company we use some elaborate way how we stack patched on top of our product. The consequence of that is we use expressions for defining the version of a pom in the parent definition of our submodules. Example:

Root pom:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <parent>
    <groupId>com.group</groupId>
    <artifactId>product</artifactId>
    <version>1.1.1</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.group.patch</groupId>
  <artifactId>Group-patch</artifactId>
  <version>${patch.version}</version>
  <packaging>pom</packaging>

  <properties>
    <customer>customername</customer>
    <tag.version>1.1.1</tag.version>
    <delivery.version>1</delivery.version>
    <patch.version>${tag.version}-${customer}-${delivery.version}</patch.version>
  </properties>

  <modules>
    <module>patch-distribution</module>
  </modules>
</project>

module patch-distribution pom:

<project xmlns="http://maven.apache.org/POM/4.0.0”
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance”
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
    <parent>
        <groupId>com.group.patch</groupId>
        <artifactId>Group-patch</artifactId>
        <version>${patch.version}</version>
        <relativePath>..</relativePath>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <artifactId>patch-distribution</artifactId>
    <packaging>pom</packaging>
</project>

We use this pattern for the submodules everywhere. The benefit is that we only need to define versions in the root pom and have no amount of duplicated information in all poms. The build works perfectly this way. There are warnings about using an expression inside the parent.version, but it does work.

Now, the catch is when you deploy these. Lets say for example, in a different project you reference patch-distribution-1.1.1-customername-1.jar (thats the complete name of the dependency). The jar and pom will be stored correctly under that name, but the contents of the pom still contains the expression ${patch.version}, which now is unknown.

You could add the definition in your own pom, but that is cumbersome. It would be neat, if in the process of deploying the pom to the repository, you could rewrite the pom and exchange the expression for its actual value.

Now, any ideas how to do that, besides rewriting the complete deploy plugin?

Thanks in advance.

Christian

Reply | Threaded
Open this post in threaded view
|

Re: influenceing the pom that is deployed

Karl Heinz Marbaise-3
Hi,


The warnings during your build are intentionally and have their reason
exactly the one that after a

mvn install

or

mvn deploy

the expression have not been replaced which makes the resulting pom's
useless...

This can solved by using the offical way using the properties
'revision', 'sha1' and 'changelist'...

This can simply being done like this (with a supplemental configuration
of the flatten-maven-plugin which is absolute necessary[1]; Really read
it completely..!!)

<project>
  ...
  <groupId>com.group.patch</groupId>
  <artifactId>Group-patch</artifactId>
  <version>${revision}</version>
  <packaging>pom</packaging>

  <properties>
     <revision>1.0.0-SNAPSHOT</revision>
  </propeties>
..
</project>


Starting with Maven 3.5.0 this can be used...

Using the above you can simply:

mvn install

or

mvn deploy


What you can also do is this:

mvn -Drevision=2.3.1-1 install

This will overwrite the property and will set the version for your
artifacts...


You can of course if you like combine different properties (one of the
previously mentioned) like this:


<project>
  ...
  <groupId>com.group.patch</groupId>
  <artifactId>Group-patch</artifactId>
  <version>${revision}${changelist}${sha1}</version>
  <packaging>pom</packaging>

  <properties>
     <revision>1.0.0</revision>
     <sha1>-SNAPSHOT</sha1>
     <changelist>-1A</changelist>
  </propeties>
..
</project>

By using the above you could call:

mvn -Dsha1=.RELEASE deploy

I recomment to use only a single property cause you can overwrite it
always on command line or via property in the pom.xml file...


Apart from that I can strongly encourage you to use semantical
versions[3] to express things like a patch/bugfix of a things like:

1.1.0 Release
1.1.1  Bug Fix
1.1.2  Bug Fix
1.2.0 Release functional enhancement

Kind regards
Karl Heinz Marbaise

[1]: https://maven.apache.org/maven-ci-friendly.html
[2]: https://maven.apache.org/docs/3.5.0/release-notes.html
[3]: https://semver.org/

On 19/07/18 15:55, Christian Domsch wrote:

> Hi,
>
> in our company we use some elaborate way how we stack patched on top of our product. The consequence of that is we use expressions for defining the version of a pom in the parent definition of our submodules. Example:
>
> Root pom:
>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
>           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>           xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
>    <parent>
>      <groupId>com.group</groupId>
>      <artifactId>product</artifactId>
>      <version>1.1.1</version>
>    </parent>
>    <modelVersion>4.0.0</modelVersion>
>
>    <groupId>com.group.patch</groupId>
>    <artifactId>Group-patch</artifactId>
>    <version>${patch.version}</version>
>    <packaging>pom</packaging>
>
>    <properties>
>      <customer>customername</customer>
>      <tag.version>1.1.1</tag.version>
>      <delivery.version>1</delivery.version>
>      <patch.version>${tag.version}-${customer}-${delivery.version}</patch.version>
>    </properties>
>
>    <modules>
>      <module>patch-distribution</module>
>    </modules>
> </project>
>
> module patch-distribution pom:
>
> <project xmlns="http://maven.apache.org/POM/4.0.0”
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance”
>          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
>      <parent>
>          <groupId>com.group.patch</groupId>
>          <artifactId>Group-patch</artifactId>
>          <version>${patch.version}</version>
>          <relativePath>..</relativePath>
>      </parent>
>
>      <modelVersion>4.0.0</modelVersion>
>      <artifactId>patch-distribution</artifactId>
>      <packaging>pom</packaging>
> </project>
>
> We use this pattern for the submodules everywhere. The benefit is that we only need to define versions in the root pom and have no amount of duplicated information in all poms. The build works perfectly this way. There are warnings about using an expression inside the parent.version, but it does work.
>
> Now, the catch is when you deploy these. Lets say for example, in a different project you reference patch-distribution-1.1.1-customername-1.jar (thats the complete name of the dependency). The jar and pom will be stored correctly under that name, but the contents of the pom still contains the expression ${patch.version}, which now is unknown.
>
> You could add the definition in your own pom, but that is cumbersome. It would be neat, if in the process of deploying the pom to the repository, you could rewrite the pom and exchange the expression for its actual value.
>
> Now, any ideas how to do that, besides rewriting the complete deploy plugin?
>
> Thanks in advance.
>
> Christian
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]