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 client-api-all .. 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. > > > org.apache.maven.plugins > maven-shade-plugin > 2.4 > > > package > >shade > > >client-api-all.jar > > > > > > 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
Re: Maven shade plugin generates uber-jar but in a file name like *.pom
Hi, just simply use client-api-all .. 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. org.apache.maven.plugins maven-shade-plugin 2.4 package shade client-api-all.jar Regards, Kai - 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. org.apache.maven.plugins maven-shade-plugin 2.4 package shade client-api-all.jar Regards, Kai
Re: A checkstyle plugin mystery
Yes, it's to do with the forked execution. I've made a test case and created https://issues.apache.org/jira/browse/MRELEASE-915. I haven't tried the yet, I will in a moment and annotate the JIRA. On Sun, Jul 12, 2015 at 1:08 PM, Benson Margulies wrote: > On Sat, Jul 11, 2015 at 5:04 AM, Robert Scholte wrote: >> You know that release:perform doesn't do any magic. It would be the same as: >> cd target/checkout >> mvn deploy (or mvn deploy site-deploy) >> >> If this works as expected (without failures), then it looks like something >> is leaking. >> Could you try to switch to the ForkedMavenExecutor? >> forked-path > > Where do I put that? release plugin config? > >> >> thanks, >> Robert >> >> Op Fri, 10 Jul 2015 03:04:55 +0200 schreef Benson Margulies >> : >> >>> Ever since we bumped to 2.15 of the plugin, we've been hitting a >>> problem. I don't have a concise repro, so I'm not opening a JIRA yet, >>> but I thought I'd inquire for other people's experience. >>> >>> We use some source generators, and none of them generate source that >>> is acceptable to our checkstyle rules. To prevent checkstyle from >>> processing that stuff, we bind the 'check' goal to the validate phase. >>> Since this is before generate-sources, it comes and goes before the >>> generator plugin(s) have a chance to register any additional source >>> roots. >>> >>> The recent change afflicts only release builds. All is well until we >>> run release:perform, and then the build fails because of checkstyle >>> complaints on generated source. >>> >>> How is it that the release plugin causes the generated source roots to >>> be visible to the plugin? >>> >>> - >>> 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: A checkstyle plugin mystery
On Sat, Jul 11, 2015 at 5:04 AM, Robert Scholte wrote: > You know that release:perform doesn't do any magic. It would be the same as: > cd target/checkout > mvn deploy (or mvn deploy site-deploy) > > If this works as expected (without failures), then it looks like something > is leaking. > Could you try to switch to the ForkedMavenExecutor? > forked-path Where do I put that? release plugin config? > > thanks, > Robert > > Op Fri, 10 Jul 2015 03:04:55 +0200 schreef Benson Margulies > : > >> Ever since we bumped to 2.15 of the plugin, we've been hitting a >> problem. I don't have a concise repro, so I'm not opening a JIRA yet, >> but I thought I'd inquire for other people's experience. >> >> We use some source generators, and none of them generate source that >> is acceptable to our checkstyle rules. To prevent checkstyle from >> processing that stuff, we bind the 'check' goal to the validate phase. >> Since this is before generate-sources, it comes and goes before the >> generator plugin(s) have a chance to register any additional source >> roots. >> >> The recent change afflicts only release builds. All is well until we >> run release:perform, and then the build fails because of checkstyle >> complaints on generated source. >> >> How is it that the release plugin causes the generated source roots to >> be visible to the plugin? >> >> - >> 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
