Hi Well makes sense!. I was only thinking about the shaded uber jar use case (we have to keep this one in mind as well) We probably need to make an extra component if we want to reuse this in both plugins.
On 24 August 2017 at 08:07, Andreas Gudian <andreas.gud...@gmail.com> wrote: > I find the arguments by Plamen very convincing. As a user I would look for > that configuration where I previously did the same thing when it ended up > in the Manifest: in the config of the jar plugin. > I wouldn't expect to suddenly switch to the shade plugin to be able to > define the main class or the module version. > > But in the end both m-shade-p and m-jar-p might need those capabilities. > > And just to check: the compiler-plugin is not the right spot for that? Or > the resources plugin to extend the module-info.java before compiling? Nah, > that sounds too far off. > > > Robert Scholte <rfscho...@apache.org> schrieb am Mi. 23. Aug. 2017 um > 11:16: > > > On Wed, 23 Aug 2017 08:11:35 +0200, Plamen Totev > > <plamen.iv.to...@gmail.com> wrote: > > > > > On Tue, Aug 22, 2017 at 11:03 PM, Robert Scholte <rfscho...@apache.org > > > > > wrote: > > >> > > >> > > >> The maven-shade-plugin has the ability to re-package a jar and > > >> manipulate any type of file, including class files. The best example > is > > >> relocation, where you give a set of classes a different package to > > >> prevent potential class collisions when the original dependency > > >> (probably with other version) is added again. > > >> So this is a good match for the module-info.class adjustments. > > >> > > > > > > Thank you for the detailed explanation. Initially I thought that if > > > this is not part of the jar plugin then the transformation should > > > happen before its execution(similar to the MANFEST.MF). Now on second > > > thought it also sounds logical to be done after. But still - isn't the > > > shade plugin supposed to be used for "uber jars" (at least its primary > > > purpose)? Correct me if I'm wrong, but its only target will create a > > > "uber jar". What if I want to set the module version but without > > > changing the rest of the jar? A configuration or new target will solve > > > this issue, but as a user of the plugin I think it would change its > > > purpose. And there is nothing wrong with that of course . > > > > You can choose which artifacts should be included/excluded from the > > uber-jar. By default it'll select all, which means you must do quite some > > extra configuration just to set the main-class and module-version. > > Another downside is that the maven-shade-plugin is probably not the > plugin > > one would expect to use to achieve this. > > > > > > > > Also another important question for me. Do you think that other types > > > of packaging will benefit from setting the module version as well? I > > > mean not only now but in future as well. Some of the EE packaging > > > types for example. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
