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

rfscholte
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  
<[hidden email]> 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: [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

Andreas Sewe-2
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 (899 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: main-class + module-version

rfscholte
In reply to this post by rfscholte
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  
<[hidden email]> wrote:

> Hi,
>
> On Mon, Jan 15, 2018 at 8:23 PM, Robert Scholte <[hidden email]>  
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]

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