Re: main-class + module-version

[Plamen Totev]

Hi,

I've done some work on implementing `PlexusArchiver` that creates
modular JAR files using the JDK `jar` tool (`ToolProvider`)[1]. It is
still work in progress but I wanted to ask for you opinion - if there
are no objections I'll polish it(fix the code formatting, implement the
TODO items, etc) and would like eventually to merge it in master. Here
are some key points:

* It requires Java 9. This of course is not the minimum required version
for the rest of the archivers, but `java.util.spi.ToolProvider` is
introduced in Java 9. I'll fix the source and target to be 7, but it
will still require Java 9 to compile and currently Plexus Archiver does
not compile on Java 9. This is easy to fix - requires only update of
some of the plugins to yet to be released versions.

* A new class is added `ModularJarArchiver`. This would allow a "normal"
JARs to be created on Java 7 using `JarArchiver` while modular JARs will
require Java 9 (I don't think this is an issue as you need Java 9 to
compile modules anyway).

* `ModularJarArchiver` uses `JarArchiver` to create a "normal" JAR file
and then uses the JDK `jar` tool to update it to modular one. This may
require some additional work during the build compared to creating the
archive using only the `jar` tool, but `JarArchiver` provides some nice
additional features not available in the `jar` tool(such as not
re-compressing the zip files, generating manifest entries, etc).

What do you think? Any objections to implement it this way? I think this
is better approach than my previous attempt[2].

Regards,
Plamen Totev

[1] 
https://github.com/plamentotev/plexus-archiver/commit/b124aceb3f6a912a9dca44f5d14b9f3f2919bc6d
[2] https://github.com/codehaus-plexus/plexus-archiver/pull/75

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Plamen Totev]

Hi Robert,

On 1/15/2018 10:10 PM, Robert Scholte wrote:
> Hi Plamen,
>
> Alan Bateman has provided some valuable information:

Thank you for sharing this. It's really helpful.

On 1/15/2018 10:10 PM, Robert Scholte wrote:
1. MR JARs weren't mentioned. The jar tool does validation to ensure 
that the API provided by the classes in the JAR file is the same for all 
versions.


Validation is indeed something I haven't dig in yet. It is interesting 
to know what is the impact of Maven not doing validation of modular JAR 
files.


On 1/15/2018 10:10 PM, Robert Scholte wrote:
2. The Module, ModulePackages, and ModuleMainClass class file attributes 
are specified in the JVMS. ASM supports them so the Archiver could use 
that. The ModulePackages attribute is optional. If this attribute is not 
present then the JAR file will be scanned to get the set of packages in 
the module.


If the JAR is scanned when ModulePackages is not present then for the 
time being is ok to not implement it.


On 1/15/2018 10:10 PM, Robert Scholte wrote:
The ModuleTarget, ModuleResolution, and ModuleHashes class file 
attributes are JDK-specific so you won't find these in the JVMS. The 
ModuleTarget attribute is documented in JEP 261, the others aren't there 
yet but ASM has support in org.objectweb.asm.commons for these 
attributes so you should be okay.


All of those could be set with ASM (I think) but setting them is the 
easy part. Calculating the hashes for ModuleHashes will require some 
work though.


On 1/15/2018 10:09 PM, Andreas Sewe wrote:
> Also, if two separate tools modify the JAR, the goal of reproducible
> builds is again a bit harder to accomplish. So, please try to use an
> internal, written-in-Java solution if possible.

This is a valid point. I don't think it would be possible to set the 
entries timestamps using the JDK jar tool. But a bit harder does not 
mean impossible. It could be achieved by "post-processing" the resulting 
jar file.


Another point I think we should have in mind is the fact that every time 
the class format version is increased we should update the ASM library 
and release a new version of the JAR plugin otherwise the build will 
fail. Also the users should update the JAR plugin version. That may 
prove to be a bit inconvenient.


From my point of view the trade-off is ease of maintainability vs 
flexibility and control.


