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" <rfscho...@apache.org> > À: jigsaw-dev@openjdk.java.net, "org openjdk" <org.open...@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.open...@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
