+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