Regards,
Plamen Totev

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Robert Scholte]

Hi Plamen,

Alan Bateman has provided some valuable information:
---
A first step to use the ToolProvider to run the jar tool make sense,  
should be easy to do. We've done quite a bit of work on the jar tool  
performance in the last few years so the performance might not be too bad.


Updating org.codehaus.plexus.archiver.Archiver to do the same as the jar  
tool is probably a lot of work. A few points on this:


1. MR JARs weren't mentioned. The jar tool does validation to ensure that  
the API provided by the classes in the JAR file is the same for all  
versions.


2. The Module, ModulePackages, and ModuleMainClass class file attributes  
are specified in the JVMS. ASM supports them so the Archiver could use  
that. The ModulePackages attribute is optional. If this attribute is not  
present then the JAR file will be scanned to get the set of packages in  
the module.


The ModuleTarget, ModuleResolution, and ModuleHashes class file attributes  
are JDK-specific so you won't find these in the JVMS. The ModuleTarget  
attribute is documented in JEP 261, the others aren't there yet but ASM  
has support in org.objectweb.asm.commons for these attributes so you  
should be okay.


3. The Maven Shade Plugin is a good discussion point. There are several  
issues to sort if this is extended to work with modules.

---

thanks,
Robert


On Mon, 15 Jan 2018 20:31:54 +0100, Plamen Totev  
 wrote:



Hi,

On Mon, Jan 15, 2018 at 8:23 PM, Robert Scholte   
wrote:

So maybe we simply have to split it up into smaller pieces.
I think we can already make people happy by adding the version to the
module-info file, assuming all other added features are actually nice to
haves.


I guess you're right. We already have the version and main class[1] -
I'll update the PR so it compiles and passes the tests.

As for the version - the module version could be set by the compiler
as well. I was thinking that maybe it would be nice if the compiler
plugin passes the project version to the Java compiler.

Regards,
Plamen Totev

[1] https://github.com/codehaus-plexus/plexus-archiver/pull/75

-
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

Re: main-class + module-version

[Andreas Sewe]

Robert Scholte wrote:
> Plexus Archiver is an archiver fully written in Java, so there has never
> been the need to add toolchain support.
> 
> It would be very nice if this could be solved without the need of the
> external jartool or using it via a ToolProvider[1].

Also, if two separate tools modify the JAR, the goal of reproducible
builds is again a bit harder to accomplish. So, please try to use an
internal, written-in-Java solution if possible.

Just my 2 cents.

Best wishes,

Andreas



signature.asc
Description: OpenPGP digital signature

Re: main-class + module-version

[Plamen Totev]

Hi,

On Mon, Jan 15, 2018 at 8:23 PM, Robert Scholte  wrote:
> So maybe we simply have to split it up into smaller pieces.
> I think we can already make people happy by adding the version to the
> module-info file, assuming all other added features are actually nice to
> haves.

I guess you're right. We already have the version and main class[1] -
I'll update the PR so it compiles and passes the tests.

As for the version - the module version could be set by the compiler
as well. I was thinking that maybe it would be nice if the compiler
plugin passes the project version to the Java compiler.

Regards,
Plamen Totev

[1] https://github.com/codehaus-plexus/plexus-archiver/pull/75

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Robert Scholte]

Plexus Archiver is an archiver fully written in Java, so there has never  
been the need to add toolchain support.


It would be very nice if this could be solved without the need of the  
external jartool or using it via a ToolProvider[1].


So maybe we simply have to split it up into smaller pieces.
I think we can already make people happy by adding the version to the  
module-info file, assuming all other added features are actually nice to  
haves.


thanks,
Robert

[1]https://docs.oracle.com/javase/9/docs/api/java/util/spi/ToolProvider.html

On Mon, 15 Jan 2018 18:12:40 +0100, Plamen Totev  
 wrote:



Hi,

On 12/20/2017 9:53 PM, Robert Scholte wrote:
 Based on this message it seems worth implementing a JarToolArchiver,  
