Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

also trace back to my note on this thread, I use buildnumber-m-p for build
definition and traceability purpose

-D

On Tue, May 9, 2017 at 7:46 PM, Bernd Eckenfels 
wrote:

> You can use the Jenkins environment variable for the build number of a job
> as a read-only parameter.  And I think ${env.BUILD_NUMBER} should also work
> on the command line.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric Benzacar 
> Sent: Wednesday, May 10, 2017 3:32:43 AM
> To: Maven Users List; i...@soebes.de
> Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?
>
> Thanks for the detailed explanation.
>
> A couple of questions come to mind:
>
> 1) can the  element only contain a variables, or can it be a
> combination of fixed + variable?
> for instance:
> 1.2-${changelist}
>
> I see in your examples that it only is a combination of variables with no
> additional text.
>
>
> 2) How do you handle your CD build definitions, given the need to pass the
> revision number at build time?  Do you end up creating new build
> definitions for each version, edit the existing build definition for a new
> version, or is there a way to create a generic build definition that can
> handle this case?
>
> I'm using Jenkins and my biggest annoyance is the need to update/modify my
> Jenkins job definitions.  I could potentially create parameterized build
> defn, where the user enters the rev #, but that is just going to be error
> prone.  I'm trying to remove as much of the human element from this as
> possible.
>
> Is there a way to design the job definition so that I don't have to specify
> this information?  I realize that I can use the mvn.config file to specify
> the revision value but what is the advantage of using that and changing
> that file for each version rather than just changing the pom file itself?
> Isn't it just shifting the problem from one place to another?
>
> Thanks,
>
> Eric
>
>
> On Mon, May 8, 2017 at 1:27 PM, Karl Heinz Marbaise 
> wrote:
>
> > Hi to all,
> >
> > I think it is needed to explain that in more detail (means also to
> improve
> > the ci documentation).
> >
> >
> > Let me start with the following:
> >
> > You can only use those three names "revision", "changelist" and "sha1" in
> > a version tag of the pom file cause they are handled special (the
> > foundation of its handling is given by the explanation of Bernd Eckenfeld
> > Thanks to Bernd).
> >
> > This means in consequence the given part will not work as expected (at
> the
> > moment):
> >
> > com.soebes.examples.j2ee
> parent > >
> > ${revision}
> > pom
> > 
> >   1.2.1-${buildNumber}
> >   SNAPSHOT
> > 
> >
> >
> > If you like to make combinations you can do it like this for example:
> > (https://github.com/khmarbaise/javaee/tree/maven350-properties):
> >
> >   com.soebes.examples.j2ee
> >   parent
> >   ${revision}${sha1}${changelist}
> >   pom
> >
> >   
> > 1.6
> > 1.6
> > 1.3.1
> > -SNAPSHOT
> > 
> >   
> >
> > or to pickup the previous example which should look like this:
> >
> > com.soebes.examples.j2ee
> parent > >
> > ${revision}${changelist}
> > pom
> > 
> >   1.2.1
> >   -SNAPSHOT
> > 
> >
> > So now your build will work as expected.
> >
> > If you like to switch to release you simply do that by using the
> following:
> >
> > mvn -Dchangelist= clean package (This will define changelist as empty).
> >
> > Or if you like to give a buildNumber from commandline:
> >
> > mvn -Dchangelist=-23-SNAPSHOT clean package
> >
> > So to make it more convenient you can define the versions like this:
> >
> >   com.soebes.examples.j2ee
> >   parent
> >   ${revision}${sha1}${changelist}
> >   pom
> >
> >   
> > 1.6
> > 1.6
> > 1.3.1
> > -SNAPSHOT
> > 
> >   
> >
> > So now I can build via (be carefull with the separator between version
> and
> > buildnumber "-"):
> >
> > mvn -Dsha1=-123 clean package
> >
> > By the above you can now define many combinatations on the command line:
> >
> > mvn -Dchangelist= clean package
> >
> > This means the command line overwrites the values of the properties which
> > are defined in the pom file (properties section).
> >
> > You can of course remove the properties (properties section) from the pom
> > file at all and only define the information on command line (works in
> > Eclipse). But you can also define those things in ".mvn/maven.config" via
> > the appropriate "-D...".
> >
> >
> > So now lets come to the point about flatten-maven-plugin:
> >
> > Assume you are using above proerties in kind of flavour...now you are
> > using my example( https://github.com/khmarbaise/
> > javaee/tree/maven350-properties) without the flatten-maven-plugin in the
> > build:
> >
> > mvn install
> >
> > The result of that would be having a folder in your local cache like etc.
> > where you find a jar file and of course a pom file: (I just picked up two
> > files as example):

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Bernd Eckenfels]

