Re: Special parameters - sha1

[Bernd Eckenfels]

You have to remember that POMs are also the model to describe artifacts, that 
why you should stay clear of profiles (especially if the influence artifact 
coordinates).

Personally I have good experience with actually releasing things, but if you 
want to keep the build identifier, then I would agree, that handling this in 
the build job is probably the best. You can have even two Parameterized jobs.

How are you planning to deal with the changed version numbers of dependencies?

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

From: Eric B 
Sent: Wednesday, November 15, 2017 4:30:06 AM
To: i...@soebes.de; Maven Users List
Subject: Re: Special  parameters - sha1

Hi,

Thanks for the additional insight.  I think I understand better now how
this works.   I'll try to explain my use case, and perhaps someone can
provide some ideas for best practices.

I started a pom refactoring because I wanted to add the enforcer-plugin for
a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
dev purposes, we have defined that anything in a release/ branch (Gitflow)
is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
Additionally, we use semantic versioning, so our versions read 4.7.0,
4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
branch needs to have a unique version.  I don't want to update the version
number for each build, so each build has to have a build number or sha1
attached to the version.

My build pipeline is very basic for the moment; it's a simple Jenkins
freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
simple as possible and always pass the same parameters to the maven build
process (to make it easier for others to understand).

I'm passing the following parameters to the maven build:
 -DbranchType=release
 -DbuildNumber=

maven.config:
-Drevision=5.0.0



My thought process is I could do the following - for the normal use case
(ie: dev branch):
${revision}${changelist}

  -SNAPSHOT



For a release:

  relelase
  

   branchType
   release

  
   
  
  ${buildNumber}
   




But now I see that won't work.  So I need to pass the buildnumber on the
command line as a SHA1 parameter.  But if I do that in this design, the
SNAPSHOT will also include the SHA1 which is not what I want.

So from what I can see, the only option is to modify the parameters on the
command line.  Which means I have to add some additional logic to my
Jenkins build.  This would be much easier if I had a Pipeline build but I
don't at the moment.  I was just looking to put the intelligence in the pom
so that anyone could easily read & understand it.

Any suggestions or recommendations would be greatly appreciated.  Is there
anyway to do this in the pom itself?

Thanks,

Eric

On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise 
wrote:

> Hi,
>
>
> I will give some more details cause I have created the docs /
> implementation and you mentioned my blog ;-)..
>
>
> On 14/11/17 03:12, Eric B wrote:
>
>> Following a long thread on this list, and a blog by khmarbaise (
>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> t-a-version-in-it/),
>> I'm still a little confused as to exactly what is allowed in the special
>> version tags for a maven pom.
>>
>> I know and realize that the 3 allowable tags are:
>>   - ${revision}
>>   - ${sha1}
>>   - ${changelist}
>>
>> However, from the thread and the blog, it seems that these properties
>> cannot be dependent on any other properties.
>>
>
> Correct.
>
>>
>> For example, this is fine:
>> ${revision}-${sha1}
>> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>>
>>
>> However, based on the further docs at
>> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>>
>
> which is not mentioned in the docs...
>
>
>> ${revision}-${sha1}
>>
>> 
>>   ${buildNumber}
>> 
>>
>>
>> and call it as -Drevision=1.2.3 -DbuildNumber=9
>>
>
> The problem is simply that buildNumber is not correctly overwritten from
> command and not correctly handled duing the model reading / interpolation
> at the correct time within Maven Core at the moment...
>
> At the moment this is only implemented for those special three
> properties...which already has performance impacts...which is also a reason
> not making that possible for all kind of properties...at the moment...
>
>
>>
>> Is anyone able to shed some light as to why this would be the case?  Why
>> can a property not be used to compute on of the 3 special vars?
>>
>> My use case is that I want to supply the build number to all my builds,
>> but
>> only append it to the version if a specific profile is enabled.  In my
>> mind, it would be simple - make the sha1 property empty by default, and in
>> my specific profile, set it to the buildnumber.   But based on my
>> understanding, this would fail.
>>
>> Is my only option in that case 

Re: Special parameters - sha1

[Eric B]

Hi,

Thanks for the additional insight.  I think I understand better now how
this works.   I'll try to explain my use case, and perhaps someone can
provide some ideas for best practices.

