+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

Reply via email to