[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
[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
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
[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?
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
[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
[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
[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
Maven Shade-Plugin strange behavior
Hi all, I would like to know if this behavior is normal while using the maven-shade-plugin. Take this sample pom as input: project modelVersion4.0.0/modelVersion groupIdsample/groupId artifactIdshade-effect/artifactId packagingjar/packaging version1.0.0-SNAPSHOT/version build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.1/version executions execution phasepackage/phase goals goalshade/goal /goals configuration createDependencyReducedPomtrue/createDependencyReducedPom /configuration /execution /executions /plugin /plugins /build dependencies dependency groupIdcommons-io/groupId artifactIdcommons-io/artifactId version2.4/version /dependency dependency groupIdorg.mockito/groupId artifactIdmockito-core/artifactId version1.9.5/version scopetest/scope /dependency /dependencies /project And do a mvn clean install. The real pom that is deployed in the repository is the one that has been transformed by the shade plugin (ie: dependency-reduced-pom.xml) If I look at this pom, the compile dependencies are removed as expected. Good. But, if you look at the dependencies with scope test, they is a super strange behavior: project modelVersion4.0.0/modelVersion groupIdsample/groupId artifactIdshade-effect/artifactId version1.0.0-SNAPSHOT/version build plugins plugin artifactIdmaven-shade-plugin/artifactId version2.1/version executions execution phasepackage/phase goals goalshade/goal /goals configuration createDependencyReducedPomtrue/createDependencyReducedPom /configuration /execution /executions /plugin /plugins /build dependencies dependency groupIdorg.mockito/groupId artifactIdmockito-core/artifactId version1.9.5/version scopetest/scope exclusions exclusion artifactIdhamcrest-core/artifactId groupIdorg.hamcrest/groupId /exclusion exclusion artifactIdobjenesis/artifactId groupIdorg.objenesis/groupId /exclusion /exclusions /dependency /dependencies /project Why are all the transitive dependencies of the test artifacts being excluded It surprise me a lot (and made some of my jobs fails in specific situations, for example when using Sonar, but that's another story/problem) BTW: I use Maven 3.0.5 Thanks for your help. WBR // David
Re: Maven Shade-Plugin strange behavior
Am 2013-08-30 17:47, schrieb David Gay: [...] Why are all the transitive dependencies of the test artifacts being excluded It surprise me a lot (and made some of my jobs fails in specific situations, for example when using Sonar, but that's another story/problem) Please suffer with me: https://jira.codehaus.org/browse/MSHADE-95 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
AppendingTransformer in maven shade plugin to support pattern matches?
Hello, The org.apache.maven.plugins.shade.resource.AppendingTransformer in the maven shade plugin (v 2.0) only supports exact resource name matches for appending resources for the uber jar. Do you guys see any problems if this this supports patterns that might be able to do it for a bunch of resources at a time, rather than repeating the names of the files: transformer implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer resourceMETA-INF/spring.*/resource /transformer instead of transformer implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer resourceMETA-INF/spring.handlers/resource /transformer transformer implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer resourceMETA-INF/spring.schemas/resource /transformer If you don't see a problem, I can go ahead and propose a patch for it. Thanks in advance!
AppendingTransformer in maven shade plugin to support pattern matches?
Hello, The org.apache.maven.plugins.shade.resource.AppendingTransformer in the maven shade plugin (v 2.0) only supports exact resource name matches for appending resources for the uber jar. Do you guys see any problems if this this supports patterns that might be able to do it for a bunch of resources at a time, rather than repeating the names of the files: transformer implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer resourceMETA-INF/spring.*/resource /transformer instead of transformer implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer resourceMETA-INF/spring.handlers/resource /transformer transformer implementation=org.apache.maven.plugins.shade.resource.AppendingTransformer resourceMETA-INF/spring.schemas/resource /transformer If you don't see a problem, I can go ahead and propose a patch for it. Thanks in advance!
[ANN] Maven Shade Plugin 2.1 Released
The Maven team is pleased to announce the release of the Maven Shade Plugin, version 2.1 Repackages the project classes together with their dependencies into a single uber-jar, optionally renaming classes or removing unused classes. 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.1/version /plugin Release Notes - Maven 2.x Shade Plugin - Version 2.1 ** Bug * [MSHADE-122] - NPE if packaging == pom * [MSHADE-132] - Shade does not buffer output, yielding excessive write syscalls * [MSHADE-136] - Shade dependency reduced pom uses timestamp in artifact names instead of -SNAPSHOT * [MSHADE-138] - No way to control the archiver * [MSHADE-142] - Shade plugin does unbuffered output * [MSHADE-143] - add support for Maven 3.1-A1/Eclipse Aether 0.9-M2 to shade ** Improvement * [MSHADE-128] - Too many warnings We have duplicates * [MSHADE-133] - DontIncludeResourceTransformer only recognizes a single resource element ** New Feature * [MSHADE-135] - Add PluginXmlTransformer ** Task * [MSHADE-144] - Correct documentation examples (filters not nested inside configuration section) Enjoy, -The Apache Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Antwort: Re: Antwort: Re: Maven Shade Plugin
Hi, To prevent any problems, I have now split up the build into two builds (api-build and full-jar). I think I will introduce now a third project (with pom packaging) that will build up all modules and collect the artifacts that are needed. I hope that is a correct strategy to solve the problem. I would like to reuse the api.jar and the full.jar as artifacts that can be used as dependencies, therefore I take Jörg's comment into account, thanks! Best, Jan Mit freundlichen Grüßen / Best regards Jan Engler Central Research Development SICK AG Erwin-Sick-Str. 1 79183 Waldkirch, Germany Phone +49 7681 202-3214 mailto:jan.eng...@sick.de http://www.sick.com Von:Jörg Schaible joerg.schai...@scalaris.com An: users@maven.apache.org Datum: 01.03.2013 08:27 Betreff:Re: Antwort: Re: Maven Shade Plugin Hi Tim, Tim Kettler wrote: Am 28.02.2013 19:47, schrieb Joachim Durchholz: Am 28.02.2013 16:24, schrieb Jan Engler: At first: in fact this is only one artifact. The full jar contains all classes of the dependecies, the api a reduced set (using filtern in the shade plugin). Is there a (conceivable) Maven build that uses api.jar as a dependency? Then it must be the main artifact at its GAV (groupId/artifact/version) coordinate. Is there a (conceivable) Maven build that uses full.jar as a dependency? Then it must be the main artifact at its GAV coordinate. If both jars need to be main artifacts, they need to go to different GAV coordinates. Because the dependent projects that need either api.jar or full.jar have no way of specifying which of them they actually need, the dependency section in their poms can only specify the GAV coordinate. That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. A POM can just as well depend on a secondary artifact: dependency groupIdfoo/groupId artifactIdbar/artifactId version1.0/version classifierapi/classifier /dependency The complete coordinates of an artifact are GAVTC: group, artifact(name), version, type (default is jar), classifier (default is empty). That's not the real problem. What actually *is* a problem, if you depend on different artifacts that bring both jars as transitive dependencies - you cannot exclude e.g. the -api, because for exclusions you can only specify GA. :-/ - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Dr. Martin Krämer - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender)
Re: Antwort: Re: Maven Shade Plugin
Am 01.03.2013 08:26, schrieb Jörg Schaible: Hi Tim, Tim Kettler wrote: Am 28.02.2013 19:47, schrieb Joachim Durchholz: Am 28.02.2013 16:24, schrieb Jan Engler: At first: in fact this is only one artifact. The full jar contains all classes of the dependecies, the api a reduced set (using filtern in the shade plugin). Is there a (conceivable) Maven build that uses api.jar as a dependency? Then it must be the main artifact at its GAV (groupId/artifact/version) coordinate. Is there a (conceivable) Maven build that uses full.jar as a dependency? Then it must be the main artifact at its GAV coordinate. If both jars need to be main artifacts, they need to go to different GAV coordinates. Because the dependent projects that need either api.jar or full.jar have no way of specifying which of them they actually need, the dependency section in their poms can only specify the GAV coordinate. That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. A POM can just as well depend on a secondary artifact: dependency groupIdfoo/groupId artifactIdbar/artifactId version1.0/version classifierapi/classifier /dependency The complete coordinates of an artifact are GAVTC: group, artifact(name), version, type (default is jar), classifier (default is empty). That's not the real problem. What actually *is* a problem, if you depend on different artifacts that bring both jars as transitive dependencies - you cannot exclude e.g. the -api, because for exclusions you can only specify GA. :-/ Ouch, never ran into this one. - Jörg -Tim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Antwort: Re: Antwort: Re: Maven Shade Plugin
Ok, working with a split-up build project seems to work. The only problem that I face in the moment is that there is not only my 2 shaded jars (api and api-sources) but also a file called original-api.jar. The content of this jar is only the meta-inf folder and I don't want this file to be placed in my nexusAny hints? Best, Jan Mit freundlichen Grüßen / Best regards Jan Engler Central Research Development SICK AG Erwin-Sick-Str. 1 79183 Waldkirch, Germany Phone +49 7681 202-3214 mailto:jan.eng...@sick.de http://www.sick.com Von:Tim Kettler tim.kett...@udo.edu An: Maven Users List users@maven.apache.org Datum: 01.03.2013 09:49 Betreff:Re: Antwort: Re: Maven Shade Plugin Am 01.03.2013 08:26, schrieb Jörg Schaible: Hi Tim, Tim Kettler wrote: Am 28.02.2013 19:47, schrieb Joachim Durchholz: Am 28.02.2013 16:24, schrieb Jan Engler: At first: in fact this is only one artifact. The full jar contains all classes of the dependecies, the api a reduced set (using filtern in the shade plugin). Is there a (conceivable) Maven build that uses api.jar as a dependency? Then it must be the main artifact at its GAV (groupId/artifact/version) coordinate. Is there a (conceivable) Maven build that uses full.jar as a dependency? Then it must be the main artifact at its GAV coordinate. If both jars need to be main artifacts, they need to go to different GAV coordinates. Because the dependent projects that need either api.jar or full.jar have no way of specifying which of them they actually need, the dependency section in their poms can only specify the GAV coordinate. That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. A POM can just as well depend on a secondary artifact: dependency groupIdfoo/groupId artifactIdbar/artifactId version1.0/version classifierapi/classifier /dependency The complete coordinates of an artifact are GAVTC: group, artifact(name), version, type (default is jar), classifier (default is empty). That's not the real problem. What actually *is* a problem, if you depend on different artifacts that bring both jars as transitive dependencies - you cannot exclude e.g. the -api, because for exclusions you can only specify GA. :-/ Ouch, never ran into this one. - Jörg -Tim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Dr. Martin Krämer - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender)
Re: Antwort: Re: Maven Shade Plugin
Am 01.03.2013 07:17, schrieb Tim Kettler: That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. I knew. I just didn't want to contradict Stephen right away. Plus, classifiers are usually assumed to identify auxiliary artifacts for a main artifact, and I suspect it's going to create lots of configuration overhead in some plugins. Jörg promptly pointed out a problem that doesn't even involve plugins. A POM can just as well depend on a secondary artifact: dependency groupIdfoo/groupId artifactIdbar/artifactId version1.0/version classifierapi/classifier /dependency The complete coordinates of an artifact are GAVTC: group, artifact(name), version, type (default is jar), classifier (default is empty). Hm. Can I specify the type in a dependency as well? Just curious, I certainly don't want to do that, but I might stumble over artifacts configured that way. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Antwort: Re: Maven Shade Plugin
working with a split-up build project seems to work. The only problem that I face in the moment is that there is not only my 2 shaded jars (api and api-sources) but also a file called original-api.jar. The content of this jar is only the meta-inf folder and I don't want this file to be placed in my nexusAny hints? Yes, put it in Nexus even though you don't want to. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Antwort: Re: Re: Antwort: Re: Maven Shade Plugin
Hmmm, I don't understand this. I will have an more or less empty jar in my nexus then, which is useless and there for no reason? For what reason does that file exists then? Jan Mit freundlichen Grüßen / Best regards Jan Engler Central Research Development SICK AG Erwin-Sick-Str. 1 79183 Waldkirch, Germany Phone +49 7681 202-3214 mailto:jan.eng...@sick.de http://www.sick.com Von:Wayne Fay wayne...@gmail.com An: Maven Users List users@maven.apache.org Datum: 01.03.2013 14:00 Betreff:Re: Re: Antwort: Re: Maven Shade Plugin working with a split-up build project seems to work. The only problem that I face in the moment is that there is not only my 2 shaded jars (api and api-sources) but also a file called original-api.jar. The content of this jar is only the meta-inf folder and I don't want this file to be placed in my nexusAny hints? Yes, put it in Nexus even though you don't want to. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Dr. Martin Krämer - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender)
Re: Antwort: Re: Maven Shade Plugin
On 1 March 2013 12:08, Joachim Durchholz j...@durchholz.org wrote: Am 01.03.2013 07:17, schrieb Tim Kettler: That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. I knew. I just didn't want to contradict Stephen right away. The real issue is that the classified artifact will probably have different transitive dependencies from the primary, and hence the only way to handle that is to use a separate module... plus I get tire of all the 'splainin' Plus, classifiers are usually assumed to identify auxiliary artifacts for a main artifact, and I suspect it's going to create lots of configuration overhead in some plugins. Jörg promptly pointed out a problem that doesn't even involve plugins. A POM can just as well depend on a secondary artifact: dependency groupIdfoo/groupId artifactIdbar/artifactId version1.0/version classifierapi/classifier /dependency The complete coordinates of an artifact are GAVTC: group, artifact(name), version, type (default is jar), classifier (default is empty). Hm. Can I specify the type in a dependency as well? Just curious, I certainly don't want to do that, but I might stumble over artifacts configured that way. --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: Maven Shade Plugin
Am 01.03.2013 14:59, schrieb Stephen Connolly: On 1 March 2013 12:08, Joachim Durchholz j...@durchholz.org wrote: Am 01.03.2013 07:17, schrieb Tim Kettler: That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. I knew. I just didn't want to contradict Stephen right away. The real issue is that the classified artifact will probably have different transitive dependencies from the primary, and hence the only way to handle that is to use a separate module... plus I get tire of all the 'splainin' Let others do it then. Even better, improve the Maven docs. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: Maven Shade Plugin
On 1 March 2013 15:03, Joachim Durchholz j...@durchholz.org wrote: Am 01.03.2013 14:59, schrieb Stephen Connolly: On 1 March 2013 12:08, Joachim Durchholz j...@durchholz.org wrote: Am 01.03.2013 07:17, schrieb Tim Kettler: That's not correct. The classifier is part of the artifact coordinates just like group, artifact(name) and version. I knew. I just didn't want to contradict Stephen right away. The real issue is that the classified artifact will probably have different transitive dependencies from the primary, and hence the only way to handle that is to use a separate module... plus I get tire of all the 'splainin' Let others do it then. Sometimes I just need to respond ;-) Even better, improve the Maven docs. It's on my TODO list (see the dev list) --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Re: Antwort: Re: Maven Shade Plugin
Hmmm, I don't understand this. I will have an more or less empty jar in my nexus then, which is useless and there for no reason? For what reason does that file exists then? Most like you are missing a configuration of the shade plugin: shadedArtifactAttached boolean - Defines whether the shaded artifact should be attached as classifier to the original artifact. If false, the shaded jar will be the main artifact of the project http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#shadedArtifactAttached Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Re: Maven Shade Plugin
Joachim Durchholz j...@durchholz.org wrote on 03/01/2013 07:08:52 AM: The complete coordinates of an artifact are GAVTC: group, artifact(name), version, type (default is jar), classifier (default is empty). Hm. Can I specify the type in a dependency as well? Just curious, I certainly don't want to do that, but I might stumble over artifacts configured that way. Yes, I do this quite often when I have projects that produce secondary artifacts for use as WAR overlays. --JEC
Maven Shade Plugin
Hi everybody, Currently I am trying to build up an assembly for our project. I needed a filtered output so I came to the shade plugin. This is what I am doing: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.0/version executions execution idapi/id phasepackage/phase goals goalshade/goal /goals configuration createSourcesJartrue/createSourcesJar shadedClassifierNameapi/ shadedClassifierName shadedArtifactIdmyArtifact/ shadedArtifactId shadedArtifactAttachedtrue/ shadedArtifactAttached archive addMavenDescriptor / compress / forced / index / manifest addClasspath / addDefaultImplementationEntriestrue/addDefaultImplementationEntries addExtensions / classpathLayoutType / classpathMavenRepositoryLayout / classpathPrefix / customClasspathLayout / mainClass / packageName / /manifest manifestEntries !-- keyvalue/key -- /manifestEntries manifestFile / pomPropertiesFile / /archive artifactSet includes include*:*/include /includes excludes excludede.my.company: myDLL/exclude /excludes /artifactSet filters filter artifact*:*/artifact includes include de/my/company/package1/*/include include de/my/company/package2/*/include include de/my/company/package3/**/include include de/my/company/package4/api/**/include /includes /filter /filters /configuration /execution execution idfull/id phasepackage/phase goals goalshade/goal /goals configuration createSourcesJartrue/createSourcesJar shadedClassifierNamefull/ shadedClassifierName shadedArtifactIdmyArtifact/ shadedArtifactId shadedArtifactAttachedtrue/ shadedArtifactAttached archive addMavenDescriptor / compress / forced / index / manifest addClasspath / addDefaultImplementationEntriestrue/addDefaultImplementationEntries addExtensions / classpathLayoutType / classpathMavenRepositoryLayout / classpathPrefix / customClasspathLayout / mainClass / packageName /
Re: Maven Shade Plugin
There is a golden principle of maven, one artifact per module... You seem to be trying to get 4 artifacts out of 1 module... Not on the maven way are you! On Thursday, 28 February 2013, Jan Engler wrote: Hi everybody, Currently I am trying to build up an assembly for our project. I needed a filtered output so I came to the shade plugin. This is what I am doing: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version2.0/version executions execution idapi/id phasepackage/phase goals goalshade/goal /goals configuration createSourcesJartrue/createSourcesJar shadedClassifierNameapi/ shadedClassifierName shadedArtifactIdmyArtifact/ shadedArtifactId shadedArtifactAttachedtrue/ shadedArtifactAttached archive addMavenDescriptor / compress / forced / index / manifest addClasspath / addDefaultImplementationEntriestrue/addDefaultImplementationEntries addExtensions / classpathLayoutType / classpathMavenRepositoryLayout / classpathPrefix / customClasspathLayout / mainClass / packageName / /manifest manifestEntries !-- keyvalue/key -- /manifestEntries manifestFile / pomPropertiesFile / /archive artifactSet includes include*:*/include /includes excludes excludede.my.company: myDLL/exclude /excludes /artifactSet filters filter artifact*:*/artifact includes include de/my/company/package1/*/include include de/my/company/package2/*/include include de/my/company/package3/**/include include de/my/company/package4/api/**/include /includes /filter /filters /configuration /execution execution idfull/id phasepackage/phase goals goalshade/goal /goals configuration createSourcesJartrue/createSourcesJar shadedClassifierNamefull/ shadedClassifierName shadedArtifactIdmyArtifact/ shadedArtifactId shadedArtifactAttachedtrue/ shadedArtifactAttached archive addMavenDescriptor / compress / forced / index / manifest addClasspath / addDefaultImplementationEntriestrue/addDefaultImplementationEntries addExtensions / classpathLayoutType /
Re: Maven Shade Plugin
Am 28.02.2013 14:50, schrieb Jan Engler: As you might have seen, I want to have 4 artifacts: api.jar, api-sources.jar, full.jar, full-sources.jar. Which of these are supposed to be used as dependencies in other projects? Each project can supply exactly 1 artifact for dependent Maven builds. Other software may make use of more artifacts, that's why foo-sources.jar is so commonplace - IDEs typically can use multiple artifacts, one for binaries, one for sources, one for javadoc. But only 1 binaries artifact for inclusion in other projects via the dependencies, that's it. This looks as if you need two projects, one that generates api.jar and api-sources.jar, and one that generates full.jar and full-sources.jar. Hope this points you in the right direction. Regards, Jo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Antwort: Re: Maven Shade Plugin
Hi, thanks for your help, At first: in fact this is only one artifact. The full jar contains all classes of the dependecies, the api a reduced set (using filtern in the shade plugin). Even if I split that up into 2 projects, I cannot define modules then in the pom, right? I need to do s/t like that: - Build up all modules (to be sure that everything is up to date) - Build the shaded artifacts - cross-compile them (using ikvm) - put the artifact with some other stuff (doc, examples, dlls, etc).into one zip (in fact three: windows, linux, mac) - deploy all artifacts into nexus (or maybe somewhere else using wagon) Thanks again! Jan Mit freundlichen Grüßen / Best regards Jan Engler Central Research Development SICK AG Erwin-Sick-Str. 1 79183 Waldkirch, Germany Phone +49 7681 202-3214 mailto:jan.eng...@sick.de http://www.sick.com Von:Joachim Durchholz j...@durchholz.org An: users@maven.apache.org Datum: 28.02.2013 15:38 Betreff:Re: Maven Shade Plugin Am 28.02.2013 14:50, schrieb Jan Engler: As you might have seen, I want to have 4 artifacts: api.jar, api-sources.jar, full.jar, full-sources.jar. Which of these are supposed to be used as dependencies in other projects? Each project can supply exactly 1 artifact for dependent Maven builds. Other software may make use of more artifacts, that's why foo-sources.jar is so commonplace - IDEs typically can use multiple artifacts, one for binaries, one for sources, one for javadoc. But only 1 binaries artifact for inclusion in other projects via the dependencies, that's it. This looks as if you need two projects, one that generates api.jar and api-sources.jar, and one that generates full.jar and full-sources.jar. Hope this points you in the right direction. Regards, Jo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Dr. Martin Krämer - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender)
