Re: Special parameters - sha1

[Bernd Eckenfels]

Hello,

>From maven points of view it needs to construct a complete model before 
>operating on it. That it is why it cannot dynamically calculate the values of 
>nested properties. So the 3 values are picked to be allowed to be specified 
>externally, with the understanding that they don’t need to be calculated by 
>maven.

However nothing stops you from dynamically constructing the values from outside 
(with Shell variables or pgrammatically with expressionism your CI Seever)

  mvn -Drevision="-$DATE-$BUildNumber" -Dchangelist="-nightly" test

1.2.3${revision}${changelist}

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

From: Eric B 
Sent: Tuesday, November 14, 2017 4:16:08 AM
To: Maven Users List
Subject: Re: Special  parameters - sha1

Bernd,

Is my understanding correct though?  These three properties cannot contain
any property values?  They can only contain constants?  Can they contain
other command line values, or not even?

Can you elaborate why it was deemed necessary to restrict the expansion to
a fixed set?  What was the reasoning behind that?

Thanks,

Eric


On Mon, Nov 13, 2017 at 9:21 PM, Bernd Eckenfels 
wrote:

> You can use the 3 Properties in any way you want it, their name suggest a
> certain content, and it was deemed necessary to restrict the expansion to a
> fixed set. so the 3 have been picked to give some guidance on what are sane
> modifiers.
>
> You will most likely use revision for the Version and changelist or sha
> for the incremental builds, but you can also cram everything into revision,
> Maven does not really care how you use them (as long as you use nothing
> else)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric B 
> Sent: Tuesday, November 14, 2017 3:12:21 AM
> To: Maven Users List
> Subject: Special  parameters - sha1
>
> 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.
>
> 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:
>
> ${revision}-${sha1}
>
> 
>  ${buildNumber}
> 
>
>
> and call it as -Drevision=1.2.3 -DbuildNumber=9
>
>
> 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?
>
> Thanks,
>
> Eric
>

Re: Special parameters - sha1

[Eric B]

Bernd,

Is my understanding correct though?  These three properties cannot contain
any property values?  They can only contain constants?  Can they contain
other command line values, or not even?

Can you elaborate why it was deemed necessary to restrict the expansion to
a fixed set?  What was the reasoning behind that?

Thanks,

Eric


On Mon, Nov 13, 2017 at 9:21 PM, Bernd Eckenfels 
wrote:

> You can use the 3 Properties in any way you want it, their name suggest a
> certain content, and it was deemed necessary to restrict the expansion to a
> fixed set. so the 3 have been picked to give some guidance on what are sane
> modifiers.
>
> You will most likely use revision for the Version and changelist or sha
> for the incremental builds, but you can also cram everything into revision,
> Maven does not really care how you use them (as long as you use nothing
> else)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> From: Eric B 
> Sent: Tuesday, November 14, 2017 3:12:21 AM
> To: Maven Users List
> Subject: Special  parameters - sha1
>
> 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.
>
> 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:
>
> ${revision}-${sha1}
>
> 
>  ${buildNumber}
> 
>
>
> and call it as -Drevision=1.2.3 -DbuildNumber=9
>
>
> 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?
>
> Thanks,
>
> Eric
>

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

[Maxim Solodovnik]

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

Re: Special parameters - sha1

[Bernd Eckenfels]

You can use the 3 Properties in any way you want it, their name suggest a 
certain content, and it was deemed necessary to restrict the expansion to a 
fixed set. so the 3 have been picked to give some guidance on what are sane 
modifiers.

You will most likely use revision for the Version and changelist or sha for the 
incremental builds, but you can also cram everything into revision, Maven does 
not really care how you use them (as long as you use nothing else)

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

From: Eric B 
Sent: Tuesday, November 14, 2017 3:12:21 AM
To: Maven Users List
Subject: Special  parameters - sha1

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.

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:

${revision}-${sha1}


 ${buildNumber}



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


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?

Thanks,

Eric

Special parameters - sha1

[Eric B]

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.

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:

${revision}-${sha1}


 ${buildNumber}



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


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?

Thanks,

Eric

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

[Eric B]

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
>

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

[Martin Gainty]

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
*

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

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

[Eric B]

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
*

*
true
MyApp

*

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