Re: main-class + module-version

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

olamy
+1 for shade plugin looks to be the most appropriate location to do this.

On 23 August 2017 at 06:03, Robert Scholte <[hidden email]> wrote:

> On Tue, 22 Aug 2017 21:23:10 +0200, Plamen Totev <
> [hidden email]> 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 <[hidden email]>
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy
Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Chas Honton
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 <[hidden email]> wrote:
>
> +1 for shade plugin looks to be the most appropriate location to do this.
>
>> On 23 August 2017 at 06:03, Robert Scholte <[hidden email]> wrote:
>>
>> On Tue, 22 Aug 2017 21:23:10 +0200, Plamen Totev <
>> [hidden email]> 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 <[hidden email]>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Robert Scholte-6
In reply to this post by olamy
On Wed, 23 Aug 2017 08:11:35 +0200, Plamen Totev  
<[hidden email]> wrote:

> On Tue, Aug 22, 2017 at 11:03 PM, Robert Scholte <[hidden email]>  
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Robert Scholte-6
In reply to this post by olamy
Hi all,

I'm having a look at the JarArchiver of the plexus-archiver project as  
used by maven-jar-plugin.
This archiver does some MANIFEST and index stuff already, so it kind of  
makes sense to add the module-descriptor logic here as well.
That will make it reusable as mentioned by Olivier and it'll be easy to  
use by the maven-jar-plugin.

thanks,
Robert

On Tue, 22 Aug 2017 19:17:04 +0200, Robert Scholte <[hidden email]>  
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: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Robert Scholte-6
On Mon, 28 Aug 2017 07:32:36 +0200, Plamen Totev  
<[hidden email]> wrote:

> Hi,
>
> On Fri, Aug 25, 2017 at 6:57 PM, Robert Scholte <[hidden email]>  
> wrote:
>> I'm having a look at the JarArchiver of the plexus-archiver project as  
>> used
>> by maven-jar-plugin.
>> This archiver does some MANIFEST and index stuff already, so it kind of
>> makes sense to add the module-descriptor logic here as well.
>
> I think it is a good idea to make Plexus Archiver module aware. I can
> help you with it if you want.

All help is appreciated, Java 9 came with quite some extra work for us.

>
> Also I took a look at the changes in the JDK jar tool and I notice a
> couple of things that it does:
>
> 1. The structure of the jar produced is such that the module info
> entries are placed after the manifest and before the rest of the
> files. Plexus Archiver does not handle  the module info entries
> differently and they are placed in random order among the rest of the
> files.

IIRC Plexus Archiver is already capable to put the manifest file up front.  
The same should be possible with the module descriptor.

> 2. It adds/replaces some additional information to the module
> description such as the list of packages it contains, the hashes of
> the modules, module version, main class.

seems like an Archive needs to get a module(descriptor?) next to the  
manifest when there are so much extra options

> 3. There is verification that the module descriptor is consistent -
> exported/opened/provided  packages/classes are actually presented in
> the jar file.
>
  See #2

> I have to double check which of those are part of the specification
> and which are OpenJdk specific. In any case it sounds like a good idea
> to have some verification (3.) and to update the packages field with
> the packages that are actually packaged. The module hashes seem to be
> OpenJdk specific but they do sound like a nice feature. Maybe we
> should do some(or all) of the above thing as well, what do you think?
>

I think we need to focus on version and mainClass first, that's probably  
the first things users will ask and which is really visible to them. If  
the extra checks are not required I consider them as nice to have checks  
and pick them up later.

> The points above convince we even more that the Plexus Archiver should
> be module aware and the component to verify/modify the module
> descriptors.
>
> BTW what do you think - should we have a new class ModuleJarArchiver
> that extends JarArchiver or just to modify JarArchiver. There is no
> new packaging type and from this POV it does sounds logical to just
> modify the JarArchiver. But on other hand it is extended by
> WarArchiver & co so they'll become module aware as well. Not
> completely sure if that is ok. I guess they should be ok as they do
> not contain any code(modules or not) in their root folder, right? Or I
> am wrong?

I think so. Otherwise we'll have to add an abstraction layer.

>
> Regards,
> Plamen Totev
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Robert Scholte-6
Hi Plamen,

On Tue, 29 Aug 2017 07:46:59 +0200, Plamen Totev  
<[hidden email]> wrote:

> Hi Robert,
>
> Thank you for you comments.
>
>>> Also I took a look at the changes in the JDK jar tool and I notice a
>>> couple of things that it does:
>>>
>>> 1. The structure of the jar produced is such that the module info
>>> entries are placed after the manifest and before the rest of the
>>> files. Plexus Archiver does not handle  the module info entries
>>> differently and they are placed in random order among the rest of the
>>> files.
>>
>>
>> IIRC Plexus Archiver is already capable to put the manifest file up  
>> front.
>> The same should be possible with the module descriptor.
>
> I double checked the changes in the Jar File Specifications [1] and
> there are no requirements specifying where the module-info.class entry
> should be located in regard to the rest of the entries(I mean
> physically in the file). So I consider this behavior implementation
> specific.
>
>> I think we need to focus on version and mainClass first, that's  
>> probably the
>> first things users will ask and which is really visible to them. If the
>> extra checks are not required I consider them as nice to have checks and
>> pick them up later.
>
> Makes sense. I created issues for them as well so we don't forget  
> them.[2][3][4]
>
> Regarding the implementation. Unfortunately as you mention it will
> require adjusting the byte code of the module-info.class. And I don't
> have knowledge in the matter so I'll need help with that. Also I was
> thinking that maybe such functionality(adding/replacing  information
> to the ModuleDescriptor) is good fit for the newly introduced
> plexus-languages project?


I've started a bit with it, but no success yet:
https://mail.ow2.org/wws/arc/asm/2017-08/msg00004.html

Even after the suggestions from Remi no success yet.
I was hoping for a fast fix, but it'll take more time and other things are  
waiting as well.
Would be great if you can pick it up from here.

I hope it won't become part of plexus-java, that would be a bad sign :)
Plexus-java contains code which are used by at least 3 or 4 other  
projects/plugins. Don't think that transforming a module descriptor would  
be such often used feature.

Robert


>
> Regards,
> Plamen Totev
>
> [1] http://cr.openjdk.java.net/~mr/jigsaw/spec/jar.html
> [2] https://github.com/codehaus-plexus/plexus-archiver/issues/67
> [3] https://github.com/codehaus-plexus/plexus-archiver/issues/68
> [4] https://github.com/codehaus-plexus/plexus-archiver/issues/69
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]