I started a pom refactoring because I wanted to add the enforcer-plugin for
a release candidate to ensure there are no SNAPSHOTs in the pom.  For our
dev purposes, we have defined that anything in a release/ branch (Gitflow)
is a release candidate.  Anything in the dev/ branch can be a SNAPSHOT.
Additionally, we use semantic versioning, so our versions read 4.7.0,
4.7.1, 5.0.0, 5.1.0, etc...  Consequently, each build coming from a release
branch needs to have a unique version.  I don't want to update the version
number for each build, so each build has to have a build number or sha1
attached to the version.

My build pipeline is very basic for the moment; it's a simple Jenkins
freestyle job (not a pipeline job yet).  Ideally, I'm trying to keep it as
simple as possible and always pass the same parameters to the maven build
process (to make it easier for others to understand).

I'm passing the following parameters to the maven build:
 -DbranchType=release
 -DbuildNumber=

maven.config:
-Drevision=5.0.0



My thought process is I could do the following - for the normal use case
(ie: dev branch):
${revision}${changelist}

  -SNAPSHOT



For a release:

  relelase
  

   branchType
   release

  
   
  
  ${buildNumber}
   




But now I see that won't work.  So I need to pass the buildnumber on the
command line as a SHA1 parameter.  But if I do that in this design, the
SNAPSHOT will also include the SHA1 which is not what I want.

So from what I can see, the only option is to modify the parameters on the
command line.  Which means I have to add some additional logic to my
Jenkins build.  This would be much easier if I had a Pipeline build but I
don't at the moment.  I was just looking to put the intelligence in the pom
so that anyone could easily read & understand it.

Any suggestions or recommendations would be greatly appreciated.  Is there
anyway to do this in the pom itself?

Thanks,

Eric

On Tue, Nov 14, 2017 at 8:42 AM, Karl Heinz Marbaise 
wrote:

> Hi,
>
>
> I will give some more details cause I have created the docs /
> implementation and you mentioned my blog ;-)..
>
>
> On 14/11/17 03:12, Eric B wrote:
>
>> Following a long thread on this list, and a blog by khmarbaise (
>> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-withou
>> t-a-version-in-it/),
>> I'm still a little confused as to exactly what is allowed in the special
>> version tags for a maven pom.
>>
>> I know and realize that the 3 allowable tags are:
>>   - ${revision}
>>   - ${sha1}
>>   - ${changelist}
>>
>> However, from the thread and the blog, it seems that these properties
>> cannot be dependent on any other properties.
>>
>
> Correct.
>
>>
>> For example, this is fine:
>> ${revision}-${sha1}
>> where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e
>>
>>
>> However, based on the further docs at
>> https://maven.apache.org/maven-ci-friendly.html, this design would fail:
>>
>
> which is not mentioned in the docs...
>
>
>> ${revision}-${sha1}
>>
>> 
>>   ${buildNumber}
>> 
>>
>>
>> and call it as -Drevision=1.2.3 -DbuildNumber=9
>>
>
> The problem is simply that buildNumber is not correctly overwritten from
> command and not correctly handled duing the model reading / interpolation
> at the correct time within Maven Core at the moment...
>
> At the moment this is only implemented for those special three
> properties...which already has performance impacts...which is also a reason
> not making that possible for all kind of properties...at the moment...
>
>
>>
>> Is anyone able to shed some light as to why this would be the case?  Why
>> can a property not be used to compute on of the 3 special vars?
>>
>> My use case is that I want to supply the build number to all my builds,
>> but
>> only append it to the version if a specific profile is enabled.  In my
>> mind, it would be simple - make the sha1 property empty by default, and in
>> my specific profile, set it to the buildnumber.   But based on my
>> understanding, this would fail.
>>
>> Is my only option in that case to design it as:
>>
>> ${artifactVersion}
>> 
>>${revision}
>> 
>>
>> 
>>buildNumber
>>
>>   ${revision}-${sha1}
>>
>> 
>>
>>
>> What is the reason for this limitation?  Is there any chance that this
>> limitation will be removed in the future?
>>
>
> The question is why do you need a profile for this? You can define
> defaults in .mvn/maven.config ...and during a CI build you can give other
> information via command line ?
>
> I don't see the need for a profile ? Maybe you can elaborate a little bit
> more what the real problem is ? ...
>
>
> Kind regards
> Karl Heinz Marbaise
>

Re: Special parameters - sha1

[Karl Heinz Marbaise]

Hi,


I will give some more details cause I have created the docs / 
implementation and you mentioned my blog ;-)..



On 14/11/17 03:12, Eric B wrote:

