[ANN] Apache Maven Shade Plugin 3.6.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.6.0 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. 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.6.0 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.6.0 ** Bug * [MSHADE-428] - Typo causes mysterious NPE in build ** New Feature * [MSHADE-478] - Add ability to inject extra artifacts into shaded output ** Task * [MSHADE-473] - Drop legacy and superfluous deps: maven-dependency-tree and commons-collections4 ** Dependency upgrade * [MSHADE-474] - Align dependencies with Maven 3 (as this is Maven3 plugin) * [MSHADE-475] - Upgrade commons-io to 2.16.1 * [MSHADE-476] - Upgrade commons-compress to 1.26.2 * [MSHADE-477] - (test) Upgrade test dependencies Have fun, -The Apache Maven team
[ANN] Apache Maven Shade Plugin 3.5.3 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.5.3 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. 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.3 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.3 ** Bug * [MSHADE-471] - still timestamp issues with timezones (DST) ** Task * [MSHADE-472] - upgrade parent POM ** Dependency upgrade * [MSHADE-470] - Upgrade ASM to 9.7 (Java 23) Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-shade-plugin createSourcesJar creates a source jar of dependencies but not the main project
Thank you very much, Alexander! It solved the issue! Toshiya On Thu, Mar 28, 2024 at 4:53 PM Alexander Kriegisch < alexan...@kriegisch.name> wrote: > Shade needs an original sources JAR as input for 'createSourcesJar'. Make > sure to add Maven Source Plugin to your build and put it above Shade in the > 'plugins' section to ensure that both of them are exeuted in the correct > order during the 'package' phase. > > > org.apache.maven.plugins > maven-source-plugin > 3.3.0 > > > module-source-jar > > jar > > > > > > BTW, in a multi-module project, the requirement to create source JARs > applies to all modules the aggregate JAR depends on and is meant to shade. > Alternatively, you could use Maven Assembly to first create one aggregate > sources JAR and then let Shade find that one. > -- > Alexander Kriegisch > https://scrum-master.de > > > Toshiya Kobayashi schrieb am 28.03.2024 06:22 (GMT +01:00): > > > Hello, > > > > I use maven-shade-plugin to create an uber jar and its source jar with > > . > > > > https://github.com/tkobayas/shade-test/blob/main/pom.xml > > ``` > > > > org.apache.maven.plugins > > maven-shade-plugin > > 3.5.2 > > > > > > source-jar > > > > shade > > > > > > true > > > > > > org.ow2.asm:asm > > > > > > > > > > > > > > ``` > > > > The uber jar (shade-test-1.0-SNAPSHOT.jar) contains both the project > > classes (App.class) and dependency classes (org.ow2.asm:asm), but the > > source jar (shade-test-1.0-SNAPSHOT-sources.jar) contains only > > dependency class sources, not the project class sources (App.java). > > > > Is it expected? Am I overlooking any configuration? > > > > Any help/suggestions would be appreciated. > > > > Thanks! > > Toshiya > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-shade-plugin createSourcesJar creates a source jar of dependencies but not the main project
Shade needs an original sources JAR as input for 'createSourcesJar'. Make sure to add Maven Source Plugin to your build and put it above Shade in the 'plugins' section to ensure that both of them are exeuted in the correct order during the 'package' phase. org.apache.maven.plugins maven-source-plugin 3.3.0 module-source-jar jar BTW, in a multi-module project, the requirement to create source JARs applies to all modules the aggregate JAR depends on and is meant to shade. Alternatively, you could use Maven Assembly to first create one aggregate sources JAR and then let Shade find that one. -- Alexander Kriegisch https://scrum-master.de Toshiya Kobayashi schrieb am 28.03.2024 06:22 (GMT +01:00): > Hello, > > I use maven-shade-plugin to create an uber jar and its source jar with > . > > https://github.com/tkobayas/shade-test/blob/main/pom.xml > ``` > > org.apache.maven.plugins > maven-shade-plugin > 3.5.2 > > > source-jar > > shade > > > true > > > org.ow2.asm:asm > > > > > > > ``` > > The uber jar (shade-test-1.0-SNAPSHOT.jar) contains both the project > classes (App.class) and dependency classes (org.ow2.asm:asm), but the > source jar (shade-test-1.0-SNAPSHOT-sources.jar) contains only > dependency class sources, not the project class sources (App.java). > > Is it expected? Am I overlooking any configuration? > > Any help/suggestions would be appreciated. > > Thanks! > Toshiya > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-shade-plugin createSourcesJar creates a source jar of dependencies but not the main project
Hello, I use maven-shade-plugin to create an uber jar and its source jar with . https://github.com/tkobayas/shade-test/blob/main/pom.xml ``` org.apache.maven.plugins maven-shade-plugin 3.5.2 source-jar shade true org.ow2.asm:asm ``` The uber jar (shade-test-1.0-SNAPSHOT.jar) contains both the project classes (App.class) and dependency classes (org.ow2.asm:asm), but the source jar (shade-test-1.0-SNAPSHOT-sources.jar) contains only dependency class sources, not the project class sources (App.java). Is it expected? Am I overlooking any configuration? Any help/suggestions would be appreciated. Thanks! Toshiya
[ANN] Apache Maven Shade Plugin 3.5.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.5.2 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. 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.2 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.2 ** Bug * [MSHADE-420] - Reproducible Builds timestamp issue in some cases * [MSHADE-462] - 3.5.1 not compatible with 3.4.1: The version cannot be empty * [MSHADE-467] - Dependency-reduced POM with missing exclusions in concurrent build * [MSHADE-469] - Cannot generate a jar since switching from 3.4.1 to 3.5.x ** Improvement * [MSHADE-468] - add plugin system requirements history section ** Dependency upgrade * [MSHADE-463] - Bump asmVersion from 9.5 to 9.6 * [MSHADE-464] - Maven 3.6.3 as minimum requirements Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shade Plugin 3.5.1 Released
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
[ANN] Maven Shade Plugin 3.5.0 released
The Apache Maven team is pleased to announce the release of the Maven Shade Plugin 3.5.0 https://maven.apache.org/plugins/maven-shade-plugin/ Release Notes - Maven Shade Plugin - Version 3.5.0 ** Bug * [MSHADE-443] - Fix problems with shadeSourcesContent ** New Feature * [MSHADE-400] - Self-minimisation with custom entry points ** Task * [MSHADE-438] - Update to Maven 3.2.5 * [MSHADE-450] - Upgrade to parent POM 39, reformat ** Dependency upgrade * [MSHADE-446] - Update dependencies * [MSHADE-447] - Move off forked Guice * [MSHADE-448] - Upgrade ASM to 9.5 * [MSHADE-449] - Upgrade plexus-utils to 3.5.1 Have fun, -The Apache Maven team
[ANN] Apache Maven Shade Plugin 3.4.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 3.4.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.4.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 3.4.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12352285 Release Notes - Maven Shade Plugin - Version 3.4.1 ** Bug * [MSHADE-366] - The warning "Access denied" during 'minimizeJar' is always printed * [MSHADE-413] - Maven shade plugin enters endless loop * [MSHADE-417] - Fix null bytes appended to small files by maven-shade-plugin ** Task * [MSHADE-422] - Remove usage of deprecated Plugin#getGoals() * [MSHADE-430] - Remove usage of deprecated ModelBase#getReports() * [MSHADE-431] - Use a caching output stream * [MSHADE-432] - Duplicate services entries can be generated Enjoy, -- Guillaume Nodet on behalf of the Apache Maven Team
Re: maven-shade-plugin: relocation of package names in resource files (unfortunately not in META-INF/services dir)
You can create your own transformer implementation and add it as a
dependency of the plugin (see sources there [1] to see what interface to
implement). not tested but should work
Maybe you can use a feature of the resources plugin see
https://maven.apache.org/plugins/maven-resources-plugin/examples/custom-resource-filters.html
Another option is to use a feature of the resources plugin to create your
own filtering (see [2])
Note the documentation is not up2date. You should be able to use some
annotations such
@Singleton
@Named("itFilter")
public class ItFilter implements MavenResourcesFiltering
and so you do not need the plugin plexus-component-metadata
HTH
Olivier
[1]
https://github.com/apache/maven-shade-plugin/tree/master/src/main/java/org/apache/maven/plugins/shade/resource
[2]
https://maven.apache.org/plugins/maven-resources-plugin/examples/custom-resource-filters.html
On Mon, 5 Sept 2022 at 06:51, PJ Fanning
wrote:
> Hi everyone,
>
> I have another question about maven-shade-plugin. I'm wondering if there
> is an equivalent of ServicesResourceTransformer that can be used on
> resource files that appear outside META-INF/services dir.
>
> My use case involves avro-compiler.jar. It has Velocity templates that are
> used to generate Java classes and I need to modify to relocate the package
> names - the same relocation that maven-shade-plugin already does for the
> class files.
>
> Any pointers would be appreciated.
>
> Regards,
> PJ
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
maven-shade-plugin: relocation of package names in resource files (unfortunately not in META-INF/services dir)
Hi everyone, I have another question about maven-shade-plugin. I'm wondering if there is an equivalent of ServicesResourceTransformer that can be used on resource files that appear outside META-INF/services dir. My use case involves avro-compiler.jar. It has Velocity templates that are used to generate Java classes and I need to modify to relocate the package names - the same relocation that maven-shade-plugin already does for the class files. Any pointers would be appreciated. Regards, PJ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-shade-plugin: excluding transitive dependencies from shade jar but having them appear in the pom.xml for the shade jar?
Thanks Delany. That was exactly what I was looking for. On Sunday 4 September 2022 at 18:44:18 IST, Delany wrote: hi PJ. You can do like this: true org.apache.avro:avro Kind regards, Delany On Sun, 4 Sept 2022 at 19:05, PJ Fanning wrote: > Hi everyone, > Apologies if this has been answered before but I searched around and > couldn't find an answer. > For Apache Hadoop, I'm looking to shade Apache Avro jar, relocating the > avro classes to a new package name. > This new jar would be published to Maven Central and used by Hadoop. > The aim is not to include Jackson and other classes from transitive > dependencies of Avro but that the pom file for the new jar would include > the transitive dependencies from Avro. > > My PR is at https://github.com/apache/hadoop-thirdparty/pull/21 > > Neither the pom.xml nor the dependency-reduced-pom.xml have the transitive > dependencies listed. > > Would anyone be able to suggest how the dependencies excluded from the > shade jar can be exposed as dependencies in the pom.xml? > > Regards, > PJ > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-shade-plugin: excluding transitive dependencies from shade jar but having them appear in the pom.xml for the shade jar?
hi PJ. You can do like this: true org.apache.avro:avro Kind regards, Delany On Sun, 4 Sept 2022 at 19:05, PJ Fanning wrote: > Hi everyone, > Apologies if this has been answered before but I searched around and > couldn't find an answer. > For Apache Hadoop, I'm looking to shade Apache Avro jar, relocating the > avro classes to a new package name. > This new jar would be published to Maven Central and used by Hadoop. > The aim is not to include Jackson and other classes from transitive > dependencies of Avro but that the pom file for the new jar would include > the transitive dependencies from Avro. > > My PR is at https://github.com/apache/hadoop-thirdparty/pull/21 > > Neither the pom.xml nor the dependency-reduced-pom.xml have the transitive > dependencies listed. > > Would anyone be able to suggest how the dependencies excluded from the > shade jar can be exposed as dependencies in the pom.xml? > > Regards, > PJ > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
maven-shade-plugin: excluding transitive dependencies from shade jar but having them appear in the pom.xml for the shade jar?
Hi everyone, Apologies if this has been answered before but I searched around and couldn't find an answer. For Apache Hadoop, I'm looking to shade Apache Avro jar, relocating the avro classes to a new package name. This new jar would be published to Maven Central and used by Hadoop. The aim is not to include Jackson and other classes from transitive dependencies of Avro but that the pom file for the new jar would include the transitive dependencies from Avro. My PR is at https://github.com/apache/hadoop-thirdparty/pull/21 Neither the pom.xml nor the dependency-reduced-pom.xml have the transitive dependencies listed. Would anyone be able to suggest how the dependencies excluded from the shade jar can be exposed as dependencies in the pom.xml? Regards, PJ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-shade-plugin not including dependencies
On Sun, Jun 26, 2022 at 9:49 AM Alexander Kriegisch < alexan...@kriegisch.name> wrote: > > Firstly, you are not crerating a test JAR but a regular JAR with > application classes, so of course test-scoped dependencies like JUnit > are not going to be contained in the uber JAR. > Oh, right. Secondly, you are even explicitly excluding JUnit, so how could you > expect it to be included, even if it was not test-scoped? > Boy am I red in the face right now! I had copied that example from the web and hadn't noticed the exclusion statement. Thx for pointing out the obvious. All works now. Alain > > > junit:junit > > -- > Alexander Kriegisch > https://scrum-master.de > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: maven-shade-plugin not including dependencies
> I get a build success, but when I inspect the generated jar, I don’t > see the junit classes Firstly, you are not crerating a test JAR but a regular JAR with application classes, so of course test-scoped dependencies like JUnit are not going to be contained in the uber JAR. Secondly, you are even explicitly excluding JUnit, so how could you expect it to be included, even if it was not test-scoped? > junit:junit -- Alexander Kriegisch https://scrum-master.de - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-shade-plugin not including dependencies
I am trying to use maven-shade-plugin for the first time to create an uber-jar
and I can’t even get the simplest example to work.
For example, I created a simple pom based on the example at the top of this
page:
https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html
The main difference with my pom is that I added a dependency to junit to test
whether the shade plugin would include its classes in the jar. But when I run
this command:
mvn clean install -X
I get a build success, but when I inspect the generated jar, I don’t see the
junit classes:
$ jar -tf spike-uber-jar-0.1.0.jar
META-INF/
META-INF/MANIFEST.MF
META-INF/maven/
META-INF/maven/org.example/
META-INF/maven/org.example/spike-uber-jar/
META-INF/maven/org.example/spike-uber-jar/pom.xml
META-INF/maven/org.example/spike-uber-jar/pom.properties
Not sure what I am doing wrong. Below is the pom file:
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
org.example
spike-uber-jar
jar
0.1.0
org.apache.maven.plugins
maven-shade-plugin
3.3.0
package
shade
classworlds:classworlds
junit:junit
jmock:*
*:xml-apis
org.apache.maven:lib:tests
log4j:log4j:jar:
junit
junit
4.12
test
--
Alain Désilets
alain.desil...@nrc-cnrc.gc.ca<mailto:alain.desil...@nrc-cnrc.gc.ca>
Research Officer Agent de recherche
National Research CouncilConseil national de recherches du Canada
Digital Technologies ResearchCentre de recherche en technologies
Center digitales
Bldg M50 Édifice M50
1200 Montreal Road, Ottawa 1200 Chemin Montréal, Ottawa
K1A 0R6 K1A 0R6
long running threads from shade-plugin recently updated dep jdom2
Hi My build was taking unusually long (28m vs 9m) and it seemed to stall installing all artefacts at the end, so I pressed ctrl+\ to create a JVM profile and I noticed this long running thread. Any comments? "mvn-builder-artifactcommandline" #25 prio=5 os_prio=0 cpu=1302760.01ms elapsed=1412.09s tid=0x7f75e0345800 nid=0x1243e1 runnable [0x7f75a86c7000] java.lang.Thread.State: RUNNABLE at org.apache.maven.plugins.shade.pom.MavenJDOMWriter.insertAtPreferredLocation(MavenJDOMWriter.java:282) at org.apache.maven.plugins.shade.pom.MavenJDOMWriter.iterateExclusion(MavenJDOMWriter.java:498) at org.apache.maven.plugins.shade.pom.MavenJDOMWriter.updateDependency(MavenJDOMWriter.java:1343) at org.apache.maven.plugins.shade.pom.MavenJDOMWriter.iterateDependency(MavenJDOMWriter.java:396) at org.apache.maven.plugins.shade.pom.MavenJDOMWriter.updateModel(MavenJDOMWriter.java:1632) at org.apache.maven.plugins.shade.pom.MavenJDOMWriter.write(MavenJDOMWriter.java:2168) at org.apache.maven.plugins.shade.pom.PomWriter.write(PomWriter.java:75) at org.apache.maven.plugins.shade.mojo.ShadeMojo.rewriteDependencyReducedPomIfWeHaveReduction(ShadeMojo.java:1201) at org.apache.maven.plugins.shade.mojo.ShadeMojo.createDependencyReducedPom(ShadeMojo.java:1130) at org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:486) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:301) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:165) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:210) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:195) at java.util.concurrent.FutureTask.run( java.base@11.0.14.1/FutureTask.java:264) at java.util.concurrent.Executors$RunnableAdapter.call( java.base@11.0.14.1/Executors.java:515) at java.util.concurrent.FutureTask.run( java.base@11.0.14.1/FutureTask.java:264) at java.util.concurrent.ThreadPoolExecutor.runWorker( java.base@11.0.14.1/ThreadPoolExecutor.java:1128) at java.util.concurrent.ThreadPoolExecutor$Worker.run( java.base@11.0.14.1/ThreadPoolExecutor.java:628) at java.lang.Thread.run(java.base@11.0.14.1/Thread.java:829) Thanks Delany
[ANN] Apache Maven Shade Plugin Version 3.3.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 3.3.0 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.3.0 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 3.3.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348391=Text=12317921 * Bugs: * [MSHADE-252] - shadeSourcesContent is broken when combined with partial relocation * [MSHADE-396] - Improve SourceContent Shading * New Feature: * [MSHADE-36] - Add option to include dependency reduced POM instead of original one * Improvements: * [MSHADE-321] - Always respect 'createDependencyReducedPom' flag * [MSHADE-371] - Update Shade Apache[Notice/LICENSE]ResourceTransformer to use also [NOTICE/LICENSE].md * [MSHADE-373] - Source transformation on source jar can break OSGi resolution due to duplicated bundle name * [MSHADE-382] - Add an option to skip execution * [MSHADE-391] - Do not modify class files, if nothing was relocated * [MSHADE-405] - ShowOverlapping Uses http instead of https Tasks: * [MSHADE-389] - Get rid of old baggage * [MSHADE-390] - Implement Sisu index transformer * [MSHADE-401] - Improve ServiceResourceTransformer * [MSHADE-412] - SimpleRelocator can fail in NPE, in particular with manifest transformer Dependency upgrades: * [MSHADE-379] - Support Java 16 - upgrade ASM to 9.0 * [MSHADE-386] - Update JDependency to 2.6.0 * [MSHADE-407] - Update ASM to 9.2 to support Java 17 Enjoy - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: New release of Maven Shade Plugin
This isn't actually what we do. The ASF release is NOT a Git tag, but the source release ZIP file. Please retain the tag as-is. > Gesendet: Freitag, 27. August 2021 um 10:02 Uhr > Von: "Robert Scholte" > An: "Maven Users List" > Betreff: Re: New release of Maven Shade Plugin > > See the vote[1] > I'll remove the github tag to prevent more confusion > > thanks, > Robert > > [1] > https://lists.apache.org/thread.html/rb9f899586cf49fefffc291b028a14b5fa8e22797d79d2362bcdfb58c%40%3Cdev.maven.apache.org%3E > > > > -- Origineel bericht -- > Van: "Philipp Dallig" > Aan: users@maven.apache.org > Verzonden: 27-8-2021 09:40:47 > Onderwerp: Re: New release of Maven Shade Plugin > > >Hi > > > >Sorry for digging up this old mail thread. > >I'm also interesseted in a new maven-shade-plugin. > >I noticed the 3.3.0 git tag > >(https://github.com/apache/maven-shade-plugin/releases/tag/maven-shade-plugin-3.3.0), > > but this version doesn't seems to be published on maven central > >(https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-shade-plugin). > > > >I hope that we can move the tag to the latest version of the master branch, > >because I'm interesseted in new commits, which are improving the source code > >shading > >(https://github.com/apache/maven-shade-plugin/commit/1dca37c71649fa4f4aa110de3b78cc98d0e47eda) > > > >At the moment the missing release blocks quite important change in the > >apache/zeppelin. I created a JIRA ticket to track the progross > >(https://issues.apache.org/jira/browse/MSHADE-404). > > > >Best Regards > >Philipp > > > > > >On 2021/07/22 07:01:52, "Alexander Kriegisch" wrote: > > > Alexander Kriegisch schrieb am 22.07.2021 09:34 (GMT +07:00):> > > > > > > > MSHADE-366: Romain and I are still talking and working on a possible> > > > > basic implementation of self-shading. (I have started hacking around,> > > > > but it is not easy.) But in order to get rid of the warning, you could> > > > > merge https://github.com/apache/maven-shade-plugin/pull/104 as-is. then> > > > > you do not have to wait for me to finish the self-shading feature, > > > > which> > > > > IMO is out of scope for MSHADE-366 anyway.> > > > > > > I created MSHADE-400 on top of it and PR> > > > https://github.com/apache/maven-shade-plugin/pull/110, which can be> > > > reviewed already. I do not want to slow down the release process, which> > > > is why I expedited this today for everyone's convenience.> > > > > > > > MSHADE-396: https://github.com/apache/maven-shade-plugin/pull/105 is> > > > > ready for merge.> > > > > > > > > > > > > > > Tibor Digana schrieb am 22.07.2021 05:26 (GMT +07:00):> > > > > > > > > >> Can we cut a new release of m-shade-p? Is there any pending bug fix or> > > > >> improvement that you want to include in the release?> > > > > > > -> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org> > > > For additional commands, e-mail: users-h...@maven.apache.org> > > > > > > > > > >- > >To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >For additional commands, e-mail: users-h...@maven.apache.org > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New release of Maven Shade Plugin
See the vote[1] I'll remove the github tag to prevent more confusion thanks, Robert [1] https://lists.apache.org/thread.html/rb9f899586cf49fefffc291b028a14b5fa8e22797d79d2362bcdfb58c%40%3Cdev.maven.apache.org%3E -- Origineel bericht -- Van: "Philipp Dallig" Aan: users@maven.apache.org Verzonden: 27-8-2021 09:40:47 Onderwerp: Re: New release of Maven Shade Plugin Hi Sorry for digging up this old mail thread. I'm also interesseted in a new maven-shade-plugin. I noticed the 3.3.0 git tag (https://github.com/apache/maven-shade-plugin/releases/tag/maven-shade-plugin-3.3.0), but this version doesn't seems to be published on maven central (https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-shade-plugin). I hope that we can move the tag to the latest version of the master branch, because I'm interesseted in new commits, which are improving the source code shading (https://github.com/apache/maven-shade-plugin/commit/1dca37c71649fa4f4aa110de3b78cc98d0e47eda) At the moment the missing release blocks quite important change in the apache/zeppelin. I created a JIRA ticket to track the progross (https://issues.apache.org/jira/browse/MSHADE-404). Best Regards Philipp On 2021/07/22 07:01:52, "Alexander Kriegisch" wrote: > Alexander Kriegisch schrieb am 22.07.2021 09:34 (GMT +07:00):> > > > MSHADE-366: Romain and I are still talking and working on a possible> > > basic implementation of self-shading. (I have started hacking around,> > > but it is not easy.) But in order to get rid of the warning, you could> > > merge https://github.com/apache/maven-shade-plugin/pull/104 as-is. then> > > you do not have to wait for me to finish the self-shading feature, which> > > IMO is out of scope for MSHADE-366 anyway.> > > I created MSHADE-400 on top of it and PR> > https://github.com/apache/maven-shade-plugin/pull/110, which can be> > reviewed already. I do not want to slow down the release process, which> > is why I expedited this today for everyone's convenience.> > > > MSHADE-396: https://github.com/apache/maven-shade-plugin/pull/105 is> > > ready for merge.> > > > > > > > > Tibor Digana schrieb am 22.07.2021 05:26 (GMT +07:00):> > > > > >> Can we cut a new release of m-shade-p? Is there any pending bug fix or> > >> improvement that you want to include in the release?> > > -> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org> > For additional commands, e-mail: users-h...@maven.apache.org> > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New release of Maven Shade Plugin
Hi Sorry for digging up this old mail thread. I'm also interesseted in a new maven-shade-plugin. I noticed the 3.3.0 git tag (https://github.com/apache/maven-shade-plugin/releases/tag/maven-shade-plugin-3.3.0), but this version doesn't seems to be published on maven central (https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-shade-plugin). I hope that we can move the tag to the latest version of the master branch, because I'm interesseted in new commits, which are improving the source code shading (https://github.com/apache/maven-shade-plugin/commit/1dca37c71649fa4f4aa110de3b78cc98d0e47eda) At the moment the missing release blocks quite important change in the apache/zeppelin. I created a JIRA ticket to track the progross (https://issues.apache.org/jira/browse/MSHADE-404). Best Regards Philipp On 2021/07/22 07:01:52, "Alexander Kriegisch" wrote: > Alexander Kriegisch schrieb am 22.07.2021 09:34 (GMT +07:00):> > > > MSHADE-366: Romain and I are still talking and working on a possible> > > basic implementation of self-shading. (I have started hacking around,> > > but it is not easy.) But in order to get rid of the warning, you could> > > merge https://github.com/apache/maven-shade-plugin/pull/104 as-is. then> > > you do not have to wait for me to finish the self-shading feature, which> > > IMO is out of scope for MSHADE-366 anyway.> > > I created MSHADE-400 on top of it and PR> > https://github.com/apache/maven-shade-plugin/pull/110, which can be> > reviewed already. I do not want to slow down the release process, which> > is why I expedited this today for everyone's convenience.> > > > MSHADE-396: https://github.com/apache/maven-shade-plugin/pull/105 is> > > ready for merge.> > > > > > > > > Tibor Digana schrieb am 22.07.2021 05:26 (GMT +07:00):> > > > > >> Can we cut a new release of m-shade-p? Is there any pending bug fix or> > >> improvement that you want to include in the release?> > > -> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org> > For additional commands, e-mail: users-h...@maven.apache.org> > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New release of Maven Shade Plugin
Alexander Kriegisch schrieb am 22.07.2021 09:34 (GMT +07:00): > MSHADE-366: Romain and I are still talking and working on a possible > basic implementation of self-shading. (I have started hacking around, > but it is not easy.) But in order to get rid of the warning, you could > merge https://github.com/apache/maven-shade-plugin/pull/104 as-is. then > you do not have to wait for me to finish the self-shading feature, which > IMO is out of scope for MSHADE-366 anyway. I created MSHADE-400 on top of it and PR https://github.com/apache/maven-shade-plugin/pull/110, which can be reviewed already. I do not want to slow down the release process, which is why I expedited this today for everyone's convenience. > MSHADE-396: https://github.com/apache/maven-shade-plugin/pull/105 is > ready for merge. > > > Tibor Digana schrieb am 22.07.2021 05:26 (GMT +07:00): > >> Can we cut a new release of m-shade-p? Is there any pending bug fix or >> improvement that you want to include in the release? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New release of Maven Shade Plugin
MSHADE-366: Romain and I are still talking and working on a possible basic implementation of self-shading. (I have started hacking around, but it is not easy.) But in order to get rid of the warning, you could merge https://github.com/apache/maven-shade-plugin/pull/104 as-is. then you do not have to wait for me to finish the self-shading feature, which IMO is out of scope for MSHADE-366 anyway. MSHADE-396: https://github.com/apache/maven-shade-plugin/pull/105 is ready for merge. -- Alexander Kriegisch https://scrum-master.de Tibor Digana schrieb am 22.07.2021 05:26 (GMT +07:00): > Can we cut a new release of m-shade-p? Is there any pending bug fix or > improvement that you want to include in the release? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
New release of Maven Shade Plugin
Can we cut a new release of m-shade-p? Is there any pending bug fix or improvement that you want to include in the release? Cheers Tibor
Re: How to relocate dependency classes using maven-shade-plugin?
> Hi Dave. > > I recommend to start with a simple stand-alone project in order to > find out how Maven Shade works. It can be quite tricks for beginners > otherwise. Create a Typo: I mean "tricky", of course. > POM, add a dependency - any dependency, some open source library maybe > - and then try shading and relocating it with Maven Shade. This should > work for both the binaries and (optionally) also for the sources. Both > uber JARs (binaries and sources) should be pulled including transitive > dependencies and you can even relocate the source code. Inspect the > resulting JARs and play with filtering options (for both dependency > names and files/directories) as well as with relocation. Then if you > have an MCVE [1] and a concrete problem, feel free to report back > here. Until then use [2] as a reference, especially [3] and [4]. Start > simple and step by step, then increase the level of difficulty. Don't > try to use 7 options at one, see what each of them does. > > [1] https://stackoverflow.com/help/mcve > [2] https://maven.apache.org/plugins/maven-shade-plugin/ > [3] > https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html > [4] > https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html > > -- > Alexander Kriegisch > https://scrum-master.de > > > David Hoffer schrieb am 31.03.2021 22:54 (GMT +07:00): > >> I have a single module Maven build where one of the dependences has >> well over 200 transitive dependencies. These transitive dependencies >> are incompatible with the rest of my application. >> >> I would like to use the maven-shade-plugin to create a shaded jar >> uber jar that contains all of these dependencies that all have been >> relocated to a custom package name. Then I need the Maven build to >> include this new shaded dependency instead of the prior/regular one. >> >> How can I configure the maven-shade-plugin to do this? So far I have >> not gotten it to process dependencies at all only other project code. >> I want it to start relocating at the top level dependency that I >> specify and have it include all transitive ones from there. >> >> Any pointers, examples are greatly appreciated. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to relocate dependency classes using maven-shade-plugin?
Hi Dave. I recommend to start with a simple stand-alone project in order to find out how Maven Shade works. It can be quite tricks for beginners otherwise. Create a POM, add a dependency - any dependency, some open source library maybe - and then try shading and relocating it with Maven Shade. This should work for both the binaries and (optionally) also for the sources. Both uber JARs (binaries and sources) should be pulled including transitive dependencies and you can even relocate the source code. Inspect the resulting JARs and play with filtering options (for both dependency names and files/directories) as well as with relocation. Then if you have an MCVE [1] and a concrete problem, feel free to report back here. Until then use [2] as a reference, especially [3] and [4]. Start simple and step by step, then increase the level of difficulty. Don't try to use 7 options at one, see what each of them does. [1] https://stackoverflow.com/help/mcve [2] https://maven.apache.org/plugins/maven-shade-plugin/ [3] https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html [4] https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html -- Alexander Kriegisch https://scrum-master.de David Hoffer schrieb am 31.03.2021 22:54 (GMT +07:00): > I have a single module Maven build where one of the dependences has > well over 200 transitive dependencies. These transitive dependencies > are incompatible with the rest of my application. > > I would like to use the maven-shade-plugin to create a shaded jar uber > jar that contains all of these dependencies that all have been > relocated to a custom package name. Then I need the Maven build to > include this new shaded dependency instead of the prior/regular one. > > How can I configure the maven-shade-plugin to do this? So far I have > not gotten it to process dependencies at all only other project code. > I want it to start relocating at the top level dependency that I > specify and have it include all transitive ones from there. > > Any pointers, examples are greatly appreciated. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to relocate dependency classes using maven-shade-plugin?
I have a single module Maven build where one of the dependences has well over 200 transitive dependencies. These transitive dependencies are incompatible with the rest of my application. I would like to use the maven-shade-plugin to create a shaded jar uber jar that contains all of these dependencies that all have been relocated to a custom package name. Then I need the Maven build to include this new shaded dependency instead of the prior/regular one. How can I configure the maven-shade-plugin to do this? So far I have not gotten it to process dependencies at all only other project code. I want it to start relocating at the top level dependency that I specify and have it include all transitive ones from there. Any pointers, examples are greatly appreciated. -Dave
Re: shade plugin modifying string constants
Thank you for your reply.
On 6/27/20 3:21 PM, John Patrick wrote:
From the views of a another user, relocation should be dumb and should
be exact case sensitive for both pattern and shadedPattern. So I would
not expect PKG to be altered. Yes the output is what your pattern
match lists but but so does; System.out.println ("org.example" +
".pkg."); and I wouldn't expect that to be changed.
That clarifies my confusion.
Based on your example would you have expect it to be replaced with
either A or B;
a) org.example.shaded.PKG
b) org.example.shaded.pkg
I wasn't expecting the capitalized name to undergo replacement. I had
added second println just for my clarity and didn't remove while posting
in the mailing list.
Thanks
anurag
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: shade plugin modifying string constants
>From the views of a another user, relocation should be dumb and should
be exact case sensitive for both pattern and shadedPattern. So I would
not expect PKG to be altered. Yes the output is what your pattern
match lists but but so does; System.out.println ("org.example" +
".pkg."); and I wouldn't expect that to be changed.
Based on your example would you have expect it to be replaced with
either A or B;
a) org.example.shaded.PKG
b) org.example.shaded.pkg
John
On Fri, 26 Jun 2020 at 07:30, Anurag Shekhar
wrote:
>
> Hi
>
> I am trying to shade a package with following tags
>
>
> org.example.pkg
> org.example.shaded.pkg
>
>
> I also have a string in one of my class which matches the pattern gets
>
> modified during shading
>
> public static void main (String [] args) {
> System.out.println ("org.example.pkg."); //prints
> org.example.shaded.pkg.
> System.out.println ("org.example.PKG.".toLowerCase()); //prints
> org.example.pkg.
> }
>
> Is this expected behavior ?
>
> I was thinking about making use of this behavior. Will it be safe to do so ?
>
> Or its something undocumented so might change without prior notice ?
>
>
> thanks
>
> Anurag
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
shade plugin modifying string constants
Hi
I am trying to shade a package with following tags
org.example.pkg
org.example.shaded.pkg
I also have a string in one of my class which matches the pattern gets
modified during shading
public static void main (String [] args) {
System.out.println ("org.example.pkg."); //prints
org.example.shaded.pkg.
System.out.println ("org.example.PKG.".toLowerCase()); //prints
org.example.pkg.
}
Is this expected behavior ?
I was thinking about making use of this behavior. Will it be safe to do so ?
Or its something undocumented so might change without prior notice ?
thanks
Anurag
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
maven-shade-plugin output with shadedArtifactAttached false overwritten by install
Dear list members,
I am having a problem with deploying jar files created by the
maven-shade-plugin. It used to work, but it has stopped working. From my
research the problem seems to be that the install step is overwriting the
shaded jar.
Please cc me when replying, because I haven't subscribed to the list.
Thank you very much for your time!
Now all the tl;dr details - please let me know if you need more.
If I use the following setting:
true
It will create a fat jar for me, but If I change that to
false
installing/deploying will remove the dependencies and the manifest entry for
the main class.
I don't want to use the "true" setting, because the file rename will break all
my tooling that depends on a generic script that will a deployed artifact via
CURL.
So, when I run
$ mvn -s ../.m2/settings.xml --batch-mode --errors --fail-at-end
--show-version clean package shade:shade
I get the correct files: ontology-merger-0.3.31.jar (big file) and
original-ontology-merger-0.3.31 (small file)
when I run
$ mvn -s ../.m2/settings.xml --batch-mode --errors --fail-at-end
--show-version clean package shade:shade install
the install step will trash the shaded jar. I am assuming that this happens
because it's running the maven-jar-plugin over it, although I don't mention the
maven-jar-plugin anywhere in my pom.xml. I have no idea how to switch this off.
Important bits from the log:
[INFO] Replacing original artifact with shaded artifact.
[INFO] Replacing
C:\dev\allotrope\source\ontology-qa-tools\merger\target\ontology-merger-0.3.31.jar
with
C:\dev\allotrope\source\ontology-qa-tools\merger\target\ontology-merger-0.3.31-shaded.jar
[INFO] Dependency-reduced POM written at:
C:\dev\allotrope\source\ontology-qa-tools\merger\dependency-reduced-pom.xml
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
ontology-merger ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @
ontology-merger ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
ontology-merger ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 30 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @
ontology-merger ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ ontology-merger
---
[INFO] Skipping execution of surefire because it has already been run for this
configuration
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ ontology-merger ---
[INFO] Building jar:
C:\dev\allotrope\source\ontology-qa-tools\merger\target\ontology-merger-0.3.31.jar
[INFO]
[INFO] --- maven-install-plugin:2.4:install (default-install) @ ontology-merger
---
[INFO] Installing
C:\dev\allotrope\source\ontology-qa-tools\merger\target\ontology-merger-0.3.31.jar
to
C:\Users\User\.m2\repository\com\osthus\ontology-merger\0.3.31\ontology-merger-0.3.31.jar
[INFO] Installing
C:\dev\allotrope\source\ontology-qa-tools\merger\dependency-reduced-pom.xml to
C:\Users\User\.m2\repository\com\osthus\ontology-merger\0.3.31\ontology-merger-0.3.31.pom
The section in my pom.xml currently looks like this:
org.apache.maven.plugins
maven-shade-plugin
3.2.3
true
com.osthus.ontology_merger.MergerMain
com.osthus.ontology_merger.MergerMain
false
*:*
MET
[ANN] Apache Maven Shade Plugin 3.2.4 Released
The Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.2.4 This plugin repackages the project classes together with their dependencies into a single uber-jar, optionally renaming classes or removing unused classes. 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.2.4 Release Notes - Apache Maven Shade Plugin - Version 3.2.4 Bug * [MSHADE-363] Breaking change to ResourceTransformer's API * [MSHADE-360] ServicesResourceTransformer.modifyOutputStream swallows IOExceptions Task * [MSHADE-365] document Properties transformers available since 3.2.2 in separate table * [MSHADE-364] Don't log as duplicate resource handled by a transformer Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Shade plugin cannot find default setter?
D’oh! Thank you very much! > On May 4, 2020, at 10:03 AM, Stuart McCulloch wrote: > > It looks like you're missing the tag inside the > list: > https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html > > try: > > > > >javax.ejb >jakarta.ejb > >javax.ejb.* > > > > > > On Mon, 4 May 2020 at 15:01, Russell Gold wrote: > >> I’m attempting to use the shade plugin to relocate some dependent classes >> with the following configuration: >> >> >> >>javax.ejb >>jakarta.ejb >> >>javax.ejb.* >> >> >> >> >> >> but when I try running, I see: >> >> [ERROR] Failed to execute goal >> org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on >> project orb-gmbal-pfl-shading: Unable to parse configuration of mojo >> org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade for parameter >> pattern: Cannot find default setter in class >> org.apache.maven.plugins.shade.mojo.PackageRelocation -> [Help 1] >> >> How do I get past this? >> >> Thanks, >> Russ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Shade plugin cannot find default setter?
It looks like you're missing the tag inside the list: https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html try: javax.ejb jakarta.ejb javax.ejb.* On Mon, 4 May 2020 at 15:01, Russell Gold wrote: > I’m attempting to use the shade plugin to relocate some dependent classes > with the following configuration: > > > > javax.ejb > jakarta.ejb > > javax.ejb.* > > > > > > but when I try running, I see: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on > project orb-gmbal-pfl-shading: Unable to parse configuration of mojo > org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade for parameter > pattern: Cannot find default setter in class > org.apache.maven.plugins.shade.mojo.PackageRelocation -> [Help 1] > > How do I get past this? > > Thanks, > Russ
Shade plugin cannot find default setter?
I’m attempting to use the shade plugin to relocate some dependent classes with the following configuration: javax.ejb jakarta.ejb javax.ejb.* but when I try running, I see: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade (default) on project orb-gmbal-pfl-shading: Unable to parse configuration of mojo org.apache.maven.plugins:maven-shade-plugin:3.1.0:shade for parameter pattern: Cannot find default setter in class org.apache.maven.plugins.shade.mojo.PackageRelocation -> [Help 1] How do I get past this? Thanks, Russ
[ANN] Apache Maven Shade Plugin 3.2.3 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.2.3 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. 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.2.3 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.2.3 ** Bug * [MSHADE-352] - shaded jars are not reproducible when using transformer ** Dependency upgrade * [MSHADE-355] - Java 15 Compatibility - JDependecny/ASM Upgrade * [MSHADE-357] - Upgrade asm to 8.0 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shade Plugin 3.2.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.2.2 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. 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.2.2 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.2.2 ** Bug * [MSHADE-223] - Endless processing when promoteTransitiveDependencies=true * [MSHADE-284] - Shaded test JARs are always empty * [MSHADE-291] - shadedPattern applied multiples times when relocating the contents of META-INF/services files * [MSHADE-298] - Groovy extension module transformer looking in incorrect META-INF directory * [MSHADE-309] - issue tracker link on the web site of shade plugin does not work. * [MSHADE-311] - Bad exclusions in dependency-reduced-pom.xml * [MSHADE-315] - Broken link on Maven Shade Plugin * [MSHADE-318] - Specifically included class's dependencies are missing * [MSHADE-331] - Issue Tracker link is not working - Page Not Found * [MSHADE-337] - Relocation cannot process class file version 58 JARs * [MSHADE-339] - Shaded test jar has wrong type "jar" * [MSHADE-340] - Shaded test jar artifact is not attached ** New Feature * [MSHADE-306] - Log all duplicates, not only classes * [MSHADE-347] - Reproducible Builds: make entries in output jar files reproducible ** Improvement * [MSHADE-285] - It should be possible to shade test sources as a JAR * [MSHADE-313] - Minimize jar should respect implementations under /META-INF/services/ * [MSHADE-316] - Minijar: true * [MSHADE-319] - Group output into included and excluded artifacts to easily identify them * [MSHADE-348] - Make build Reproducible ** Test * [MSHADE-327] - improved integration test coverage for relocation and minification ** Task * [MSHADE-322] - Provide a transformer for properties files * [MSHADE-330] - Java 12 and 13 support * [MSHADE-346] - Introduce mock repository manager for testing * [MSHADE-350] - Enable ManifestResourceTransformer to rewrite the manifest with relocations ** Dependency upgrade * [MSHADE-320] - Upgrade maven-artifact-transfer to 0.11.0 * [MSHADE-338] - Upgrade maven-artifact-transfer 0.12.0 * [MSHADE-341] - Upgrade plexus-utils 3.3.0 * [MSHADE-349] - Upgrade to org.ow2.asm:asm:7.3.1 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Skipping maven shade plugin in a spring-boot project based on maven profile
Thanks Maarten.
On Fri, Dec 20, 2019 at 12:07 PM Maarten Mulders wrote:
> Also cross-posting from StackOverflow [1], where I just answered your
> question:
>
>
> There is a dedicated Spring Boot Maven Plugin [2] that also allows you
> to repackage your application. Its repackage goal automatically
> activates during the package phase, so you don't even need to define an
> execution.
>
> Back to your question, if you want to skip execution of a certain
> plugin, many plugins have a skip property that you can set. The Spring
> Boot Maven Plugin has one. You can set it in the XML configuration, but
> there's also a user property for it. As a result, your dev-local profile
> could look like this:
>
>
> dev-local
>
> true
>
>
>
> But you could even skip the profile completely and invoke Maven with
> -Dspring-boot.repackage.skip=true.
>
> The Maven Shade Plugin [3] has no such property documented, so that
> could be a reason for using the Spring Boot Maven Plugin over the Maven
> Shade Plugin.
>
> Finally, for building applications, you typically don't need mvn clean
> install, but mvn verify would be enough. Saves you a few seconds in
> execution and saves a lot of disk space in the long run since it doesn't
> copy built artifacts to your local Maven repo (~/.m2/repository or
> %userprofile%\.m2\repository).
>
>
> Hope this helps,
>
>
> Maarten
>
> References:
> [1] https://stackoverflow.com/a/59420813/1523342
> [2]
> https://docs.spring.io/spring-boot/docs/current/maven-plugin/index.html
> [3] https://maven.apache.org/plugins/maven-shade-plugin/index.html
>
> On December 20, 2019 at 06:04, Debraj Manna wrote:
>
> > I am cross-posting from stackoverflow
> > <
> https://stackoverflow.com/questions/59393863/skipping-maven-shade-plugin-in-a-spring-boot-project-based-on-maven-profile
> >
> > as I did not get any reply there.
> >
> > I want to skip the execution of maven-shade-plugin when a certain maven
> > profile is activated on a spring-boot project. As mentioned in this
> > answer
> > <https://stackoverflow.com/a/13383092/785523> I have made my pom.xml
> > like
> > below
> >
> > > xmlns="http://maven.apache.org/POM/4.0.0;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> > 4.0.0
> >
> > com.van.saasinfra
> > saas-controller
> > 0.001-SNAPSHOT
> > jar
> >
> > saas-controller
> > SaaS Controller
> >
> >
> > org.springframework.boot
> > spring-boot-starter-parent
> > 1.5.21.RELEASE
> >
> >
> >
> >
> > ...
> >
> >
> >
> >
> > dev-local
> >
> > org.apache.maven.plugins
> > maven-shade-plugin
> > ${mvn.shade.plugin.version}
> >
> >
> > saas-controller-shade
> > none
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > maven-shade-plugin
> >
> >
> > maven-antrun-plugin
> > 1.8
> >
> >
> > generate-sources
> > generate-sources
> >
> >
> > > dir="${project.build.directory}/generated-sources"/>
> >
> > > value="--java_out=${project.build.directory}/generated-sources"/>
> > > value="--proto_path=${project.basedir}/src/main/proto"/>
> > >
> value="${project.basedir}/src/main/proto/com/van/saasinfra/saascontroller/saas-controller.proto"/>
> > >
> value="${project.basedir}/src/main/proto/com/van/saasinfra/saascontroller/billing-controller.proto"/>
> > >
> value="${project.basedir}/src/main/proto/com/van/saasinfra/saascontroller/node-topology.proto"/>
> > >
> value="${project.basedir}/src/main/proto/com/van/saasinfra/saascontroller/availability.proto"/>
> > >
> value="${project.basedir}/src/main/proto/com/van/saasinfra/saascontroller/dynamodb-config.proto"/>
> > >
> value="${project.basedir}/src/main/proto/com/van/saasinfra/saascontroller/tenant-migration.proto"/>
> >
> >
> >
> > ${project.build.directory}/generated-sources/
> >
> >
> > run
> >
> >
> >
> >
> >
> >
> >
> > But even when doing maven clean install -Pdev-local I am seeing shade
> > step
> > is still getting executed.
> >
> > Can some suggest how to stop the execution of shade when a certain
> > profile
> > is enabled on a spring boot project?
>
Re: Skipping maven shade plugin in a spring-boot project based on maven profile
Also cross-posting from StackOverflow [1], where I just answered your
question:
There is a dedicated Spring Boot Maven Plugin [2] that also allows you
to repackage your application. Its repackage goal automatically
activates during the package phase, so you don't even need to define an
execution.
Back to your question, if you want to skip execution of a certain
plugin, many plugins have a skip property that you can set. The Spring
Boot Maven Plugin has one. You can set it in the XML configuration, but
there's also a user property for it. As a result, your dev-local profile
could look like this:
dev-local
true
But you could even skip the profile completely and invoke Maven with
-Dspring-boot.repackage.skip=true.
The Maven Shade Plugin [3] has no such property documented, so that
could be a reason for using the Spring Boot Maven Plugin over the Maven
Shade Plugin.
Finally, for building applications, you typically don't need mvn clean
install, but mvn verify would be enough. Saves you a few seconds in
execution and saves a lot of disk space in the long run since it doesn't
copy built artifacts to your local Maven repo (~/.m2/repository or
%userprofile%\.m2\repository).
Hope this helps,
Maarten
References:
[1] https://stackoverflow.com/a/59420813/1523342
[2]
https://docs.spring.io/spring-boot/docs/current/maven-plugin/index.html
[3] https://maven.apache.org/plugins/maven-shade-plugin/index.html
On December 20, 2019 at 06:04, Debraj Manna wrote:
I am cross-posting from stackoverflow
<https://stackoverflow.com/questions/59393863/skipping-maven-shade-plugin-in-a-spring-boot-project-based-on-maven-profile>
as I did not get any reply there.
I want to skip the execution of maven-shade-plugin when a certain maven
profile is activated on a spring-boot project. As mentioned in this
answer
<https://stackoverflow.com/a/13383092/785523> I have made my pom.xml
like
below
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
com.van.saasinfra
saas-controller
0.001-SNAPSHOT
jar
saas-controller
SaaS Controller
org.springframework.boot
spring-boot-starter-parent
1.5.21.RELEASE
...
dev-local
org.apache.maven.plugins
maven-shade-plugin
${mvn.shade.plugin.version}
saas-controller-shade
none
maven-shade-plugin
maven-antrun-plugin
1.8
generate-sources
generate-sources
${project.build.directory}/generated-sources/
run
But even when doing maven clean install -Pdev-local I am seeing shade
step
is still getting executed.
Can some suggest how to stop the execution of shade when a certain
profile
is enabled on a spring boot project?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Skipping maven shade plugin in a spring-boot project based on maven profile
I am cross-posting from stackoverflow
<https://stackoverflow.com/questions/59393863/skipping-maven-shade-plugin-in-a-spring-boot-project-based-on-maven-profile>
as I did not get any reply there.
I want to skip the execution of maven-shade-plugin when a certain maven
profile is activated on a spring-boot project. As mentioned in this answer
<https://stackoverflow.com/a/13383092/785523> I have made my pom.xml like
below
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0
com.van.saasinfra
saas-controller
0.001-SNAPSHOT
jar
saas-controller
SaaS Controller
org.springframework.boot
spring-boot-starter-parent
1.5.21.RELEASE
...
dev-local
org.apache.maven.plugins
maven-shade-plugin
${mvn.shade.plugin.version}
saas-controller-shade
none
maven-shade-plugin
maven-antrun-plugin
1.8
generate-sources
generate-sources
${project.build.directory}/generated-sources/
run
But even when doing maven clean install -Pdev-local I am seeing shade step
is still getting executed.
Can some suggest how to stop the execution of shade when a certain profile
is enabled on a spring boot project?
Re: Shade Plugin dependency resolution
Anyone any update on this? On Thu, Aug 22, 2019 at 8:06 PM Debraj Manna wrote: > Hi > > Is there any doc or link that explains how does shade Plugin resolves the > dependency that is to be added in the uber jar? >
Shade Plugin dependency resolution
Hi Is there any doc or link that explains how does shade Plugin resolves the dependency that is to be added in the uber jar?
how to configure maven-shade-plugin to execute using specific java version?
Hi,
My default JAVA_HOME points to java 1.6 and I am trying use
maven-shade-plugin version 3.2.1 which requires java 1.7+
So I looking for a way to configure my maven-shade-plugin to execute using
required java version and not my default JAVA_HOME version.
E.g. I had similar issue with maven-surefire-plugin and I was able to solve
it by specifying under its but unfortunately this
doesn't works for maven-shade-plugin:
${JAVA_8_HOME}/bin/java
Thanks,
Sachin
Re: Usage of dependency-reduced-pom.xml from maven-shade-plugin in a multi-module/reactor project
Building the shaded module separately was my workaround for a few days. My current workaround is to specify the intra-module dependency in my parent pom under dependencyManagement with a list of exclusions for the artifacts I am shading into it. Effectively I am manually "reducing" the dependency set of the shaded module as seen from within the multi-module project. However, I think it might be best for Maven to (re-)allow the set of dependencies listed to reduce after build due to plugins like maven-shade-plugin. While needing to shade in general is not ideal, needing to build the module outside of the reactor in addition to shading is less ideal, especially in a larger project where it may need to be ordered between other modules to successfully build. See: https://issues.apache.org/jira/browse/MSHADE-206 See: https://issues.apache.org/jira/browse/MNG-5899 On 3/18/19 5:12 PM, Francois MAROT wrote: > Hi Nikki, > > Regarding your question, I'm not sure of what is a "reactor of reactor"... > by 2 separate "projects" I mean 2 different build. Hence 2 different > "reactor". > As I understand it, the reactor is the sum of all Maven modules > participating in the build. Usually in the case of a multi-modules Maven > project, you start the build from the top level module, and all your modules > are part of the same rector. Part of the same build. > I personally like to have one git repository per multi-module Maven project > so we have: > > 1 git repo --> containing one multi-modules Maven project ⊃ composed of many > modules == one build == one reactor > > What is sure is that for the shade plugin to work, you have to make Maven > builds depending on the shaded artifact find this artifact stored in a repo > (whether local or remote) and not reference it as a module inside the > reactor (ie part of the same build). > > I hope it helps ! signature.asc Description: OpenPGP digital signature
Re: Usage of dependency-reduced-pom.xml from maven-shade-plugin in a multi-module/reactor project
Hi Nikki, Regarding your question, I'm not sure of what is a "reactor of reactor"... by 2 separate "projects" I mean 2 different build. Hence 2 different "reactor". As I understand it, the reactor is the sum of all Maven modules participating in the build. Usually in the case of a multi-modules Maven project, you start the build from the top level module, and all your modules are part of the same rector. Part of the same build. I personally like to have one git repository per multi-module Maven project so we have: 1 git repo --> containing one multi-modules Maven project ⊃ composed of many modules == one build == one reactor What is sure is that for the shade plugin to work, you have to make Maven builds depending on the shaded artifact find this artifact stored in a repo (whether local or remote) and not reference it as a module inside the reactor (ie part of the same build). I hope it helps ! -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Usage of dependency-reduced-pom.xml from maven-shade-plugin in a multi-module/reactor project
Francois, Oh wow, I never knew shaded modules should be leafs... thanks! ...two separate projects ? Conceptually, I always thought of each module as its own project. I guess that's the wrong way of thinking about modules ? What about doing a reactor of reactors ? Would that be a sufficient work-around ? Would that satisfy the separate-projects rule ? Or no ? Thanks, Nick From: Francois MAROT Sent: Sunday, March 17, 2019 10:38 PM To: users@maven.apache.org Subject: Re: Usage of dependency-reduced-pom.xml from maven-shade-plugin in a multi-module/reactor project Hello Kyle, to my knowledge your analysis is good, you are correct. Sorry but I did not take the time to read your pom excerpt but I have been using the shade plugin for quite some time now and concluded that shaded artifacts must be leafs in the Maven modules tree. By "leaf" I mean no artifact in the same Maven reactor must depend upon a shaded artifact. You must separate the build of a shaded artifact and those depending upon it. >From my understanding, this relates to the way Maven calculates the dependencies: they are calculated at the beginning of the build, not at the end or incrementally. While the shade plugin acts merely as a hack and replaces the pom at the end of building the shaded module. It's too late in the process as the dependencies of artifacts depending on the shaded one have already been calculated. My advice would be to ensure you have 2 separated projects, not part of the same reactor build to prevent problems or surprise for newcomers. Regards Francois Marot -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Usage of dependency-reduced-pom.xml from maven-shade-plugin in a multi-module/reactor project
Hello Kyle, to my knowledge your analysis is good, you are correct. Sorry but I did not take the time to read your pom excerpt but I have been using the shade plugin for quite some time now and concluded that shaded artifacts must be leafs in the Maven modules tree. By "leaf" I mean no artifact in the same Maven reactor must depend upon a shaded artifact. You must separate the build of a shaded artifact and those depending upon it. >From my understanding, this relates to the way Maven calculates the dependencies: they are calculated at the beginning of the build, not at the end or incrementally. While the shade plugin acts merely as a hack and replaces the pom at the end of building the shaded module. It's too late in the process as the dependencies of artifacts depending on the shaded one have already been calculated. My advice would be to ensure you have 2 separated projects, not part of the same reactor build to prevent problems or surprise for newcomers. Regards Francois Marot -- Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Usage of dependency-reduced-pom.xml from maven-shade-plugin in a multi-module/reactor project
Wolf helped me out with a similar issue.
https://github.com/BattlePlugins/BattleBukkitLib/issues/3
He alerted me to the Maven-Flatten-Plugin:
https://www.mojohaus.org/flatten-maven-plugin/
Quote:
"This essentially allows you to use your parent POMs during builds but
deletes the reference to them when your artifact gets deployed,
integrating the information from the parents at the appropriate places
(flattening), reducing the information "leaked" to the consumer of your
artifact to the bare minimum." ~Wolf
Hopefully that can help solve your issue as well.
As for some of your technical questions about the behavior of Maven, we're in
the same boat.
There are some aspects of Maven that I don't quite understand... but I am
extremely curious.
Good luck !
Nick
From: Kyle Marek
Sent: Saturday, March 16, 2019 5:34 AM
To: users@maven.apache.org
Subject: Usage of dependency-reduced-pom.xml from maven-shade-plugin in a
multi-module/reactor project
I am having a dependency conflict issue in a project I am working on.
Specifically, a dependency of a dependency of a dependency depends on Jersey
1.9 for internal client purposes, while I am using Jersey 2.28 in implementing
a REST interface for the high level functionality of the project. Since Jersey
1.9 is basically being used invisibly and behind the scenes inside of my
dependency, I am attempting to use maven-shade-plugin to include the dependency
and Jersey 1.9 and relocate Jersey to another package while I use Jersey 2.28
up front in its original package.
maven-shade-plugin creates a modified POM file with reduced dependencies for
installation so dependent projects won't pull in dependencies for the jar when
they are already included/shaded in the jar.
However, what I am finding is that when the functional component and the web
application component of the project are developed as *modules* to an
aggregating/parent POM, the build process only accounts for the *original* POM
of the shaded functional module with its original/pre-reduced dependencies,
which makes the build of the web application module pull in the original
dependencies, that should have been shaded, into its WEB-INF/lib/. The
dependency management works correctly when installing the shaded functional
component, and building the web application module independently.
Is this a bug or by design? Is there a proper fix to apply to my POM files, or
am I stuck ordering, building and installing each project independently for now?
My test case and details follow. Please note that I am demonstrating the issue
and left relocations and artifact includes/excludes out of the
maven-shade-plugin configuration.
See:
# POM files
kma...@kyle.internal.gigabyteproductions.net<mailto:kma...@kyle.internal.gigabyteproductions.net>
~/src/shadetest
$ cat pom.xml
http://maven.apache.org/POM/4.0.0;<http://maven.apache.org/POM/4.0.0>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;<http://www.w3.org/2001/XMLSchema-instance>
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;<http://maven.apache.org/POM/4.0.0http://maven.apache.org/maven-v4_0_0.xsd>>
4.0.0
net.gigabyteproductions.maven.shadetest
shadetest-parent
pom
1.0-SNAPSHOT
lib
service
javax.servlet
servlet-api
2.5
provided
org.apache.accumulo
accumulo-core
1.8.1
org.apache.maven.plugins
maven-shade-plugin
3.0.0
org.apache.tomcat.maven
tomcat7-maven-plugin
2.2
kma...@kyle.internal.gigabyteproductions.net<mailto:kma...@kyle.internal.gigabyteproductions.net>
~/src/shadetest
$ cat lib/pom.xml
http://maven.apache.org/POM/4.0.0;<http://maven.apache.org/POM/4.0.0>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;<http://www.w3.org/2001/XMLSchema-instance>
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;<http://maven.apache.org/POM/4.0.0http://maven.apache.org/maven-v4_0_0.xsd>>
4.0.0
net.gigabyteproductions.maven.shadetest
shadetest-parent
1.0-SNAPSHOT
..
shadetest-lib
jar
1.0-SNAPSHOT
org.apache.accumulo
accumulo-core
org.apache.maven.plugins
maven-shade-plugin
package
shade
false
kma...@kyle.internal.gigabyteproductions.net<mailto:kma...@kyle.internal.gigabyteproductions.net>
~/src/shadetest
$ cat service/pom.xml
http://maven.apache.org/POM/4.0.0;<http://ma
Usage of dependency-reduced-pom.xml from maven-shade-plugin in a multi-module/reactor project
I am having a dependency conflict issue in a project I am working on.
Specifically, a dependency of a dependency of a dependency depends on
Jersey 1.9 for internal client purposes, while I am using Jersey 2.28 in
implementing a REST interface for the high level functionality of the
project. Since Jersey 1.9 is basically being used invisibly and behind
the scenes inside of my dependency, I am attempting to use
maven-shade-plugin to include the dependency and Jersey 1.9 and relocate
Jersey to another package while I use Jersey 2.28 up front in its
original package.
maven-shade-plugin creates a modified POM file with reduced dependencies
for installation so dependent projects won't pull in dependencies for
the jar when they are already included/shaded in the jar.
However, what I am finding is that when the functional component and the
web application component of the project are developed as *modules* to
an aggregating/parent POM, the build process only accounts for the
*original* POM of the shaded functional module with its
original/pre-reduced dependencies, which makes the build of the web
application module pull in the original dependencies, that should have
been shaded, into its WEB-INF/lib/. The dependency management works
correctly when installing the shaded functional component, and building
the web application module independently.
Is this a bug or by design? Is there a proper fix to apply to my POM
files, or am I stuck ordering, building and installing each project
independently for now?
My test case and details follow. Please note that I am demonstrating the
issue and left relocations and artifact includes/excludes out of the
maven-shade-plugin configuration.
See:
# POM files
kma...@kyle.internal.gigabyteproductions.net ~/src/shadetest
$ cat pom.xml
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
net.gigabyteproductions.maven.shadetest
shadetest-parent
pom
1.0-SNAPSHOT
lib
service
javax.servlet
servlet-api
2.5
provided
org.apache.accumulo
accumulo-core
1.8.1
org.apache.maven.plugins
maven-shade-plugin
3.0.0
org.apache.tomcat.maven
tomcat7-maven-plugin
2.2
kma...@kyle.internal.gigabyteproductions.net ~/src/shadetest
$ cat lib/pom.xml
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
net.gigabyteproductions.maven.shadetest
shadetest-parent
1.0-SNAPSHOT
..
shadetest-lib
jar
1.0-SNAPSHOT
org.apache.accumulo
accumulo-core
org.apache.maven.plugins
maven-shade-plugin
package
shade
false
kma...@kyle.internal.gigabyteproductions.net ~/src/shadetest
$ cat service/pom.xml
http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
4.0.0
net.gigabyteproductions.maven.shadetest
shadetest-parent
1.0-SNAPSHOT
..
shadetest-service
war
1.0-SNAPSHOT
net.gigabyteproductions.maven.shadetest
shadetest-lib
1.0-SNAPSHOT
org.glassfish.jersey.containers
jersey-container-servlet-core
2.28
org.glassfish.jersey.inject
jersey-hk2
2.28
# reactor build/install
kma...@kyle.internal.gigabyteproductions.net ~/src/shadetest
$ rm -rf ~/.m2/repository/net/gigabyteproductions/maven/shadetest/
kma...@kyle.internal.gigabyteproductions.net ~/src/shadetest
$ mvn clean install
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] shadetest-parent [pom]
[INFO] shadetest-lib [jar]
[INFO] shadetest-service [war]
. . .
[INFO] --- maven-shade-plugin:3.0.0:shade (default) @ shadetest-lib ---
[INFO] Including org.apache.accumulo:accumulo-core:jar:1.8.1 in the shaded jar.
. . .
[INFO] Including com.sun.jersey:jersey-core:jar:1.9 in the shaded jar.
[INFO] Including com.sun.jersey:jersey-client:jar:1.9 in the shaded jar.
. . .
[INFO] Replacing original artifact with shaded a
Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
Hi,
I have faced the same problem recently on jgitver maven core dependency (
https://github.com/jgitver/jgitver-maven-plugin/issues/109).
In fact, the problem popped up when a *fork* execution occures after that
the pom file has been relocated.
When this occures the basedir is computed as the directory containing the
pom which is not what is expected and leads to issues.
Unfortunatelly my plugin already calls the 'good' api by calling setPomFile
when it can (
https://github.com/jgitver/jgitver-maven-plugin/blob/master/src/main/java/fr/brouillard/oss/jgitver/JGitverUtils.java#L127
).
So if you have a plugin that fires a fork execution you should be able to
reproduce.
I have not tested yet the above fork scenario with pom relocation outside
of project dir with flatten-maven-plugin.
Regards,
Matthieu
On Sun, Jan 13, 2019 at 3:10 PM Mikael Åsberg
wrote:
> Hi Hervé, and thanks for your reply! So it sounds like since
> maven-shade-plugin still has not been updated to use the new API, the
> problem should still be there. But did you check my test project? I thought
> it would capture the problem, if it was still there and I understood it
> correctly, but I guess the project is bogus somehow since it doesn't
> capture the issue. I would like to understand how my test project is faulty
> so I understand the issue properly. Is there a Jira for maven-shade-plugin
> which tracks the issue (an issue which could be solved by using the new API
> you mentioned)?
>
> Regards, Mikael
>
> On Sun, Jan 13, 2019, 10:43 Hervé BOUTEMY
> > Hi
> >
> > Good question: I did not yet find the official answer, but I can share
> > what I
> > know on this.
> >
> > flatten-maven-plugin has the exact same issue, and this was fixed in the
> > past
> > by adding a new API in Maven core (in 3.2.5) to be called by the plugin:
> > see https://github.com/mojohaus/flatten-maven-plugin/pull/30
> >
> > I just had a look at maven-shade-plugin source and found
> "project.setFile(
> > dependencyReducedPomLocation );": this call has not been replaced by
> > setPomFile() API.
> > That means that the limitation on the chosen directory should still be
> here
> >
> > Hope this helps...
> >
> > Regards,
> >
> > Hervé
> >
> > Le mercredi 9 janvier 2019, 15:06:26 CET Mikael Åsberg a écrit :
> > > Hi, the documentation for dependencyReducedPomLocation says:
> > > "Where to put the dependency reduced pom. Note: setting a value for
> > > this parameter with a directory other than ${basedir} will change the
> > > value of ${basedir} for all executions that come after the shade
> > > execution. This is often not what you want. This is considered an open
> > > issue with this plugin."
> > >
> > >
> >
> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependen
> > > cyReducedPomLocation
> > >
> > > I created a small test project which performs a shade in the package
> > > phase (with the dependencyReducedPomLocation set to the
> > > ${project.build.directory} and then I print the value (using
> > > gmavenplus-plugin) of ${project.basedir} in the verify phase (which
> > > comes after package as you know). I don't see that the value of
> > > basedir has changed (which is good), is this part of the documentation
> > > incorrect or is my test project wrong (i.e., did I misunderstood the
> > > possibly undesirable side-effect to ${basedir} by setting
> > > dependencyReducedPomLocation)?
> > >
> > > You can find my test project here:
> > https://github.com/masberg/mshadeissue
> > >
> > > - Mikael
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
Hi Hervé, and thanks for your reply! So it sounds like since
maven-shade-plugin still has not been updated to use the new API, the
problem should still be there. But did you check my test project? I thought
it would capture the problem, if it was still there and I understood it
correctly, but I guess the project is bogus somehow since it doesn't
capture the issue. I would like to understand how my test project is faulty
so I understand the issue properly. Is there a Jira for maven-shade-plugin
which tracks the issue (an issue which could be solved by using the new API
you mentioned)?
Regards, Mikael
On Sun, Jan 13, 2019, 10:43 Hervé BOUTEMY Hi
>
> Good question: I did not yet find the official answer, but I can share
> what I
> know on this.
>
> flatten-maven-plugin has the exact same issue, and this was fixed in the
> past
> by adding a new API in Maven core (in 3.2.5) to be called by the plugin:
> see https://github.com/mojohaus/flatten-maven-plugin/pull/30
>
> I just had a look at maven-shade-plugin source and found "project.setFile(
> dependencyReducedPomLocation );": this call has not been replaced by
> setPomFile() API.
> That means that the limitation on the chosen directory should still be here
>
> Hope this helps...
>
> Regards,
>
> Hervé
>
> Le mercredi 9 janvier 2019, 15:06:26 CET Mikael Åsberg a écrit :
> > Hi, the documentation for dependencyReducedPomLocation says:
> > "Where to put the dependency reduced pom. Note: setting a value for
> > this parameter with a directory other than ${basedir} will change the
> > value of ${basedir} for all executions that come after the shade
> > execution. This is often not what you want. This is considered an open
> > issue with this plugin."
> >
> >
> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependen
> > cyReducedPomLocation
> >
> > I created a small test project which performs a shade in the package
> > phase (with the dependencyReducedPomLocation set to the
> > ${project.build.directory} and then I print the value (using
> > gmavenplus-plugin) of ${project.basedir} in the verify phase (which
> > comes after package as you know). I don't see that the value of
> > basedir has changed (which is good), is this part of the documentation
> > incorrect or is my test project wrong (i.e., did I misunderstood the
> > possibly undesirable side-effect to ${basedir} by setting
> > dependencyReducedPomLocation)?
> >
> > You can find my test project here:
> https://github.com/masberg/mshadeissue
> >
> > - Mikael
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: Regarding config param dependencyReducedPomLocation for maven-shade-plugin
Hi
Good question: I did not yet find the official answer, but I can share what I
know on this.
flatten-maven-plugin has the exact same issue, and this was fixed in the past
by adding a new API in Maven core (in 3.2.5) to be called by the plugin:
see https://github.com/mojohaus/flatten-maven-plugin/pull/30
I just had a look at maven-shade-plugin source and found "project.setFile(
dependencyReducedPomLocation );": this call has not been replaced by
setPomFile() API.
That means that the limitation on the chosen directory should still be here
Hope this helps...
Regards,
Hervé
Le mercredi 9 janvier 2019, 15:06:26 CET Mikael Åsberg a écrit :
> Hi, the documentation for dependencyReducedPomLocation says:
> "Where to put the dependency reduced pom. Note: setting a value for
> this parameter with a directory other than ${basedir} will change the
> value of ${basedir} for all executions that come after the shade
> execution. This is often not what you want. This is considered an open
> issue with this plugin."
>
> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependen
> cyReducedPomLocation
>
> I created a small test project which performs a shade in the package
> phase (with the dependencyReducedPomLocation set to the
> ${project.build.directory} and then I print the value (using
> gmavenplus-plugin) of ${project.basedir} in the verify phase (which
> comes after package as you know). I don't see that the value of
> basedir has changed (which is good), is this part of the documentation
> incorrect or is my test project wrong (i.e., did I misunderstood the
> possibly undesirable side-effect to ${basedir} by setting
> dependencyReducedPomLocation)?
>
> You can find my test project here: https://github.com/masberg/mshadeissue
>
> - Mikael
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Regarding config param dependencyReducedPomLocation for maven-shade-plugin
Hi, the documentation for dependencyReducedPomLocation says:
"Where to put the dependency reduced pom. Note: setting a value for
this parameter with a directory other than ${basedir} will change the
value of ${basedir} for all executions that come after the shade
execution. This is often not what you want. This is considered an open
issue with this plugin."
https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation
I created a small test project which performs a shade in the package
phase (with the dependencyReducedPomLocation set to the
${project.build.directory} and then I print the value (using
gmavenplus-plugin) of ${project.basedir} in the verify phase (which
comes after package as you know). I don't see that the value of
basedir has changed (which is good), is this part of the documentation
incorrect or is my test project wrong (i.e., did I misunderstood the
possibly undesirable side-effect to ${basedir} by setting
dependencyReducedPomLocation)?
You can find my test project here: https://github.com/masberg/mshadeissue
- Mikael
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
shade-plugin: different result based on order of filters
The Apache Flink project has run into an unexpected behavior when using the maven-shade-plugin. In one of our modules we define 2 filters: * META-INF/maven/org.weakref/** com.facebook.presto.hadoop:hadoop-apache2 com/facebook/presto/hadoop/** Basically, the first filters removes a bit of noise, and the second includes a specific set of classes from a specific artifact. The full pom.xml can be found here: https://github.com/apache/flink/blob/b765e0774c585b02f5906370e245028b15c8fda2/flink-filesystems/flink-s3-fs-presto/pom.xml#L262 With the configuration above the files that should be included based on the second filter are missing from the jar. (in fact, everything from hadoop-apache2 is missing) However, if we reverse the filter order they are contained in the jar. My question would be whether someone has seen something similar to this issue. I'm trying to create a small self-contained reproducing project but haven't succeeded so far :/
[ANN] Apache Maven Shade Plugin 3.2.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.2.1 Repackages the project classes together with their dependencies into a single uber-jar, optionally renaming classes or removing unused classes. 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.2.1 Release Notes - Apache Maven Shade Plugin - Version 3.2.1 Bug * [MSHADE-302] maven-shade-plugin fails to minimize JAR with Java 11 * [MSHADE-291] shadedPattern applied multiples times when relocating the contents of META-INF/services files Improvement * [MSHADE-303] Suppress module-info.class warning if the file if filtered Task * [MSHADE-301] java11 support * [MSHADE-299] Upgrade maven-dependency-tree to 3.0.1 Enjoy, -The Apache Maven team
[ANN] Apache Maven Shade Plugin Version 3.2.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 3.2.0 https://maven.apache.org/plugins/maven-shade-plugin/ Important Note since 3.2.0: * Maven 3.X only * If you like to use minimizeJar you have to use JDK8+ otherwise you can keep running with JDK7. You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-shade-plugin 3.2.0 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 3.2.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12343491 Bug: * [MSHADE-289] - Maven Shade Plugin does not work under Java 10 Improvement: * [MSHADE-293] - Require Java 7 Dependency upgrades: * [MSHADE-294] - Upgrade maven-plugins parent to version 32 * [MSHADE-296] - Upgrade maven-artifact-transfer 0.10.0 Enjoy - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shade Plugin Version 3.1.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 3.1.1 https://maven.apache.org/plugins/maven-shade-plugin/ Important Note since 3.1.1: * Maven 3.X only You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-shade-plugin 3.1.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 3.1.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12341390 Bugs: * [MSHADE-273] - Shading of paths starting with / ignores excludes * [MSHADE-275] - Maven Shade Plugin does not work under Java 10 Improvements: * [MSHADE-277] - Identify issue related IT failure mini-jar-malformed-dependencies/pom.xml * [MSHADE-278] - Print out the jar responsible for exceptions like "Error creating shaded jar: invalid LOC header (bad signature)" * [MSHADE-283] - Add documentation information for GitHub Dependency upgrades: * [MSHADE-276] - Upgrade parent to 31 * [MSHADE-279] - Upgrade mave-surefire/failsafe-plugin 2.21.0 * [MSHADE-280] - Upgrade jdom 1.1.3 to jdom2 2.0.6 * [MSHADE-281] - Upgrade plexus-utils 3.1.0 * [MSHADE-282] - Remove not used directories rel-path-test-files Many thanks to all reporters/contributors/testers of this release. Reporters: * MSHADE-273: Eugene Kirpichov * MSHADE-275: Markus Grech * MSHADE-278: Gary Gregory Testers: * Markus Grech * Rafael Winterhalter Enjoy - The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
is it possible to use maven flatten plugin with maven shade plugin?
Hi all, Has anyone tried using the MojoHaus flatten plugin in conjunction with Maven shade plugin? The trick is to get the flatten plugin to flatten the DRP after shading, instead of the original pom. My goal is for the uber-jar to include a standalone POM that does not reference any parent POM, but still includes any original dependencies that were *not* shaded. So if the project has dependencies D1, D2, and D3, and the shade plugin is configured to put D2 and D3 into the uber-jar, then the DRP will contain only a dependency for D1. I then want the flatten plugin to remove the parent information (and some of the other stuff it removes) from the DRP, put the updated POM into the uber-jar, and then we proceed to mvn install/deploy with the uber-jar and flattened DRP. I'm guessing doing this will require code changes in the flatten plugin, but if there's a pure configuration way of achieving that would be terrific. Thanks for any input! -Richard
[ANN] Apache Maven Shade Plugin 3.1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.1.0 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. 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.1.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-shade-plugin/download.cgi Note: This is a Java 9 support release. Be aware when using this on jars with module descriptors; it's intended strong encapsulation (i.e. not exported packages) will be lost. This is actually a JVM issue which is hopefully resolved in a future version of Java. Release Notes - Maven Shade Plugin - Version 3.1.0 ** Bug * [MSHADE-242] - Plugin does not work with Java 9 * [MSHADE-247] - NullpointerException when createSourcesJar = true and source jar cannot be found * [MSHADE-253] - NullPointerException if minimizeJar == true && packaging == pom * [MSHADE-255] - IllegalArgumentException on relocating class * [MSHADE-258] - RemappingClassAdapter is deprecated and throws an exception with ASM 6.0 beta ** Improvement * [MSHADE-257] - Bad zero length source jars published by 3rd parties cause source jar creation to fail. Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Shade Plugin - How to Shade
Hi, Quick help - This is the first time i am using the shade plugin. I saw the shading documentation here - but could not figure out which transformer should I use - https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html My requirement is this - I am using Apache Spark 1.6 that has a dependency on JPMML 1.1.15 as documented here - https://repository.cloudera.com/artifactory/cloudera-repos/org/apache/spark/spark-mllib_2.10/1.6.0-cdh5.7.5-SNAPSHOT/spark-mllib_2.10-1.6.0-cdh5.7.5-20161028.092134-21.pom org.jpmml * pmml-model* * 1.1.15* compile FastInfoset com.sun.xml.fastinfoset istack-commons-runtime com.sun.istack My code uses org.jpmml version 1.2.6 org.jpmml pmml-model 1.2.6 Now my shade pom snippet looks like - org.apache.maven.plugins maven-shade-plugin 2.4.1 package shade org.jpmml my.spark.jpmml But this does not work as intended and my package fails. Any idea what is missing here. Thanks, Manish
[ANN] Apache Maven Shade Plugin 3.0.0 Released
Hi, The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 3.0.0 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. 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.0.0 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.0.0 ** Improvement * [MSHADE-219] - Update XSD location of POM to the new one in POMWriter * [MSHADE-224] - Preserve last modified time in resources files. * [MSHADE-225] - Writing output only once * [MSHADE-232] - Introduce ResourceBundleAppendingTransformer * [MSHADE-241] - Groovy extension module transformer * [MSHADE-246] - Switch to maven-artifact-transfer to support both Aether implementations ** Bug * [MSHADE-182] - ServicesResourceTransformer incorrectly ignores given Relocators * [MSHADE-223] - Endless processing when promoteTransitiveDependencies=true * [MSHADE-228] - Shade can incorrectly re-write an InterfaceMethodRef in the constant pool to a MethodRef * [MSHADE-237] - ServicesResourceTransformer relocates excluded classes * [MSHADE-239] - Shaded Source JAR not following finalName pattern * [MSHADE-240] - support relocation pom.properties and pom.xml descriptors in shaded jars ** Task * [MSHADE-222] - Dependency updates. Enjoy, -The Apache Maven team
Re: maven-shade-plugin and classifiers
Hi, If you only have to shade an attached artifact I wonder if your project setup is correct. Without knowing the details I would expect that this classified jar should be a separate module in a Maven multimodule project Robert On Thu, 08 Dec 2016 12:11:28 +0100, Túlio Gomes <tuliogom...@hotmail.com> wrote: Hi there, I’m having some trouble while working with maven-shade-plugin, profiles and classifiers. I need my classified jar to be an input to the shade plugin. Currently only the main artifact is an input. If i change the execution id of maven-jar-plugin to “default-jar”, the following error is thrown: “Failed to create shaded artifact, project main artifact does not exist.” Is there any option that i can use that take my classified jar in consideration? Thanks in advance. Enviado do Email<https://go.microsoft.com/fwlink/?LinkId=550986> para Windows 10 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-shade-plugin and classifiers
Hi there, I’m having some trouble while working with maven-shade-plugin, profiles and classifiers. I need my classified jar to be an input to the shade plugin. Currently only the main artifact is an input. If i change the execution id of maven-jar-plugin to “default-jar”, the following error is thrown: “Failed to create shaded artifact, project main artifact does not exist.” Is there any option that i can use that take my classified jar in consideration? Thanks in advance. Enviado do Email<https://go.microsoft.com/fwlink/?LinkId=550986> para Windows 10
Re: maven-shade-plugin and Eclipse (m2e)
http://blog.artifact-software.com/tech/?p=121 and other Maven posts might give you some ideas about handling large numbers of third party jars in a large project. We use Eclipse/STS and Maven. Ron On 30/06/2016 11:10 AM, Eddie Galvez wrote: What is the way to use the maven-shade-plugin but, what I think is the obvious usage then of such a shaded project, to have it in eclipse as a source project? In other words - because maven-shade-plugin only does its thing on package... while you are in Eclipse (your IDE), other projects will not compile since they are expecting the shaded package names... what's the way to be able to work with a project that you want to maven-shade-plugin some third party dependencies in, for use within and inside eclipse? Cleary I understand you can just package/install the shaded project into a repository then NOT bring in the source project into the workspace... but ideally I don't want that. Thanks! -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-shade-plugin and Eclipse (m2e)
Hi! I think nothing should depend on shaded names. Everything should use original names, which is then fixed by the shade plugin during packaging. Regards, Aliaksei On Thu, Jun 30, 2016 at 5:10 PM, Eddie Galvez <egal...@tibco.com> wrote: > What is the way to use the maven-shade-plugin but, what I think is the > obvious usage then of such a shaded project, to have it in eclipse as a > source project? > > In other words - because maven-shade-plugin only does its thing on > package... while you are in Eclipse (your IDE), other projects will not > compile since they are expecting the shaded package names... what's the way > to be able to work with a project that you want to maven-shade-plugin some > third party dependencies in, for use within and inside eclipse? > > Cleary I understand you can just package/install the shaded project into a > repository then NOT bring in the source project into the workspace... but > ideally I don't want that. > > Thanks! >
maven-shade-plugin and Eclipse (m2e)
What is the way to use the maven-shade-plugin but, what I think is the obvious usage then of such a shaded project, to have it in eclipse as a source project? In other words - because maven-shade-plugin only does its thing on package... while you are in Eclipse (your IDE), other projects will not compile since they are expecting the shaded package names... what's the way to be able to work with a project that you want to maven-shade-plugin some third party dependencies in, for use within and inside eclipse? Cleary I understand you can just package/install the shaded project into a repository then NOT bring in the source project into the workspace... but ideally I don't want that. Thanks!
[ANN] Apache Maven Shade Plugin 2.4.3 Released
Hi, The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 2.4.3 The release contains 4 bug fixes. Again we received contributions from the community in form of bug reports and bug fixes. Thank you and keep them coming! 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 2.4.3 Release Notes - Maven Shade Plugin - Version 2.4.3 Bug [MSHADE-171] - Access Denied on Windows because shade plugin seems to try to open a directory as Zip-File [MSHADE-195] - createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail Improvement [MSHADE-213] - Clarify contract of ResourceTransformer wrt closing of streams [MSHADE-214] - Update jdependency to 1.1 to fix resource leaks Enjoy, -The Apache Maven team
[ANN] Apache Maven Shade Plugin 2.4.3 Released
Hi, The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 2.4.3 The release contains 4 bug fixes. Again we received contributions from the community in form of bug reports and bug fixes. Thank you and keep them coming! 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 2.4.3 Release Notes - Maven Shade Plugin - Version 2.4.3 Bug [MSHADE-171] - Access Denied on Windows because shade plugin seems to try to open a directory as Zip-File [MSHADE-195] - createSourcesJar with source:jar-no-fork causes sources.jar to be deployed twice, causing the build to fail Improvement [MSHADE-213] - Clarify contract of ResourceTransformer wrt closing of streams [MSHADE-214] - Update jdependency to 1.1 to fix resource leaks Enjoy, -The Apache Maven team
[ANN] Apache Maven Shade Plugin Version 2.4.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 2.4.2. This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. 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 2.4.2 You can download the [appropriate sources etc. from the download page](http://maven.apache.org/plugins/maven-shade-plugin/download.cgi). Release Notes - Apache Maven Shade Plugin Version 2.4.2 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12333008 Bugs: * [MSHADE-172] - "java.lang.ArithmeticException: / by zero" in MinijarFilter * [MSHADE-190] - Shade does not relocate the contents of META-INF/services files * [MSHADE-209] - [REGRESSION] "java.lang.ArithmeticException: / by zero" in MinijarFilter (reporter Jon McLean). Improvements: * [MSHADE-205] - Better use of ClazzpathUnit for improved jar minimization (contribution of Benoit Perrot). * [MSHADE-207] - Replace wrong link to codehaus with correct location * [MSHADE-210] - Upgrade maven-plugins parent to version 28. * [MSHADE-211] - Keep Java 1.5 Enjoy, The Apache Maven team Thanks to contributors and reporters. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shade Plugin Version 2.4.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin Version 2.4.1 http://maven.apache.org/plugins/maven-shade-plugin/ This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.4.1/version /plugin You can download the appropriate sources etc. from the download page: http://maven.apache.org/plugins/maven-shade-plugin/download.cgi Release Notes - Maven Shade Plugin - Version 2.4.1 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921version=12332978 Bugs: * [MSHADE-148] - Shade Plugin gets stuck in infinite loop building dependency reduced POM * [MSHADE-194] - Reporting uses maven-invoker-plugin version 1.9 instead of 1.10 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven shade plugin generates uber-jar but in a file name like *.pom
Hi, just simply use finalNameclient-api-all/finalName .. Kind regards Karl Heinz Marbaise On 7/13/15 1:02 AM, Zheng, Kai wrote: Hi experts, With the following, it generates a uber-jar, but the generated jar file name isn't expected, being client-api-all.jar.pom. Note the content is correct, containing classes files, not any POM stuff. Would anyone help? Thanks a lot. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.4/version executions execution phasepackage/phase goals goalshade/goal /goals configuration finalNameclient-api-all.jar/finalName /configuration /execution /executions /plugin Regards, Kai - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven shade plugin generates uber-jar but in a file name like *.pom
Thanks Karl for the response. I just logged an issue as follows. It was caused by the bad packaging (it's 'pom' instead of 'jar'). Would you comment on it? Thanks. https://issues.apache.org/jira/browse/MSHADE-198 Regards, Kai -Original Message- From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de] Sent: Monday, July 13, 2015 2:04 PM To: Maven Users List Subject: Re: Maven shade plugin generates uber-jar but in a file name like *.pom Hi, just simply use finalNameclient-api-all/finalName .. Kind regards Karl Heinz Marbaise On 7/13/15 1:02 AM, Zheng, Kai wrote: Hi experts, With the following, it generates a uber-jar, but the generated jar file name isn't expected, being client-api-all.jar.pom. Note the content is correct, containing classes files, not any POM stuff. Would anyone help? Thanks a lot. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.4/version executions execution phasepackage/phase goals goalshade/goal /goals configuration finalNameclient-api-all.jar/finalName /configuration /execution /executions /plugin Regards, Kai - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven shade plugin generates uber-jar but in a file name like *.pom
Hi experts, With the following, it generates a uber-jar, but the generated jar file name isn't expected, being client-api-all.jar.pom. Note the content is correct, containing classes files, not any POM stuff. Would anyone help? Thanks a lot. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.4/version executions execution phasepackage/phase goals goalshade/goal /goals configuration finalNameclient-api-all.jar/finalName /configuration /execution /executions /plugin Regards, Kai
[ANN] Apache Maven Shade Plugin Version 2.4 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Version 2.4 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. http://maven.apache.org/maven-shade-plugin/ Release Notes - Apache Maven Shade - Version 2.4 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921version=12331393 Bugs: * [MSHADE-155] - dependency-reduced-pom should use shadedArtifactId * [MSHADE-169] - Typos in warning message * [MSHADE-172] - java.lang.ArithmeticException: / by zero in MinijarFilter * [MSHADE-174] - Unable to shade Java 8 jarfiles with static interface methods using minimizeJar * [MSHADE-183] - Getting Error creating shaded jar: java.util.jar.Attributes cannot be cast to java.lang.String error when using ManifestResourceTransformer with Maven 3.2.5 * [MSHADE-185] - systemPath content is interpolated for system dependencies Improvements: * [MSHADE-177] - MavenProject/MavenSession Injection as a paremeter instead as a component. * [MSHADE-178] - Removing plexus-container-default dependency * [MSHADE-179] - Fix RAT Report * [MSHADE-180] - Upgrade plexus-utils to 3.0.18 * [MSHADE-188] - Upgrade maven-dependency-tree to 2.2 * [MSHADE-191] - Upgrade plexus-utils to 3.0.22 * [MSHADE-192] - Upgrade maven-invoker to 1.10 * [MSHADE-193] - Upgrade to fluido skin 1.4.0 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-shade-plugin question
What am I supposed to do with dependency-reduced-pom.xml? Add it to revision control or ignore it? Not entirely clear why I need it, but it's added by default so assume it's important. Also, the documentation for it is incorrect. The file is by default written to the base dir and not the same dir as the shaded artifact (target). Thanks, James
Re: maven-shade-plugin question
On 14 January 2015 at 10:12, James Green james.mk.gr...@gmail.com wrote: What am I supposed to do with dependency-reduced-pom.xml? Add it to revision control or ignore it? I say ignore it. For technical reasons a dependency reduced pom needs to land in the same directory as the pom it is replacing It is generated from the pom.xml, so you should not add it to SCM Not entirely clear why I need it, but it's added by default so assume it's important. Also, the documentation for it is incorrect. The file is by default written to the base dir and not the same dir as the shaded artifact (target). Correct because IIUC the rector model is changed to point to this dependency reduced pom and consequently other code will break if the relative path from the depenency-reduced-pom.xml to the target/classes directory is changed. Thanks, James
Shade plugin: Shade more than one artifact
Hi there, first, apologies, if I am on the wrong list for this topic, maybe there is a more specific list, so feel free to point me towards it. I am currently trying to persuade the shade plugin to actually shade more than one artifact. My goal is to create two different test jars. One, which contains only the needed infrastructure to use in other projects and another one, that includes all the tests of the current project, so I can take that jar, unpack it in another project and run all the tests in the scope of that project (this is used for a plugin the main project, to make sure, that this plugin does not accidentally remove features needed for normal functioning). The plugin cannot be merged or created as a sub-module of the main project, from which I want to create the jars. My current (non-working) workflow is to create two jars using the maven-jar-plugin and let the shade plugin do its work, which it does only with the default jar. My current workaround is to have a default mvn profile which creates the slim test jar and another one, which creates the fat test jar - however I would like to built both at the same time and deploy them. The pom.xml from my current workaround can be found at https://github.com/spinscale/elasticsearch/blob/build/test-jar-profiles/pom.xml#L1501-L1632 I'd love to get some feedback if this is possible at all using the shade plugin, or if my approach is bad and I am supposed to do something completely different. Thanks a lot and have a nice day! --Alex
Q: Shade Plugin - LICENSE and NOTICE
Hi Maveners, Greetings from Apache Olingo :) I am working with the shade plugin to create ueber jar for Android use case. The plugin is cool and technically everything is fine. But I am having problems to get the LICENSE and NOTICE files included as required by Apache policies. I tried out all the Shade features for transforming, merging and filtering these files. At the end I don't get what I want. So my basic question is: Can I filter out META-INF/LICENSE.* and META-INF/NOTICE.* files from all dependencies and add my handcrafted META-INF/LICENSE and META-INF/NOTICE files as part of my own module to the ueber jar? If I add a filter like this: filters filter artifact*:*/artifact excludes excludeMETA-INF/**/exclude /excludes /filter /filters Then I don't get my own files in. Any hint is welcome. Greetings, Stephan [1] http://olingo.apache.org
[ANN] Apache Maven Shade Plugin 2.3 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 2.3. This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. http://maven.apache.org/plugins/maven-shade-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.3/version /plugin Release Notes - Maven Shade Plugin - Version 2.3 ** Bug * [MSHADE-166] - maven-shade-plugin not compatible with Java 8 ** Improvement * [MSHADE-167] - [PATCH] When individual classes are renamed, they are not debuggable Have Fun! -- The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-shade-plugin Class Overlap
Wayne Fay wrote I use shade but won't pretend to be an expert on all the configuration options. I will assume you RTFM already. Did you consider using class relocation to move the overlapping classes to com.dontuse? Or perhaps an artifact filter to just eliminate them entirely? Just thinking out loud, I'm not sure what the order is/should be. Wayne Hi there, Thanks for the reply, I was curious how would you throw together a filter that could handle something like that? I didn't see anything like that on their website. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-shade-plugin-Class-Overlap-tp5787056p5787741.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-shade-plugin Class Overlap
Thanks for the reply, I was curious how would you throw together a filter that could handle something like that? I didn't see anything like that on their website. Do you know the name(s) of the files that overlap? If so, surely a filter that specifies them could be created. If not, that's the place to start. For fine-grained control of which classes from the selected dependencies are included, artifact filters can be used: https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-shade-plugin Class Overlap
Wayne Fay wrote Do you know the name(s) of the files that overlap? If so, surely a filter that specifies them could be created. If not, that's the place to start. For fine-grained control of which classes from the selected dependencies are included, artifact filters can be used: https://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html Wayne Well, I can find out which are and aren't but they change every release, and there will be many eventually. Which the filter using include/excludes would be unmanageable when it gets as large as I imagine it will be -- View this message in context: http://maven.40175.n5.nabble.com/Maven-shade-plugin-Class-Overlap-tp5787056p5787785.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-shade-plugin Class Overlap
Well, I can find out which are and aren't but they change every release, and there will be many eventually. Which the filter using include/excludes would be unmanageable when it gets as large as I imagine it will be Try this experiment for me. Make 3 jar file with content as follows: 1.jar a.class, b.class, c.class 2.jar c.class, d.class, e.class 3.jar a.class, c.class, f.class Put some text in each file so you know which version (1, 2, or 3) the file represents. These don't need to be real class files, just plain txt files. Now play with the shade plugin configuration to see you can predict/configure the ordering of how these files are merged together. You want something repeatable of course. I assume there is some implicit ordering which takes place and which you can leverage to guarantee your later versions of these files overwrites the earlier ones. If you can do this, then I think you will be able to see a solution to your own problem. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven-shade-plugin Class Overlap
I'm trying to use maven shade to overlay all of my changes to a jar on top of another in a manner similar to a jar overlay. However there are some classes that overlap in my source files with the jar I wish to overlap. After I build, the ones that overlap are replaced by what is in the jar's i'm overlaying. I want to know if it's possible to either chose the order the jars are added or to tell it to skip any classes that overlap. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-shade-plugin-Class-Overlap-tp5787056.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven-shade-plugin Class Overlap
I'm trying to use maven shade to overlay all of my changes to a jar on top of another in a manner similar to a jar overlay. However there are some classes that overlap in my source files with the jar I wish to overlap. After I build, the ones that overlap are replaced by what is in the jar's i'm overlaying. I want to know if it's possible to either chose the order the jars are added or to tell it to skip any classes that overlap. I use shade but won't pretend to be an expert on all the configuration options. I will assume you RTFM already. Did you consider using class relocation to move the overlapping classes to com.dontuse? Or perhaps an artifact filter to just eliminate them entirely? Just thinking out loud, I'm not sure what the order is/should be. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Add Apache License to reduced pom (shade plugin)
that JIRA is different. It is asking for _comments_ from the original pom to flow through, which is pretty nearly impossible. if you ask for a brand new comment to be inserted based on some configuration element, and better yet offer a patch, that's doable. On Sun, Feb 9, 2014 at 5:20 PM, Flavio Junqueira fpjunque...@yahoo.com wrote: Thanks for getting back, but I'm not sure creating a jira is any good in this case. We've found this jira: https://jira.codehaus.org/browse/MSHADE-48 which has been open for quite some time. I'm basically interested in what other projects have had this same problem and how they solved it. Perhaps it is ok to have the reduced pom without a license because it is a generated file. Thanks, -Flavio On 09 Feb 2014, at 03:22, Benson Margulies bimargul...@gmail.com wrote: Please file a JIRA on the shade plugin. On Sat, Feb 8, 2014 at 10:48 AM, Flavio Junqueira fpjunque...@yahoo.com wrote: Hi there, We are using the shade plugin in the Apache BookKeeper project (BOOKKEEPER-724, BOOKKEEPER-730) and we originally wanted to the add the Apache license to the reduced pom generated so that we could ship it with our next release. However, we couldn't find any option that allows us to add the license automatically. Is it right that there is no option to add it automatically to the reduced pom? If this is right, then the next question is if we really need to add the license header to a generated file. Has anyone had this problem before? Any suggestion of how to deal with this problem? Thanks! -Flavio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Add Apache License to reduced pom (shade plugin)
Thanks for getting back, but I'm not sure creating a jira is any good in this case. We've found this jira: https://jira.codehaus.org/browse/MSHADE-48 which has been open for quite some time. I'm basically interested in what other projects have had this same problem and how they solved it. Perhaps it is ok to have the reduced pom without a license because it is a generated file. Thanks, -Flavio On 09 Feb 2014, at 03:22, Benson Margulies bimargul...@gmail.com wrote: Please file a JIRA on the shade plugin. On Sat, Feb 8, 2014 at 10:48 AM, Flavio Junqueira fpjunque...@yahoo.com wrote: Hi there, We are using the shade plugin in the Apache BookKeeper project (BOOKKEEPER-724, BOOKKEEPER-730) and we originally wanted to the add the Apache license to the reduced pom generated so that we could ship it with our next release. However, we couldn't find any option that allows us to add the license automatically. Is it right that there is no option to add it automatically to the reduced pom? If this is right, then the next question is if we really need to add the license header to a generated file. Has anyone had this problem before? Any suggestion of how to deal with this problem? Thanks! -Flavio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Add Apache License to reduced pom (shade plugin)
Hi there, We are using the shade plugin in the Apache BookKeeper project (BOOKKEEPER-724, BOOKKEEPER-730) and we originally wanted to the add the Apache license to the reduced pom generated so that we could ship it with our next release. However, we couldn't find any option that allows us to add the license automatically. Is it right that there is no option to add it automatically to the reduced pom? If this is right, then the next question is if we really need to add the license header to a generated file. Has anyone had this problem before? Any suggestion of how to deal with this problem? Thanks! -Flavio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Add Apache License to reduced pom (shade plugin)
Please file a JIRA on the shade plugin. On Sat, Feb 8, 2014 at 10:48 AM, Flavio Junqueira fpjunque...@yahoo.com wrote: Hi there, We are using the shade plugin in the Apache BookKeeper project (BOOKKEEPER-724, BOOKKEEPER-730) and we originally wanted to the add the Apache license to the reduced pom generated so that we could ship it with our next release. However, we couldn't find any option that allows us to add the license automatically. Is it right that there is no option to add it automatically to the reduced pom? If this is right, then the next question is if we really need to add the license header to a generated file. Has anyone had this problem before? Any suggestion of how to deal with this problem? Thanks! -Flavio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Apache Maven Shade Plugin 2.2 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Shade Plugin, version 2.2 This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies. http://maven.apache.org/plugins/maven-shade-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.2/version /plugin Release Notes - Apache Maven Shade Plugin - Version 2.2 ** Improvement * [MSHADE-158] - Allow shading of test jar Have fun -- The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven shade plugin: Retaining origin file timestamps
For now, as a work around, I wrote a shell script that after the shading process rewrites the timestamps of clojure files to sometime in the past. I am using maven-exec-plugin to run that shell script. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-shade-plugin-Retaining-origin-file-timestamps-tp5773664p5773994.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven shade plugin: Retaining origin file timestamps
We could remove clj files from the jar altogether. However, the problem is we don't know if all the clojure dependencies are AOT compiled. So, some of the clojure files should be compiled on the fly. The problem is when dynamically compiling clojure files whose class files already exist in the jar. -- View this message in context: http://maven.40175.n5.nabble.com/Maven-shade-plugin-Retaining-origin-file-timestamps-tp5773664p5773855.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven shade plugin: Retaining origin file timestamps
We could remove clj files from the jar altogether. However, the problem is we don't know if all the clojure dependencies are AOT compiled. So, some of the clojure files should be compiled on the fly. The problem is when dynamically compiling clojure files whose class files already exist in the jar. Well, I see this as an opportunity to do that work today. If you just figure this out now, you will have a short list of files to filter out during the packaging step. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven shade plugin: Retaining origin file timestamps
Hello, I am currently using maven shade plugin to package a project jar that would contain some java libraries as well as some clojure libraries. After some investigation into load time performance issue, I found that maven shade plugin default behaviour is to re-write or create the files, which means new timestamps will be present in jar for all the files. This generally wouldn't have been a problem if it is just Java files. Clojure compilation current behaviour is that if two files - one clojure, one java file have the same timestamp then it would give clojure file priority and would compile it on the fly. For example, if a.clj and a corresponding a.class is present with equal timestamps then clojure would think that a.clj is newer and would compile it. This is causing all the clojure files to be compiled again and thus causing jar load time to increase. Is there a workaround to overcome this default behaviour from maven-shade-plugin ? Thanks, Kranthi
Re: Maven shade plugin: Retaining origin file timestamps
compile it on the fly. For example, if a.clj and a corresponding a.class is present with equal timestamps then clojure would think that a.clj is newer and would compile it. This is causing all the clojure files to be compiled again and thus causing jar load time to increase. Perhaps just don't include the *.clj files in your final assembly? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: shade plugin usage
Help the Java community kill all überjars... /Anders On Thu, Sep 5, 2013 at 5:21 AM, Richard Sand rs...@idfconnect.com wrote: Hi Anders - thanks for your reply. I agree with your advice - for this particular project artifact is a case where we want to offer both options, and the uberjar is mainly an aggregation of our product apis. But I definitely understand the danger you are describing. -Richard -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Wednesday, September 04, 2013 2:08 AM To: Maven Users List Subject: Re: shade plugin usage First, try to stay away from the überjar path. It's normally not the way to go today, but you should use the jar and it's dependencies instead. I've seen many case where people use a überjar just to try to make their life simpler but ending up with other issues instead. A proper classpath is the way to go in my opinion. I guess your approach of deploying the überjar and a dep-reduced-pom would work, but please remember to deploy it to your remote repo as well (and not just your local repo). Somewhere in the back of my head I recall a similar discussion earlier. Not sure if someone brought up any issues though. Having said that, the reason for deploying the überjar at a separate coordinate would be to have a separate pom with reduced deps. This indicates that you plan on use the pom to get the dependencies and in that case you should try to stick with the original jar instead and work with the proper set of deps. /Anders On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand rs...@idfconnect.com wrote: I've a project that uses shade to create an uberjar - since I want that uberjar artifact to be available for use in other projects, does it make sense to *not* attach the artifact in shade, but rather have shade create the uberjar and dependency-reduced-pom, and then use install:install-file to grab the uberjar and drp.xml and install with a new unique artifactid (as opposed to a classifier of the original artifact)? Still feeling my way down the Maven Way... -Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: shade plugin usage
Hi Anders, Help the Java community kill all überjars... Personally, I am a fan of uberjars as long as the encapsulated dependencies are shaded to avoid package clashes. Then you can use multiple dependency versions without crazy classloading like OSGi does. I used this feature just the other day when I needed to invoke Jython from a JVM that had an incompatible version of ASM on the classpath already. Fortunately, the Jython developers provided a shaded uberjar (which they call standalone) which did the trick. I've also spent lots of hours troubleshooting NoSuchMethodError and ClassNotFoundException bug reports in user installations of our applications which developed JAR skew between dependencies. Uberjars (when done carefully) avoid that mess. Of course there are downsides too, but I wouldn't say uberjars are always a bad idea. The nastiest thing about them is really when the producers *don't* shade the dependency packages. Regards, Curtis On Thu, Sep 5, 2013 at 1:18 AM, Anders Hammar and...@hammar.net wrote: Help the Java community kill all überjars... /Anders On Thu, Sep 5, 2013 at 5:21 AM, Richard Sand rs...@idfconnect.com wrote: Hi Anders - thanks for your reply. I agree with your advice - for this particular project artifact is a case where we want to offer both options, and the uberjar is mainly an aggregation of our product apis. But I definitely understand the danger you are describing. -Richard -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Wednesday, September 04, 2013 2:08 AM To: Maven Users List Subject: Re: shade plugin usage First, try to stay away from the überjar path. It's normally not the way to go today, but you should use the jar and it's dependencies instead. I've seen many case where people use a überjar just to try to make their life simpler but ending up with other issues instead. A proper classpath is the way to go in my opinion. I guess your approach of deploying the überjar and a dep-reduced-pom would work, but please remember to deploy it to your remote repo as well (and not just your local repo). Somewhere in the back of my head I recall a similar discussion earlier. Not sure if someone brought up any issues though. Having said that, the reason for deploying the überjar at a separate coordinate would be to have a separate pom with reduced deps. This indicates that you plan on use the pom to get the dependencies and in that case you should try to stick with the original jar instead and work with the proper set of deps. /Anders On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand rs...@idfconnect.com wrote: I've a project that uses shade to create an uberjar - since I want that uberjar artifact to be available for use in other projects, does it make sense to *not* attach the artifact in shade, but rather have shade create the uberjar and dependency-reduced-pom, and then use install:install-file to grab the uberjar and drp.xml and install with a new unique artifactid (as opposed to a classifier of the original artifact)? Still feeling my way down the Maven Way... -Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: shade plugin usage
From: ctrue...@wisc.edu Date: Thu, 5 Sep 2013 10:37:34 -0500 Subject: Re: shade plugin usage To: users@maven.apache.org Hi Anders, Help the Java community kill all überjars... Personally, I am a fan of uberjars MG+1 as long as the encapsulated dependencies are shaded to avoid package clashes. Then you can use multiple dependency versions without crazy classloading like OSGi does. I used this feature just the other day when I needed to invoke Jython from a JVM that had an incompatible version of ASM on the classpath already. Fortunately, the Jython developers provided a shaded uberjar (which they call standalone) which did the trick. I've also spent lots of hours troubleshooting NoSuchMethodErrorMG*usually* Dependency Version Mismatch and ClassNotFoundException MG*usually* a Dependency Version Mismatch or the dependency is missing MG(mvn dependency:tree will identify the culprit) bug reports in user installations of our applications which developed JAR skew between dependencies. Uberjars (when done carefully) avoid that mess. Of course there are downsides too, but I wouldn't say uberjars are always a bad idea. The nastiest thing about them is really when the producers *don't* shade the dependency packages.MGwhat i've seen is the commercial codehauses 'brand' base packages with their company MGe.g. sonatype brands a lot of the googlecode librariesMGhaven't seen any other reason (other than package branding) for implementing shading .. Regards, CurtisMGRegards MGMartin- On Thu, Sep 5, 2013 at 1:18 AM, Anders Hammar and...@hammar.net wrote: Help the Java community kill all überjars... /Anders On Thu, Sep 5, 2013 at 5:21 AM, Richard Sand rs...@idfconnect.com wrote: Hi Anders - thanks for your reply. I agree with your advice - for this particular project artifact is a case where we want to offer both options, and the uberjar is mainly an aggregation of our product apis. But I definitely understand the danger you are describing. -Richard -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Wednesday, September 04, 2013 2:08 AM To: Maven Users List Subject: Re: shade plugin usage First, try to stay away from the überjar path. It's normally not the way to go today, but you should use the jar and it's dependencies instead. I've seen many case where people use a überjar just to try to make their life simpler but ending up with other issues instead. A proper classpath is the way to go in my opinion. I guess your approach of deploying the überjar and a dep-reduced-pom would work, but please remember to deploy it to your remote repo as well (and not just your local repo). Somewhere in the back of my head I recall a similar discussion earlier. Not sure if someone brought up any issues though. Having said that, the reason for deploying the überjar at a separate coordinate would be to have a separate pom with reduced deps. This indicates that you plan on use the pom to get the dependencies and in that case you should try to stick with the original jar instead and work with the proper set of deps. /Anders On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand rs...@idfconnect.com wrote: I've a project that uses shade to create an uberjar - since I want that uberjar artifact to be available for use in other projects, does it make sense to *not* attach the artifact in shade, but rather have shade create the uberjar and dependency-reduced-pom, and then use install:install-file to grab the uberjar and drp.xml and install with a new unique artifactid (as opposed to a classifier of the original artifact)? Still feeling my way down the Maven Way... -Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: shade plugin usage
First, try to stay away from the überjar path. It's normally not the way to go today, but you should use the jar and it's dependencies instead. I've seen many case where people use a überjar just to try to make their life simpler but ending up with other issues instead. A proper classpath is the way to go in my opinion. I guess your approach of deploying the überjar and a dep-reduced-pom would work, but please remember to deploy it to your remote repo as well (and not just your local repo). Somewhere in the back of my head I recall a similar discussion earlier. Not sure if someone brought up any issues though. Having said that, the reason for deploying the überjar at a separate coordinate would be to have a separate pom with reduced deps. This indicates that you plan on use the pom to get the dependencies and in that case you should try to stick with the original jar instead and work with the proper set of deps. /Anders On Wed, Sep 4, 2013 at 7:42 AM, Richard Sand rs...@idfconnect.com wrote: I've a project that uses shade to create an uberjar - since I want that uberjar artifact to be available for use in other projects, does it make sense to *not* attach the artifact in shade, but rather have shade create the uberjar and dependency-reduced-pom, and then use install:install-file to grab the uberjar and drp.xml and install with a new unique artifactid (as opposed to a classifier of the original artifact)? Still feeling my way down the Maven Way... -Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
