Re: main-class + module-version

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

Re: main-class + module-version

Plamen Totev-2
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?

> 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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

Plamen Totev-2
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.

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.
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.
3. There is verification that the module descriptor is consistent -
exported/opened/provided  packages/classes are actually presented in
the jar file.

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?

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?

Regards,
Plamen Totev

---------------------------------------------------------------------
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 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]