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

[Dan Tran]

On Wed, May 10, 2017 at 11:50 AM, Karl Heinz Marbaise 
wrote:

> Hi Dan,
>
> On 10/05/17 00:59, Dan Tran wrote:
>
>> 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,
>>
>
> Good to hear that...
>
> > except those external
>
>> modules which depends on a full pom.xml at maven repo. This is fixable
>>
>
> Can you give more details about that? What that means?


any project depends on any flatten pom is screwed!!! but that is there
problem, they should not do that




>
>
> 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
>>
>
> you mean the output of Maven at BUILD SUCCESS ?
>

Yes


>
> Do you have the option to test with JConsole during the run of the build
> and see how the evolution of the memory usage is going over the time? Can
> you give the exact values for -Xmx, -Xms etc. and which JDK you are using ?
>
> currently, I don't set any memory settings. My build is under SLES12SP2
docker container with latest  openjdk  1.8.x


>
> Hm...Maven 3.5.0 contains a fix for larger reactors which caused a bigger
> issues with large reactors (See https://github.com/khmarbaise/
> maven-test-project-generator).
>
> I'm really astonished cause Maven 3.3.9 used more memory than 3.5.0 did
> (based on my tests)...Maybe the changes for the properties (revision,
> changelist, sha1) might be the culprit...
>
>
> No major hickup at IDEs eclipse, Intellij, and netbeans
>>
>
> No major means there are some? Do you have some more details...
>
>
One one my NetBean user notices  'Build with dependencies' is much slower.
But he only does it once a day



>
> Kind regards
> Karl Heinz Marbaise
>
>>
>> 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):
>>>
>>> 

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

[Eric B]

Right... That will give me a build number, but I still need to figure a way
to provide the version number to the build.  That one had me stumped.

Thanks

Eric

On May 9, 2017 10: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 

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

[Karl Heinz Marbaise]

Hi Dan,

On 10/05/17 00:59, Dan Tran wrote:

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,


Good to hear that...

> except those external

modules which depends on a full pom.xml at maven repo. This is fixable


Can you give more details about that? What that means?


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


you mean the output of Maven at BUILD SUCCESS ?

Do you have the option to test with JConsole during the run of the build 
and see how the evolution of the memory usage is going over the time? 
Can you give the exact values for -Xmx, -Xms etc. and which JDK you are 
using ?



Hm...Maven 3.5.0 contains a fix for larger reactors which caused a 
bigger issues with large reactors (See 
https://github.com/khmarbaise/maven-test-project-generator).


I'm really astonished cause Maven 3.3.9 used more memory than 3.5.0 did 
(based on my tests)...Maybe the changes for the properties (revision, 
changelist, sha1) might be the culprit...




No major hickup at IDEs eclipse, Intellij, and netbeans


No major means there are some? Do you have some more details...


Kind regards
Karl Heinz Marbaise


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 

Re: How to use global checkstyle.xml that have SuppressionsFilter included

[Martin Hoeller]

On 09 Mai 2017, Gayan Weerakutti wrote:

> 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?

What about specifying the suprresion file also in your project:


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

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


I don't know if this works, but you could give it a try.

hth,
- martin


pgpkAo4yxW5v4.pgp
Description: Digitale Signatur von OpenPGP