<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Mark ,</div><div dir="ltr"><br></div><div dir="ltr">I'm developing a new program packaging format[1]. It packages multiple JARs into a single file, which can contain named modules, automatic modules, or unmodularized JARs.<br></div><div dir="ltr">At runtime it places the contents of these JARs on the module path or classpath. Is this what you want?<br></div><div dir="ltr"><br></div><div>Glavo</div><div><br></div><div>[1]: <a href="https://github.com/Glavo/japp">https://github.com/Glavo/japp</a></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 12, 2023 at 5:20 AM Mark Raynsford <<a href="mailto:jigsaw-dev@io7m.com">jigsaw-dev@io7m.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
I have multiple applications that are modularized; all of the<br>
application modules are named modules and make heavy use of services.<br>
However, I do have many (transitive) dependencies that are only<br>
automatic modules (using Automatic-Module-Name declarations in the<br>
manifests).<br>
<br>
I want to use jpackage to produce platform-specific application<br>
distributions, but the automatic modules are causing me problems.<br>
Essentially, as far as I can tell, there are exactly two approaches<br>
that jpackage will take:<br>
<br>
  1. Put all of your application jars inside an app directory inside<br>
     the app image, and configure the runtime such that all of those<br>
     jars end up on the class path.<br>
<br>
  2. Take all of the application modules and compile them into the<br>
     resulting app image runtime using jlink.<br>
<br>
It would _really_ help myself (and possibly others, given that I've<br>
never seen a Java application consisting of 100% named modules) if<br>
there was a third option:<br>
<br>
  3. Take all of the application jars and place them inside an app<br>
     directory inside the app image, and configure the runtime such<br>
     that all of those jars _end up on the module path_.<br>
<br>
Effectively, I'd like a runtime that behaves as if "java -p app"<br>
had been specified on the command-line. I don't care about minimizing<br>
the size of the runtime with jlink by discarding unused modules. I<br>
_do_ care about having a nice double-clickable exe on Windows that<br>
has a nice icon, identifies itself properly in Process Explorer, and<br>
has all of my jars on the module path so that the services work.<br>
<br>
Is anything like this on the horizon? I believe I've published more<br>
JPMS modules than any other individual on the planet, but I've never<br>
been able to make any use of jlink due to the entire world not having<br>
been modularized. I don't want to be rewriting my dependencies with<br>
Moditect and other tools: My dependencies already work correctly on the<br>
module path, I just can't seem to get them into anything jpackage will<br>
produce!<br>
<br>
-- <br>
Mark Raynsford | <a href="https://www.io7m.com" rel="noreferrer" target="_blank">https://www.io7m.com</a><br>
<br>
</blockquote></div>