Jar plugin is used more often than shade plugin. (I dis-recommend shade since provenance of classes is difficult or impossible to trace.). If module version is required to make jar useful, then jar plugin appears more appropriate. Chas
> On Aug 22, 2017, at 6:10 PM, Olivier Lamy <ol...@apache.org> wrote: > > +1 for shade plugin looks to be the most appropriate location to do this. > >> On 23 August 2017 at 06:03, Robert Scholte <rfscho...@apache.org> wrote: >> >> On Tue, 22 Aug 2017 21:23:10 +0200, Plamen Totev < >> plamen.iv.to...@gmail.com> wrote: >> >> Hi, >>> >>> I've experimented with Maven and Java 9 the last weekend and actually one >>> of the things I noticed is that currently I could not set the module >>> version. >>> >>> I do agree that the packaging should be stupid action and the module-info >>> transformation should happen before that. But I'm not sure why the Maven >>> Shade plug-in is the place to do that. Probably I'm missing something, >>> would you explain a bit? >> >> 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. >> >> >> >>> Or should these extra (basic?) features require an extra setup of a >>> maven-plugin so all transformations are done by one plugin only. >>> >>> My thoughts exactly. While it makes sense to have separate plugin for that >>> (maybe in the future the module-info.class will contain more >>> information?), >>> I'm not sure it's worth to have separate plugin just for that. And if we >>> don't have separate plugin then I think the Jar plugin is the better place >>> because: >>> 1. this way it's consistent with the JDK tools >>> 2. up until Java 9 the usual place to put meta-information about the >>> package was to place in in the META-INF directory and package it. Of >>> course >>> the processing >>> >>> An interesting question (no matter which plugin does the transformation) >>> is >>> that if the module-version should be added by default? I feel a bit >>> uncomfortable about the idea to enable it by default but on other hand >>> the module-info is a new class so it's unlikely to break anything and it >>> may prove tiresome to have to set the version explicitly. I mean why would >>> you want not to have the version set? I personally think that the majority >>> of the projects would like to have the version set. >>> >>> Regards, >>> Plamen Totev >>> >>> On Tue, Aug 22, 2017 at 8:17 PM, Robert Scholte <rfscho...@apache.org> >>> wrote: >>> >>> Hi, >>>> >>>> The JDK 9 jar packager comes with 2 extra options: main-class and >>>> module-version. >>>> The first one is used in case of an executable modular jar, the latter is >>>> just for display/analysis to show which version of a specific module is >>>> used. >>>> To support these 2 values, the module-info.class must be adjusted (yes, >>>> the bytecode!). >>>> >>>> It is not that hard to support this as well with a little help from ASM, >>>> but the question is: which plugin should do this: maven-jar-plugin or >>>> maven-shade-plugin? >>>> If you consider this kind of information to be part of the packaging >>>> process, maven-jar-plugin seems to be the best fit. >>>> However, if you consider this as a resource transformation, then >>>> maven-shade-plugin seems better. >>>> >>>> Personally I think packaging should be quite a stupid action: making a >>>> jar >>>> from a set of files. And it should be very reliable, since it is part of >>>> the lifecycle of the most used packaging type. Of course you can control >>>> this when exposed as parameters... >>>> >>>> Or should these extra (basic?) features require an extra setup of a >>>> maven-plugin so all transformations are done by one plugin only. >>>> >>>> WDYT? >>>> Robert >>>> >>>> --------------------------------------------------------------------- >>>> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