You can use the Jenkins environment variable for the build number of a job as a 
read-only parameter.  And I think ${env.BUILD_NUMBER} should also work on the 
command line.

Gruss
Bernd
--
http://bernd.eckenfels.net

From: Eric Benzacar 
Sent: Wednesday, May 10, 2017 3:32:43 AM
To: Maven Users List; i...@soebes.de
Subject: Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

Thanks for the detailed explanation.

A couple of questions come to mind:

1) can the  element only contain a variables, or can it be a
combination of fixed + variable?
for instance:
1.2-${changelist}

I see in your examples that it only is a combination of variables with no
additional text.


2) How do you handle your CD build definitions, given the need to pass the
revision number at build time?  Do you end up creating new build
definitions for each version, edit the existing build definition for a new
version, or is there a way to create a generic build definition that can
handle this case?

I'm using Jenkins and my biggest annoyance is the need to update/modify my
Jenkins job definitions.  I could potentially create parameterized build
defn, where the user enters the rev #, but that is just going to be error
prone.  I'm trying to remove as much of the human element from this as
possible.

Is there a way to design the job definition so that I don't have to specify
this information?  I realize that I can use the mvn.config file to specify
the revision value but what is the advantage of using that and changing
that file for each version rather than just changing the pom file itself?
Isn't it just shifting the problem from one place to another?

Thanks,

Eric


On Mon, May 8, 2017 at 1:27 PM, Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> I think it is needed to explain that in more detail (means also to improve
> the ci documentation).
>
>
> Let me start with the following:
>
> You can only use those three names "revision", "changelist" and "sha1" in
> a version tag of the pom file cause they are handled special (the
> foundation of its handling is given by the explanation of Bernd Eckenfeld
> Thanks to Bernd).
>
> This means in consequence the given part will not work as expected (at the
> moment):
>
> com.soebes.examples.j2ee parent >
> ${revision}
> pom
> 
>   1.2.1-${buildNumber}
>   SNAPSHOT
> 
>
>
> If you like to make combinations you can do it like this for example:
> (https://github.com/khmarbaise/javaee/tree/maven350-properties):
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> or to pickup the previous example which should look like this:
>
> com.soebes.examples.j2ee parent >
> ${revision}${changelist}
> pom
> 
>   1.2.1
>   -SNAPSHOT
> 
>
> So now your build will work as expected.
>
> If you like to switch to release you simply do that by using the following:
>
> mvn -Dchangelist= clean package (This will define changelist as empty).
>
> Or if you like to give a buildNumber from commandline:
>
> mvn -Dchangelist=-23-SNAPSHOT clean package
>
> So to make it more convenient you can define the versions like this:
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> So now I can build via (be carefull with the separator between version and
> buildnumber "-"):
>
> mvn -Dsha1=-123 clean package
>
> By the above you can now define many combinatations on the command line:
>
> mvn -Dchangelist= clean package
>
> This means the command line overwrites the values of the properties which
> are defined in the pom file (properties section).
>
> You can of course remove the properties (properties section) from the pom
> file at all and only define the information on command line (works in
> Eclipse). But you can also define those things in ".mvn/maven.config" via
> the appropriate "-D...".
>
>
> So now lets come to the point about flatten-maven-plugin:
>
> Assume you are using above proerties in kind of flavour...now you are
> using my example( https://github.com/khmarbaise/
> javaee/tree/maven350-properties) without the flatten-maven-plugin in the
> build:
>
> mvn install
>
> The result of that would be having a folder in your local cache like etc.
> where you find a jar file and of course a pom file: (I just picked up two
> files as example):
>
> $HOME/.m2/repository/com/soebes/examples/j2ee/parent/1.3.1-
> SNAPSHOT/parent-1.3.1-SNAPSHOT.pom
> $HOME//.m2/repository/com/soebes/examples/j2ee/domain/1.3.1-
> SNAPSHOT/domain-1.3.1-SNAPSHOT.jar
>
> Looks Ok so far? But let us take a look into the pom file:
>
> The pom file will look like this:
>
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> This looks ok so far (on the first glance)
>
> But 

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Eric Benzacar]

Thanks for the detailed explanation.

A couple of questions come to mind:

1) can the  element only contain a variables, or can it be a
combination of fixed + variable?
for instance:
1.2-${changelist}

I see in your examples that it only is a combination of variables with no
additional text.


2) How do you handle your CD build definitions, given the need to pass the
revision number at build time?  Do you end up creating new build
definitions for each version, edit the existing build definition for a new
version, or is there a way to create a generic build definition that can
handle this case?