using the jar tool via the ToolProvider[1]
I hope it can still be a org.codehaus.plexus.archiver.Archiver,  
otherwise I'll contact the openjdk team about the details of the  
specifications. I don't think we need them all, good to know the reason  
for the extra files.


So I did some experiments and definitely it is possible to implement it  
as org.codehaus.plexus.archiver.Archiver. I think it would be best to  
reuse JarArchiver to create the  non-modular JAR file and then use the  
JDK jar tool to update it to modular JAR file. The downside of this  
approach is that it involves additional work(there is some performance  
penalty). The JDK jar tool updates files the same as way Plexus Archiver  
- creates new file, copies the old entries and adds the new ones. Do you  
think this is really an issue? I think for small JAR files the  
difference would not be noticeable.


Of course we could create the jar file directly using only the JDK jar  
tool. But the Plexus Archiver is quite advanced tool compared to it. If  
we have to implement all of its functionality using only the JDK jar  
tool, it would be easier to update the module descriptors using asm  
(IMHO).


About the ToolProvider - maybe I'm missing something but it is available  
only for Java 9 and does not allow the use of tool chains, does it?


Regards,
Plamen Totev

-
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

Re: main-class + module-version

[Plamen Totev]

Hi,

On 12/20/2017 9:53 PM, Robert Scholte wrote:


Based on this message it seems worth implementing a JarToolArchiver, 
using the jar tool via the ToolProvider[1]
I hope it can still be a org.codehaus.plexus.archiver.Archiver, 
otherwise I'll contact the openjdk team about the details of the 
specifications. I don't think we need them all, good to know the reason 
for the extra files.


So I did some experiments and definitely it is possible to implement it 
as org.codehaus.plexus.archiver.Archiver. I think it would be best to 
reuse JarArchiver to create the  non-modular JAR file and then use the 
JDK jar tool to update it to modular JAR file. The downside of this 
approach is that it involves additional work(there is some performance 
penalty). The JDK jar tool updates files the same as way Plexus Archiver 
- creates new file, copies the old entries and adds the new ones. Do you 
think this is really an issue? I think for small JAR files the 
difference would not be noticeable.


Of course we could create the jar file directly using only the JDK jar 
tool. But the Plexus Archiver is quite advanced tool compared to it. If 
we have to implement all of its functionality using only the JDK jar 
tool, it would be easier to update the module descriptors using asm (IMHO).


About the ToolProvider - maybe I'm missing something but it is available 
only for Java 9 and does not allow the use of tool chains, does it?


Regards,
Plamen Totev

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Plamen Totev]

Hi,

Actually that might just work. Good idea. I'll take a look at it.

Thanks,
Plamen Totev

