[ANN] Apache Maven Shade Plugin 3.5.1 Released

[Slawomir Jaranowski]

The Apache Maven team is pleased to announce the release of the Apache
Maven Shade Plugin, version 3.5.1

https://maven.apache.org/plugins/maven-shade-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-shade-plugin
  3.5.1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-shade-plugin/download.cgi

Release Notes - Maven Shade Plugin - Version 3.5.1

** Bug
* [MSHADE-454] - Shade Plugin does not work with JDK 20

** Improvement
* [MSHADE-459] - Prepare to build and pass tests with Java 21

** Task
* [MSHADE-458] - Refresh download page

** Dependency upgrade
* [MSHADE-457] - Upgrade Parent to 40

Enjoy,

-The Apache Maven team

Re: passing compiler args via a properties file

[Stanimir Stamenkov]

Sun, 24 Sep 2023 20:01:14 +0200, /Thomas Broyer/:


ErrorProne itself doesn't support @file arguments, so I think the question
remains unanswered: can Maven load a property's value from a file?
(possibly through a plugin; I have looked at build-helper-maven-plugin and
apparently it doesn't support it)


There's also a "Properties Maven Plugin":

https://www.mojohaus.org/properties-maven-plugin/

--
Stanimir

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

Re: passing compiler args via a properties file

[Thomas Broyer]

On Sun, Sep 24, 2023 at 7:49 PM Stanimir Stamenkov
 wrote:

> I've just noticed you're providing multiple arguments in a single 
> element – I'm not sure if this is supposed to work like that.


It is; this is how -Xplugin: works; those are arguments to the ErrorProne
plugins, not to javac itself:
https://docs.oracle.com/en/java/javase/21/docs/specs/man/javac.html#option-Xplugin

This also means that using @file wouldn't really solve the problem, as the
whole -Xplugin:ErrorProne and its arguments would still have to be on a
single line.

ErrorProne itself doesn't support @file arguments, so I think the question
remains unanswered: can Maven load a property's value from a file?
(possibly through a plugin; I have looked at build-helper-maven-plugin and
apparently it doesn't support it)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 

Re: passing compiler args via a properties file

[Stanimir Stamenkov]

Sun, 24 Sep 2023 18:04:51 +0200, /Delany/:


Thank you. Its not happening though. I also tried it from the pom, so
-Xplugin:ErrorProne
-XepExcludedPaths:.*/target/.* @${build.root}/ep.config


@files are Java 9+ feature for tools other than javadoc – just making 
sure you're not using Java 8 here.


If @file is specified it must exist, although it could be empty.  If the 
file doesn't exist the tool would fail.


I've just noticed you're providing multiple arguments in a single  
element – I'm not sure if this is supposed to work like that.  Maybe try:


  -Xplugin:ErrorProne
  -XepExcludedPaths:.*target.*
  @${build.root}/ep.config


Made more difficult by lack of visibility what's going on with the javac
processors.


mvn -X (--debug) could be overwhelming but could possibly provide 
insight of what's happening.


--
Stanimir

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

Re: passing compiler args via a properties file

[Delany]

Thank you. Its not happening though. I also tried it from the pom, so
-Xplugin:ErrorProne
-XepExcludedPaths:.*/target/.* @${build.root}/ep.config

Made more difficult by lack of visibility what's going on with the javac
processors.


On Sun, 24 Sept 2023 at 16:23, Stanimir Stamenkov
 wrote:

> [With some more context from the original message.]
>
> Sun, 24 Sep 2023 15:45:49 +0200, /Stanimir Stamenkov/:
> > Sun, 24 Sep 2023 15:45:49 +0200, /Delany/:
> >
> >> I can also quickly run a build to catch on issue
> >> that I'm trying to eradicate by adding
> >> -Dep="-XepDisableAllChecks -Xep:ReferenceEquality:ERROR"
> >>
> >> But having all those rules on one line makes reviewing changes a pain.
> >> I don't really want to config the whole build with the compiler
> arguments.
> >>
> >> Is there a way to specify these in a properties file and have each
> >> argument on its own line?
> >
> > Have you tried using @file (a-la javadoc options):
> >
> >
> https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#command-line-argument-files
>
> Maybe:
>
> -Dep=@myoptions
>
> And in "myoptions" file:
>
> -XepDisableAllChecks
> -Xep:ReferenceEquality:ERROR
>
> --
> Stanimir
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: passing compiler args via a properties file

[Stanimir Stamenkov]

[With some more context from the original message.]

Sun, 24 Sep 2023 15:45:49 +0200, /Stanimir Stamenkov/:

Sun, 24 Sep 2023 15:45:49 +0200, /Delany/:

I can also quickly run a build to catch on issue 
that I'm trying to eradicate by adding

-Dep="-XepDisableAllChecks -Xep:ReferenceEquality:ERROR"

But having all those rules on one line makes reviewing changes a pain.
I don't really want to config the whole build with the compiler arguments.

Is there a way to specify these in a properties file and have each 
argument on its own line?


Have you tried using @file (a-la javadoc options):

https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#command-line-argument-files


Maybe:

   -Dep=@myoptions

And in "myoptions" file:

-XepDisableAllChecks
-Xep:ReferenceEquality:ERROR

--
Stanimir

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

Re: passing compiler args via a properties file

[Stanimir Stamenkov]

Sun, 24 Sep 2023 15:45:49 +0200, /Delany/:


[...]
Is there a way to specify these in a properties file and have each argument 
on its own line?


Have you tried using @file (a-la javadoc options):

https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#command-line-argument-files

--
Stanimir

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

passing compiler args via a properties file

[Delany]

Hi,

Passing a few arguments to the compiler is done easily enough through the
pom,
but when there are many arguments it starts to gets hairy,
especially when I'm configuring a plugin in multiple levels of inheritance.

For example, there are many bugpatterns in errorprone
https://errorprone.info/docs/flags

I want my build pom to set the basic settings for the compiler


  -Xlint:all,-serial,-processing
  -XDcompilePolicy=byfile
  -Xplugin:ErrorProne -XepExcludedPaths:.*/target/.* ${ep}


And then my project can decide whether it want to override errorprone
default levels for specific rules

https://maven.apache.org/configure.html
I can add this one line to maven.config
-Dep=-Xep:ArgumentSelectionDefectChecker:WARN -Xep:AssertFalse:WARN
-Xep:EqualsHashCode:WARN -Xep:AvoidObjectArrays:WARN
-Xep:BareDotMetacharacter:WARN -Xep:CatchAndPrintStackTrace:WARN
-Xep:OperatorPrecedence:WARN -Xep:StatementSwitchToExpressionSwitch:WARN
-Xep:SuppressWarningsWithoutExplanation:WARN

And that does the job. I can also quickly run a build to catch on issue
that I'm trying to eradicate by adding
-Dep="-XepDisableAllChecks -Xep:ReferenceEquality:ERROR"

But having all those rules on one line makes reviewing changes a pain.
I don't really want to config the whole build with the compiler arguments.

Is there a way to specify these in a properties file and have each argument
on its own line?

Kind regards,
Delany

Re: maven-build-cache, immutable docker tags, etc

[Ben Tatham]

Thanks, Francois.  That would have been great for our original problem, but
how I can I leverage that for build cache issues?

On Sun, Sept 24, 2023, 5:14 a.m. Francois Marot 
wrote:

> Just a suggestion: you could use ci-friendly Maven to pass in a version
> depending on the commit Id/sha1 on the command line. Like mvn
> -Drevision=
> More info:
> https://maven.apache.org/maven-ci-friendly.html
>
> Regards
>
> Le jeu. 21 sept. 2023, 15:49, Ben Tatham  .invalid>
> a écrit :
>
> > Hi,
> > I'm loving the ideas in the maven-build-cache, but I'm running into some
> > circular build issues that are blocking us from using it at the moment.
> >
> > In many of our projects, we deploy docker images. Ideally, we would like
> to
> > keep our docker images immutable. To achieve that, we have extra maven
> > plugins that create unique SNAPSHOT version numbers (based on jira issue
> > ids, git commit hashes, and/our CI build numbers).  We do this for docker
> > image immutability, but also to avoid SNAPSHOT collisions when multiple
> > developers are working at the same time in the same project, but still be
> > able to deploy the snapshot artifacts for other reasons (temporary test
> > deployments, sharing libraries as snapshots while still in development
> > across projects, etc).
> >
> > But that solution creates unique maven versions in CI for every build,
> > which of course then contradicts using maven-build-cache, since the
> version
> > is always different in CI.
> >
> > To use maven-build-cache, we would just go back to using standard
> -SNAPSHOT
> > builds, but then we have to solve our original issues a different way.
> >
> > (Sadly, AWS ECR only allows setting immutability at the registry level. I
> > looked at nexus as a docker registry, and it seems to be even higher at
> the
> > whole docker repo level. (We wish we could set immutability of images
> based
> > on the tag - ie allow -SNAPSHOT tags to mutable, but nothing else))
> >
> > One idea we have is to use a different docker registry for snapshot vs
> > release builds, but since maven properties are evaluated at the beginning
> > of the maven lifecycle, we cannot change the parameters sent to maven
> > plugins that due to the docker builds once the build starts. Thus, we
> would
> > have to do something outside of maven to detect, eg, if the build is a
> > snapshot and choose a different docker registry there and pass it on the
> > command line. We would love this to be an all-maven solution.
> >
> > Does anyone else run into similar issues with maven-build-cache?  Is
> there
> > some weird way we can ignore the project.version altogether on the
> > maven-build-cache (that seems very odd, for sure though)?  Other ideas?
> >
> > Thanks,
> >
> > Ben
> >
> > [image: -] 
> > [image: -]  [image: -]
> >  >
> > [image:
> > -] 
> >
> > Ben Tatham
> > Principal Software Developer
> > Nanometrics
> > bentat...@nanometrics.ca
> >
> > --
> > This message is intended exclusively for the individual or entity to
> which
> > it is addressed. This communication may contain information that is
> > proprietary, privileged, confidential or otherwise legally exempt from
> > disclosure. If you are not the named addressee, or have been
> inadvertently
> > and erroneously referenced in the address line, you are not authorized to
> > read, print, retain, copy or disseminate this message or any part of it.
> > If
> > you have received this message in error, please notify the sender
> > immediately by e-mail and delete all copies of the message.
> >
>

-- 
This message is intended exclusively for the individual or entity to which 
it is addressed. This communication may contain information that is 
proprietary, privileged, confidential or otherwise legally exempt from 
disclosure. If you are not the named addressee, or have been inadvertently 
and erroneously referenced in the address line, you are not authorized to 
read, print, retain, copy or disseminate this message or any part of it. If 
you have received this message in error, please notify the sender 
immediately by e-mail and delete all copies of the message.

Re: maven-build-cache, immutable docker tags, etc

[Francois Marot]

Just a suggestion: you could use ci-friendly Maven to pass in a version
depending on the commit Id/sha1 on the command line. Like mvn
-Drevision=
More info:
https://maven.apache.org/maven-ci-friendly.html

Regards

Le jeu. 21 sept. 2023, 15:49, Ben Tatham 
a écrit :

> Hi,
> I'm loving the ideas in the maven-build-cache, but I'm running into some
> circular build issues that are blocking us from using it at the moment.
>
> In many of our projects, we deploy docker images. Ideally, we would like to
> keep our docker images immutable. To achieve that, we have extra maven
> plugins that create unique SNAPSHOT version numbers (based on jira issue
> ids, git commit hashes, and/our CI build numbers).  We do this for docker
> image immutability, but also to avoid SNAPSHOT collisions when multiple
> developers are working at the same time in the same project, but still be
> able to deploy the snapshot artifacts for other reasons (temporary test
> deployments, sharing libraries as snapshots while still in development
> across projects, etc).
>
> But that solution creates unique maven versions in CI for every build,
> which of course then contradicts using maven-build-cache, since the version
> is always different in CI.
>
> To use maven-build-cache, we would just go back to using standard -SNAPSHOT
> builds, but then we have to solve our original issues a different way.
>
> (Sadly, AWS ECR only allows setting immutability at the registry level. I
> looked at nexus as a docker registry, and it seems to be even higher at the
> whole docker repo level. (We wish we could set immutability of images based
> on the tag - ie allow -SNAPSHOT tags to mutable, but nothing else))
>
> One idea we have is to use a different docker registry for snapshot vs
> release builds, but since maven properties are evaluated at the beginning
> of the maven lifecycle, we cannot change the parameters sent to maven
> plugins that due to the docker builds once the build starts. Thus, we would
> have to do something outside of maven to detect, eg, if the build is a
> snapshot and choose a different docker registry there and pass it on the
> command line. We would love this to be an all-maven solution.
>
> Does anyone else run into similar issues with maven-build-cache?  Is there
> some weird way we can ignore the project.version altogether on the
> maven-build-cache (that seems very odd, for sure though)?  Other ideas?
>
> Thanks,
>
> Ben
>
> [image: -] 
> [image: -]  [image: -]
> 
> [image:
> -] 
>
> Ben Tatham
> Principal Software Developer
> Nanometrics
> bentat...@nanometrics.ca
>
> --
> This message is intended exclusively for the individual or entity to which
> it is addressed. This communication may contain information that is
> proprietary, privileged, confidential or otherwise legally exempt from
> disclosure. If you are not the named addressee, or have been inadvertently
> and erroneously referenced in the address line, you are not authorized to
> read, print, retain, copy or disseminate this message or any part of it.
> If
> you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.
>