Re: main-class + module-version

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

Re: main-class + module-version

Andreas Gudian
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 <[hidden email]> schrieb am Mi. 23. Aug. 2017 um 11:16:

> 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

olamy
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 <[hidden email]> 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 <[hidden email]> schrieb am Mi. 23. Aug. 2017 um
> 11:16:
>
> > 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]
> >
> >
>



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

Re: main-class + module-version

Plamen Totev-2
In reply to this post by Andreas Gudian
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?

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]

Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Plamen Totev-2
Hi,

I've started working on this one. Unfortunately I don't have as much
free time as I expected so the progress is a bit slow. With the
release date of Java 9 approaching I hope this does not block any
other release.

I've just pushed my implementation [1]. It's not fully ready yet as
there are no tests and Java Docs. The commit messages should be more
detailed as well. But all changes to the API and the work on
implementing the functionality are done so if you want you can take a
look. Any comments and suggestions are welcome. I'll continue with the
tests next week.

Regards,
Plamen Totev


[1] https://github.com/codehaus-plexus/plexus-archiver/compare/master...plamentotev:module-version-and-main-class

On Wed, Aug 30, 2017 at 8:32 AM, Plamen Totev <[hidden email]> wrote:

> Hi Robert,
>
>>
>> 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.
>
> Yes, I will. Thanks for the starting point. I took a look at the asm
> API, the class file format and the jar tool implementation so I should
> be able to continue from here.
>
> Regards,
> Plamen Totev

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