onejars under Jigsaw

[Remi Forax]

I wonder how far this is different from having more than one implementation for jrt ?
If we can see a uberjar as a module file system, all the other tools will work on it.

Can an uberjar be see as a kind of mount point in the jrt filesystem ?

Rémi

----- Mail original -----
> De: "Robert Scholte" <rfscholte at apache.org>
> À: jigsaw-dev at openjdk.java.net, "org openjdk" <org.openjdk at io7m.com>
> Envoyé: Samedi 19 Novembre 2016 22:53:17
> Objet: Re: onejars under Jigsaw

> Hi,
> 
> The following topics have been created for this issue:
> http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleExecutableJARs
> http://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleJARs
> 
> Once resolved we should improve the maven-shade-plugin according the new
> specifications.
> 
> Robert
> 
> 
> On Fri, 18 Nov 2016 22:40:13 +0100, <org.openjdk at io7m.com> wrote:
> 
>> Hello!
>>
>> When I write command line applications, I typically produce an
>> additional platform-independent "onejar" for convenience. More
>> specifically, I use the Maven Shade plugin to pack all of the classes
>> of all of the dependencies into a single jar with MainClass attribute.
>> The main benefit of doing things this way is that the jar file remains
>> platform independent (assuming that the code itself is platform
>> independent). A good example of this is my kstructural package:
>>
>>   http://io7m.github.io/kstructural/
>>
>> The main command-line jar program is an amalgamation of all of the
>> other modules and all dependencies:
>>
>>   https://repo1.maven.org/maven2//com/io7m/kstructural/io7m-kstructural-cmdline/0.3.0/io7m-kstructural-cmdline-0.3.0-main.jar
>>
>> Is there already a facility to do this under Jigsaw? Jlink is not quite
>> what I'm looking for in this case, because the produced artifacts would
>> be platform-specific.
>>
>> Clearly, producing onejars in pre-Jigsaw Java is like taking all of the
>> problems of the classpath and smashing them into one unfixable lump for
>> deployment. The fact that we often get builds that appear to work using
>> this method seems to owe a lot to blind luck.
>>
>> No doubt doing this sort of transformation is a hell of a lot safer when
>> there are module boundaries to work with, services declared in module
>> descriptors, and so on.
>>
>> I suspect I could address the same question to the Maven Shade list,
>> but I thought I'd better check here first. :)
>>
> > M