On Wed, Dec 20, 2017 at 9:53 PM, Robert Scholte  wrote:
> On Wed, 20 Dec 2017 07:40:24 +0100, Plamen Totev 
> wrote:
>
>> Hi,
>>
>> I've started working on implementing support for modular JARs in
>> Plexus Archiver but as I research the matter I found that they are
>> more complex than I expected. I've updated the GitHub issue[1] with
>> the details but I'll post the findings here as well. The modular JAR
>> files contain not only version and main class but also:
>>
>> * List of the packages contained - usually populated by the compiler,
>> but there are some caveats here. The most obvious one is that for jars
>> created by the Shade Plugin this attribute will almost certainly be
>> incorrect - the plugin will most likely introduce additional packages
>> and the list produced by the compiler will be out of date. The other
>> caveat are the resources - they could be located in packages and
>> encapsulated the same way as the classes. The jar tools records not
>> only the class packages but the resource ones too. Packaging resources
>> together with the classes may result in incorrect module descriptor if
>> this attribute is not updated.
>>
>> * The module main class - passed as argument to the jar tool and it
>> seems that it cannot be set using the compiler.
>>
>> * The module version - passed as argument to the jar tool. Could be
>> set using the compiler(again passed as argument) as well.
>>
>> * Hashes - calculates the hashes of given external modules that depend
>> on this one. During runtime java checks the recorded hashes against
>> the resolved module and and if don't match it will fail. The primary
>> use case is a module A that exports packages to B and C. An easy way
>> to break the encapsulation of A is to create module named B. To
>> prevent that you can record the hash of B and C inside A. Then A will
>> export the packages only to the intended modules. It is used by the
>> OpenJDK but could be useful for platforms and frameworks as well.
>>
>> * Module resolution - marks the module to not be resolved by default or
>> marks it as deprecated or incubating so at run time a warning is
>> displayed if it is resolved. I don't think you can set it using the
>> JDK 9 jar tool but it's present in the code. Maybe it will be
>> implemented in future version of the jar tool.
>>
>> To me it looks like the packaging of modular JAR file is more complex
>> than just packing module-info.class file and the jar tool is no longer
>> just a ZIP program. Something similar is stated in the tool
>> documentation[2]:
>>
>>> The jar command is a general-purpose archiving and compression tool,
>>> based on the ZIP and ZLIB compression formats.
>>> Initially, the jar command was designed to package Java applets
>>> or applications; however, beginning with JDK 9, users can use the
>>> jar command to create modular JARs.
>>> For transportation and deployment, it’s usually more convenient to
>>> package modules as modular JARs.
>>
>>
>> While not at all that complex from technical point of view, I don't
>> think it is worth implementing, and whats more maintaining, all this
>> functionality. Probably it would be better if the plugins that produce
>> JAR files use the jar tool, the same way the compiler plugin does not
>> compile by itself but uses the Java compiler.
>>
>> What do you think?
>
>
> Based on this message it seems worth implementing a JarToolArchiver, using
> the jar tool via the ToolProvider[1]
> I hope it can still be a org.codehaus.plexus.archiver.Archiver, otherwise
> I'll contact the openjdk team about the details of the specifications. I
> don't think we need them all, good to know the reason for the extra files.
>
> thanks so far,
> Robert
>
>
> [1]
> https://docs.oracle.com/javase/9/docs/api/jdk.jartool-summary.html#module.description
>
>>
>>
>> [1]
>> https://github.com/codehaus-plexus/plexus-archiver/issues/69#issuecomment-349095101
>> [2] https://docs.oracle.com/javase/9/tools/jar.htm
>>
>> -
>> 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
>

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Robert Scholte]

On Wed, 20 Dec 2017 07:40:24 +0100, Plamen Totev  
 wrote:



Hi,

I've started working on implementing support for modular JARs in
Plexus Archiver but as I research the matter I found that they are
more complex than I expected. I've updated the GitHub issue[1] with
the details but I'll post the findings here as well. The modular JAR
files contain not only version and main class but also:

* List of the packages contained - usually populated by the compiler,
but there are some caveats here. The most obvious one is that for jars
created by the Shade Plugin this attribute will almost certainly be
incorrect - the plugin will most likely introduce additional packages
and the list produced by the compiler will be out of date. The other
caveat are the resources - they could be located in packages and
encapsulated the same way as the classes. The jar tools records not
only the class packages but the resource ones too. Packaging resources
together with the classes may result in incorrect module descriptor if
this attribute is not updated.

* The module main class - passed as argument to the jar tool and it
seems that it cannot be set using the compiler.

* The module version - passed as argument to the jar tool. Could be
set using the compiler(again passed as argument) as well.

* Hashes - calculates the hashes of given external modules that depend
on this one. During runtime java checks the recorded hashes against
the resolved module and and if don't match it will fail. The primary
use case is a module A that exports packages to B and C. An easy way
to break the encapsulation of A is to create module named B. To
prevent that you can record the hash of B and C inside A. Then A will
export the packages only to the intended modules. It is used by the
OpenJDK but could be useful for platforms and frameworks as well.