I'm using Jenkins and my biggest annoyance is the need to update/modify my
Jenkins job definitions.  I could potentially create parameterized build
defn, where the user enters the rev #, but that is just going to be error
prone.  I'm trying to remove as much of the human element from this as
possible.

Is there a way to design the job definition so that I don't have to specify
this information?  I realize that I can use the mvn.config file to specify
the revision value but what is the advantage of using that and changing
that file for each version rather than just changing the pom file itself?
Isn't it just shifting the problem from one place to another?

Thanks,

Eric


On Mon, May 8, 2017 at 1:27 PM, Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> I think it is needed to explain that in more detail (means also to improve
> the ci documentation).
>
>
> Let me start with the following:
>
> You can only use those three names "revision", "changelist" and "sha1" in
> a version tag of the pom file cause they are handled special (the
> foundation of its handling is given by the explanation of Bernd Eckenfeld
> Thanks to Bernd).
>
> This means in consequence the given part will not work as expected (at the
> moment):
>
> com.soebes.examples.j2ee parent >
> ${revision}
> pom
> 
>   1.2.1-${buildNumber}
>   SNAPSHOT
> 
>
>
> If you like to make combinations you can do it like this for example:
> (https://github.com/khmarbaise/javaee/tree/maven350-properties):
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> or to pickup the previous example which should look like this:
>
> com.soebes.examples.j2ee parent >
> ${revision}${changelist}
> pom
> 
>   1.2.1
>   -SNAPSHOT
> 
>
> So now your build will work as expected.
>
> If you like to switch to release you simply do that by using the following:
>
> mvn -Dchangelist= clean package (This will define changelist as empty).
>
> Or if you like to give a buildNumber from commandline:
>
> mvn -Dchangelist=-23-SNAPSHOT clean package
>
> So to make it more convenient you can define the versions like this:
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> So now I can build via (be carefull with the separator between version and
> buildnumber "-"):
>
> mvn -Dsha1=-123 clean package
>
> By the above you can now define many combinatations on the command line:
>
> mvn -Dchangelist= clean package
>
> This means the command line overwrites the values of the properties which
> are defined in the pom file (properties section).
>
> You can of course remove the properties (properties section) from the pom
> file at all and only define the information on command line (works in
> Eclipse). But you can also define those things in ".mvn/maven.config" via
> the appropriate "-D...".
>
>
> So now lets come to the point about flatten-maven-plugin:
>
> Assume you are using above proerties in kind of flavour...now you are
> using my example( https://github.com/khmarbaise/
> javaee/tree/maven350-properties) without the flatten-maven-plugin in the
> build:
>
> mvn install
>
> The result of that would be having a folder in your local cache like etc.
> where you find a jar file and of course a pom file: (I just picked up two
> files as example):
>
> $HOME/.m2/repository/com/soebes/examples/j2ee/parent/1.3.1-
> SNAPSHOT/parent-1.3.1-SNAPSHOT.pom
> $HOME//.m2/repository/com/soebes/examples/j2ee/domain/1.3.1-
> SNAPSHOT/domain-1.3.1-SNAPSHOT.jar
>
> Looks Ok so far? But let us take a look into the pom file:
>
> The pom file will look like this:
>
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> This looks ok so far (on the first glance)
>
> But now I have given mvn -Drevision=2.0.0 install
>
> There will produced also files like this:
>
> $HOME/.m2/repository/com/soebes/examples/j2ee/parent/2.0.0-
> SNAPSHOT/parent-2.0.0-SNAPSHOT.pom
>
> The pom file will look like exactly the same:
>
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> which is obviouly wrong(the same is 

Re: [EXTERNAL] RE: Continuous Delivery with Maven now possible?

[Dan Tran]

Hi

I am in the process of switching our 250+ modules to version-less poms.
There are 2 phases

1. Activated flatten poms.  Every thing seems ok, except those external
modules which depends on a full pom.xml at maven repo. This is fixable
2. Switched   versionless using ${revision} at a dev branch.  Looking good,
except final maven memory report increases significantly by 2G for both min
and max
No major hickup at IDEs eclipse, Intellij, and netbeans

If you have any idea on the root cause of memory issue please advice

Thanks

-Dan

On Mon, May 8, 2017 at 10:27 AM, Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> I think it is needed to explain that in more detail (means also to improve
> the ci documentation).
>
>
> Let me start with the following:
>
> You can only use those three names "revision", "changelist" and "sha1" in
> a version tag of the pom file cause they are handled special (the
> foundation of its handling is given by the explanation of Bernd Eckenfeld
> Thanks to Bernd).
>
> This means in consequence the given part will not work as expected (at the
> moment):
>
> com.soebes.examples.j2ee parent >
> ${revision}
> pom
> 
>   1.2.1-${buildNumber}
>   SNAPSHOT
> 
>
>
> If you like to make combinations you can do it like this for example:
> (https://github.com/khmarbaise/javaee/tree/maven350-properties):
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> or to pickup the previous example which should look like this:
>
> com.soebes.examples.j2ee parent >
> ${revision}${changelist}
> pom
> 
>   1.2.1
>   -SNAPSHOT
> 
>
> So now your build will work as expected.
>
> If you like to switch to release you simply do that by using the following:
>
> mvn -Dchangelist= clean package (This will define changelist as empty).
>
> Or if you like to give a buildNumber from commandline:
>
> mvn -Dchangelist=-23-SNAPSHOT clean package
>
> So to make it more convenient you can define the versions like this:
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> So now I can build via (be carefull with the separator between version and
> buildnumber "-"):
>
> mvn -Dsha1=-123 clean package
>
> By the above you can now define many combinatations on the command line:
>
> mvn -Dchangelist= clean package
>
> This means the command line overwrites the values of the properties which
> are defined in the pom file (properties section).
>
> You can of course remove the properties (properties section) from the pom
> file at all and only define the information on command line (works in
> Eclipse). But you can also define those things in ".mvn/maven.config" via
> the appropriate "-D...".
>
>
> So now lets come to the point about flatten-maven-plugin:
>
> Assume you are using above proerties in kind of flavour...now you are
> using my example( https://github.com/khmarbaise/
> javaee/tree/maven350-properties) without the flatten-maven-plugin in the
> build:
>
> mvn install
>
> The result of that would be having a folder in your local cache like etc.
> where you find a jar file and of course a pom file: (I just picked up two
> files as example):
>
> $HOME/.m2/repository/com/soebes/examples/j2ee/parent/1.3.1-
> SNAPSHOT/parent-1.3.1-SNAPSHOT.pom
> $HOME//.m2/repository/com/soebes/examples/j2ee/domain/1.3.1-
> SNAPSHOT/domain-1.3.1-SNAPSHOT.jar
>
> Looks Ok so far? But let us take a look into the pom file:
>
> The pom file will look like this:
>
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> This looks ok so far (on the first glance)
>
> But now I have given mvn -Drevision=2.0.0 install
>
> There will produced also files like this:
>
> $HOME/.m2/repository/com/soebes/examples/j2ee/parent/2.0.0-
> SNAPSHOT/parent-2.0.0-SNAPSHOT.pom
>
> The pom file will look like exactly the same:
>
>
>   com.soebes.examples.j2ee
>   parent
>   ${revision}${sha1}${changelist}
>   pom
>
>   
> 1.6
> 1.6
> 1.3.1
> -SNAPSHOT
> 
>   
>
> which is obviouly wrong(the same is if you omit the revision,
> changelist and sha1 from properties part).
>
> If you like to consume this pom file it will fail cause this can't be
> correctly solve (where is the -Drevision=2.0.0 gone?)
>
>
> That is the reason you need the flatten-maven-plugin cause it replace the
> propreties in the version tag with it's current version (can do more but
> that's a different story) and produce a correct pom file:
>
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd; xmlns="
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
>   4.0.0
>   com.soebes.examples.j2ee
>   parent
>   2.0.0-SNAPSHOT
>   pom
>   
> 
>   Apache License 2.0
>   

maven shade multi module setup

[Georg Heiler]

Hi,
I am facing a problem with correctly setting up shading in a multi module
maven project. Currently all the original code is removed / filtered out
from the user-jar even though.
http://stackoverflow.com/questions/43873608/maven-shade-in-multi-project-setup-filtering-too-much


Looking forward to any hints which could point me in the right direction.

regards,
Georg

How to use global checkstyle.xml that have SuppressionsFilter included

[Gayan Weerakutti]

So here in my case I want use remote checkstyle file located in 
https://github.com/openmrs/openmrs-core/blob/master/checkstyle.xml?#L45 in 
another project.


In my project's pom I have config location set as 
follows:



 https://github.com/openmrs/openmrs-core/blob/master/checkstyle.xml


However checkstyle can't resolve checkstyle-suppressions.xml because of the 
configuration included in the remote file:





So what would be the ideal solution to be alble to use that remote checkstyle 
on other projects?. BTW I can get access to openmrs-core to make any necessary 
changes.

Thanks,
Gayan