Following a long thread on this list, and a blog by khmarbaise (
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
I'm still a little confused as to exactly what is allowed in the special
version tags for a maven pom.

I know and realize that the 3 allowable tags are:
  - ${revision}
  - ${sha1}
  - ${changelist}

However, from the thread and the blog, it seems that these properties
cannot be dependent on any other properties.


Correct.


For example, this is fine:
${revision}-${sha1}
where mvn is called with -Drevision=1.2.3 -Dsha1=1a2b3c4e


However, based on the further docs at
https://maven.apache.org/maven-ci-friendly.html, this design would fail:


which is not mentioned in the docs...



${revision}-${sha1}


  ${buildNumber}



and call it as -Drevision=1.2.3 -DbuildNumber=9


The problem is simply that buildNumber is not correctly overwritten from 
command and not correctly handled duing the model reading / 
interpolation at the correct time within Maven Core at the moment...


At the moment this is only implemented for those special three 
properties...which already has performance impacts...which is also a 
reason not making that possible for all kind of properties...at the 
moment...





Is anyone able to shed some light as to why this would be the case?  Why
can a property not be used to compute on of the 3 special vars?

My use case is that I want to supply the build number to all my builds, but
only append it to the version if a specific profile is enabled.  In my
mind, it would be simple - make the sha1 property empty by default, and in
my specific profile, set it to the buildnumber.   But based on my
understanding, this would fail.

Is my only option in that case to design it as:

${artifactVersion}

   ${revision}



   buildNumber
   
  ${revision}-${sha1}
   



What is the reason for this limitation?  Is there any chance that this
limitation will be removed in the future?


The question is why do you need a profile for this? You can define 
defaults in .mvn/maven.config ...and during a CI build you can give 
other information via command line ?


I don't see the need for a profile ? Maybe you can elaborate a little 
bit more what the real problem is ? ...



Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Is there a plugin that allows me to modify existing jar manifest?

[Martin Gainty]

From: Eric B 
Sent: Monday, November 13, 2017 8:53 PM
To: Maven Users List
Subject: Re: Is there a plugin that allows me to modify existing jar manifest?

Martin,

Thanks, but the jar-plugin only allows to build a jar from the current
project (and set appropriate Manifest entries).  I'm looking to modify an
existing jar.  I could use the dependency plugin to retrieve the jar, and
unpack it, then point the jar-plugin to the unpacked dependency and have it
repkg the dependency from the unpacked classes, but was hoping for
something a little less manual.  For multiple dependencies, I would need to
write a different execution config for the jar-plugin which becomes quite
bloatsome for my pom.  I was just hoping for a cleaner/easier approach.

I started looking at the shade plugin with a manifest transformer, but that
too becomes individual execution configs.

MG>in JIRA for maven-execution-plugin suggest   as a parameter

MG>the other way is to have some sort of XSLT transform from pom.xml which will 
sub in new id to transformed_pom.xml

sed -i "s/$id/$new_id/" pom.xml


Parameterized Build - Jenkins - Jenkins 
Wiki
wiki.jenkins.io
Sometimes, it is useful/necessary to have your builds take several 
"parameters." Consider the following use case: You set up a test job on 
Jenkins, and it accepts a ...



Thanks,

Eric

On Mon, Nov 13, 2017 at 8:03 PM, Martin Gainty  wrote:

>
>
> 
> From: Eric B 
> Sent: Monday, November 13, 2017 5:51 PM
> To: Maven Users List
> Subject: Is there a plugin that allows me to modify existing jar manifest?
>
> I'm looking to modify an existing third-party JAR's Manifest file in my
> maven build.  Specifically, I have an Applet which has a dependency on
> these third party jars, and need to add some entries/permissions to the
> Manifest before I sign them for my Applet to use.
>
> I'm looking to add the following:
>
>all-permissions
> *
>
> * Library-Allowable-Codebase>
> true
> MyApp
>
> *
>
> MG>Eric...did you try  configuration parameter of
> maven-jar-plugin ?
> https://maven.apache.org/plugins/maven-jar-plugin/examples/
> manifest-customization.html
> Apache Maven JAR Plugin – Manifest customization ache.org/plugins/maven-jar-plugin/examples/manifest-customization.html>
> maven.apache.org
> The default contents of the manifest is described in the documentation for
> Maven Archiver. Starting with version 2.1, the maven-jar-plugin uses Maven
> Archiver 3.1.1 ...
>
> MG>https://maven.apache.org/shared/maven-archiver/index.html
> Apache Maven Archiver – Reference .org/shared/maven-archiver/index.html>
> maven.apache.org
> Apache Maven Archiver. The Maven Archiver is mainly used by plugins to
> handle packaging. The version numbers referenced in the Since column on
> this page are the ...
>
>
>
>
> I realize that these aren't particularly secure parameters, but right now
> I'm just trying to see what it will take to get this working.
>
> Is there a plugin that will allow me to modify an existing jar?  I'm using
> the dependency plugin to retrieve them from Maven, but once I have them
> locally, I'm not sure what to use to update the MANIFEST.  Is this
> something the assembly plugin can do easily?  I've looked at the assmbly
> descriptor reference, but don't see where/how it can be leveraged for this.
>
> Thanks,
>
> Eric
>

Re: Is there a plugin that allows me to modify existing jar manifest?

[Eric B]

Thanks Maxim.  Will take a look at how you are using the assembly.xml to
accomplish that.

Much appreciated.

Eric

On Nov 13, 2017 10:03 PM, "Maxim Solodovnik"  wrote:

> Hello Eric,
>
> we are using assembly plugin to achieve this:
> https://github.com/apache/openmeetings/blob/master/
> openmeetings-screenshare/pom.xml#L158
>
> On Tue, Nov 14, 2017 at 8:53 AM, Eric B  wrote:
>
> > Martin,
> >
> > Thanks, but the jar-plugin only allows to build a jar from the current
> > project (and set appropriate Manifest entries).  I'm looking to modify an
> > existing jar.  I could use the dependency plugin to retrieve the jar, and
> > unpack it, then point the jar-plugin to the unpacked dependency and have
> it
> > repkg the dependency from the unpacked classes, but was hoping for
> > something a little less manual.  For multiple dependencies, I would need
> to
> > write a different execution config for the jar-plugin which becomes quite
> > bloatsome for my pom.  I was just hoping for a cleaner/easier approach.
> >
> > I started looking at the shade plugin with a manifest transformer, but
> that
> > too becomes individual execution configs.
> >
> > Thanks,
> >
> > Eric
> >
> > On Mon, Nov 13, 2017 at 8:03 PM, Martin Gainty 
> > wrote:
> >
> > >
> > >
> > > 
> > > From: Eric B 
> > > Sent: Monday, November 13, 2017 5:51 PM
> > > To: Maven Users List
> > > Subject: Is there a plugin that allows me to modify existing jar
> > manifest?
> > >
> > > I'm looking to modify an existing third-party JAR's Manifest file in my
> > > maven build.  Specifically, I have an Applet which has a dependency on
> > > these third party jars, and need to add some entries/permissions to the
> > > Manifest before I sign them for my Applet to use.
> > >
> > > I'm looking to add the following:
> > >
> > >all-permissions
> > > *
> > >
> > > * > > Library-Allowable-Codebase>
> > > true
> > > MyApp
> > >
> > > *
> > >
> > > MG>Eric...did you try  configuration parameter of
> > > maven-jar-plugin ?
> > > https://maven.apache.org/plugins/maven-jar-plugin/examples/
> > > manifest-customization.html
> > > Apache Maven JAR Plugin – Manifest customization > > ache.org/plugins/maven-jar-plugin/examples/manifest-customization.html
> >
> > > maven.apache.org
> > > The default contents of the manifest is described in the documentation
> > for
> > > Maven Archiver. Starting with version 2.1, the maven-jar-plugin uses
> > Maven
> > > Archiver 3.1.1 ...
> > >
> > > MG>https://maven.apache.org/shared/maven-archiver/index.html
> > > Apache Maven Archiver – Reference > > .org/shared/maven-archiver/index.html>
> > > maven.apache.org
> > > Apache Maven Archiver. The Maven Archiver is mainly used by plugins to
> > > handle packaging. The version numbers referenced in the Since column on
> > > this page are the ...
> > >
> > >
> > >
> > >
> > > I realize that these aren't particularly secure parameters, but right
> now
> > > I'm just trying to see what it will take to get this working.
> > >
> > > Is there a plugin that will allow me to modify an existing jar?  I'm
> > using
> > > the dependency plugin to retrieve them from Maven, but once I have them
> > > locally, I'm not sure what to use to update the MANIFEST.  Is this
> > > something the assembly plugin can do easily?  I've looked at the
> assmbly
> > > descriptor reference, but don't see where/how it can be leveraged for
> > this.
> > >
> > > Thanks,
> > >
> > > Eric
> > >
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>