* Module resolution - marks the module to not be resolved by default or
marks it as deprecated or incubating so at run time a warning is
displayed if it is resolved. I don't think you can set it using the
JDK 9 jar tool but it's present in the code. Maybe it will be
implemented in future version of the jar tool.

To me it looks like the packaging of modular JAR file is more complex
than just packing module-info.class file and the jar tool is no longer
just a ZIP program. Something similar is stated in the tool
documentation[2]:


The jar command is a general-purpose archiving and compression tool,
based on the ZIP and ZLIB compression formats.
Initially, the jar command was designed to package Java applets
or applications; however, beginning with JDK 9, users can use the
jar command to create modular JARs.
For transportation and deployment, it’s usually more convenient to
package modules as modular JARs.


While not at all that complex from technical point of view, I don't
think it is worth implementing, and whats more maintaining, all this
functionality. Probably it would be better if the plugins that produce
JAR files use the jar tool, the same way the compiler plugin does not
compile by itself but uses the Java compiler.

What do you think?


Based on this message it seems worth implementing a JarToolArchiver, using  
the jar tool via the ToolProvider[1]
I hope it can still be a org.codehaus.plexus.archiver.Archiver, otherwise  
I'll contact the openjdk team about the details of the specifications. I  
don't think we need them all, good to know the reason for the extra files.


thanks so far,
Robert


[1]  
https://docs.oracle.com/javase/9/docs/api/jdk.jartool-summary.html#module.description





[1]  
https://github.com/codehaus-plexus/plexus-archiver/issues/69#issuecomment-349095101

[2] https://docs.oracle.com/javase/9/tools/jar.htm

-
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

Re: main-class + module-version

[Plamen Totev]

Hi,

I've started working on implementing support for modular JARs in
Plexus Archiver but as I research the matter I found that they are
more complex than I expected. I've updated the GitHub issue[1] with
the details but I'll post the findings here as well. The modular JAR
files contain not only version and main class but also:

* List of the packages contained - usually populated by the compiler,
but there are some caveats here. The most obvious one is that for jars
created by the Shade Plugin this attribute will almost certainly be
incorrect - the plugin will most likely introduce additional packages
and the list produced by the compiler will be out of date. The other
caveat are the resources - they could be located in packages and
encapsulated the same way as the classes. The jar tools records not
only the class packages but the resource ones too. Packaging resources
together with the classes may result in incorrect module descriptor if
this attribute is not updated.

* The module main class - passed as argument to the jar tool and it
seems that it cannot be set using the compiler.

* The module version - passed as argument to the jar tool. Could be
set using the compiler(again passed as argument) as well.

* Hashes - calculates the hashes of given external modules that depend
on this one. During runtime java checks the recorded hashes against
the resolved module and and if don't match it will fail. The primary
use case is a module A that exports packages to B and C. An easy way
to break the encapsulation of A is to create module named B. To
prevent that you can record the hash of B and C inside A. Then A will
export the packages only to the intended modules. It is used by the
OpenJDK but could be useful for platforms and frameworks as well.

* Module resolution - marks the module to not be resolved by default or
marks it as deprecated or incubating so at run time a warning is
displayed if it is resolved. I don't think you can set it using the
JDK 9 jar tool but it's present in the code. Maybe it will be
implemented in future version of the jar tool.

To me it looks like the packaging of modular JAR file is more complex
than just packing module-info.class file and the jar tool is no longer
just a ZIP program. Something similar is stated in the tool
documentation[2]:

> The jar command is a general-purpose archiving and compression tool,
> based on the ZIP and ZLIB compression formats.
> Initially, the jar command was designed to package Java applets
> or applications; however, beginning with JDK 9, users can use the
> jar command to create modular JARs.
> For transportation and deployment, it’s usually more convenient to
> package modules as modular JARs.

While not at all that complex from technical point of view, I don't
think it is worth implementing, and whats more maintaining, all this
functionality. Probably it would be better if the plugins that produce
JAR files use the jar tool, the same way the compiler plugin does not
compile by itself but uses the Java compiler.

What do you think?


[1] 
https://github.com/codehaus-plexus/plexus-archiver/issues/69#issuecomment-349095101
[2] https://docs.oracle.com/javase/9/tools/jar.htm

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Plamen Totev]

Hi,

I've just implemented support for adding module version and main
class. There is pull request[1] and comments and suggestions are more
than welcome. The following excerpt from the test showcase how you can
add module version and main class to a modular JAR fie:

JarArchiver archiver = new JarArchiver();
archiver.setDestFile( jarFile );
archiver.addDirectory( new File( "src/test/resources/java-module" ) );

ModuleConfiguration moduleConfiguration = new ModuleConfiguration();
moduleConfiguration.setVersion( "1.0.0" );
moduleConfiguration.setMainClass( "com.example.app.Main" );
archiver.setModuleConfiguration( moduleConfiguration );

archiver.createArchive();

Regards,
Plamen Totev

[1] https://github.com/codehaus-plexus/plexus-archiver/pull/75

On Wed, Sep 6, 2017 at 10:03 PM, Plamen Totev  wrote:
> 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  
> wrote:
>> Hi Robert,
>>
>>>
>>> I've started a bit with it, but no success yet:
>>> https://mail.ow2.org/wws/arc/asm/2017-08/msg4.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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Plamen Totev]

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  wrote:
> Hi Robert,
>
>>
>> I've started a bit with it, but no success yet:
>> https://mail.ow2.org/wws/arc/asm/2017-08/msg4.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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Plamen Totev]

Hi Robert,

>
> I've started a bit with it, but no success yet:
> https://mail.ow2.org/wws/arc/asm/2017-08/msg4.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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Robert Scholte]

Hi Plamen,

On Tue, 29 Aug 2017 07:46:59 +0200, Plamen Totev  
 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/msg4.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: 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

Re: main-class + module-version

[Plamen Totev]

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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Robert Scholte]

On Mon, 28 Aug 2017 07:32:36 +0200, Plamen Totev  
 wrote:



Hi,

On Fri, Aug 25, 2017 at 6:57 PM, Robert Scholte   
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: 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

Re: main-class + module-version

[Plamen Totev]

Hi,

On Fri, Aug 25, 2017 at 6:57 PM, Robert Scholte  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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Robert Scholte]

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

Re: main-class + module-version

[Olivier Lamy]

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  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  schrieb am Mi. 23. Aug. 2017 um
> 11:16:
>
> > On Wed, 23 Aug 2017 08:11:35 +0200, Plamen Totev
> >  wrote:
> >
> > > On Tue, Aug 22, 2017 at 11:03 PM, Robert Scholte  >
> > > 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: 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

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  schrieb am Mi. 23. Aug. 2017 um 11:16:

> On Wed, 23 Aug 2017 08:11:35 +0200, Plamen Totev
>  wrote:
>
> > On Tue, Aug 22, 2017 at 11:03 PM, Robert Scholte 
> > 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: 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
>
>

Re: main-class + module-version

[Robert Scholte]

On Wed, 23 Aug 2017 08:11:35 +0200, Plamen Totev  
 wrote:


On Tue, Aug 22, 2017 at 11:03 PM, Robert Scholte   
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: 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

Re: main-class + module-version

[Plamen Totev]

On Tue, Aug 22, 2017 at 11:03 PM, Robert Scholte  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 .

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: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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  wrote:
> 
> +1 for shade plugin looks to be the most appropriate location to do this.
> 
>> On 23 August 2017 at 06:03, Robert Scholte  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 
>>> 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


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: main-class + module-version

[Olivier Lamy]

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

On 23 August 2017 at 06:03, Robert Scholte  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 
>> 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

Re: main-class + module-version

[Robert Scholte]

On Tue, 22 Aug 2017 21:23:10 +0200, Plamen Totev  
 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 
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

Re: main-class + module-version

[Plamen Totev]

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

main-class + module-version

[Robert Scholte]

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