jpackage custom resources not found

Rachel Greenham rachel at
Tue Jan 15 16:55:06 UTC 2019

My understanding was that this particular jdk build only exists for the 
sake of getting jpackage out there into our hands (hence my point about 
putting it out as a jlinked app instead), and if you want to play with 
jdk13-ea in its own right, should probably get a fresh one to do just 
that, as the one used in these jpackage builds is not necessarily always 
going to be the most up to date, and also may have changes needed by 
jpackage that haven't been accepted upstream yet. In fact the latter 
seems almost likely to me as otherwise why not just include jpackage in 
the ea builds now?

 From my point of view, it's easy enough to do this, and the only 
downside is needing to exec it as its own process rather than invoke 
in-process via ToolProvider from my usual buildsystem jdk, which I 
intend to move to doing later when it is finally part of the JDK I'm 
actually building with. Wastes disk space too, but don't care about 
that, have plenty. :-)


On 15/01/2019 16:33, Michael Hall wrote:
>> On Jan 15, 2019, at 10:25 AM, Rachel Greenham <rachel at> wrote:
>> ... simply that you don't *want* jpackage's jdk to be in your path, you don't want it to be the default, you *only* want it to run jpackage *itself*, in create-image using --runtime-image pointing to your already jlinked runtime image using your usual JDK; then in create-installer, using --app-image to point to the image created in create-image. In all other respects you build your application with your usual JDK, this one is *just* for running jpackage, and only exists at all because jpackage isn't ready to go in the JDK proper yet.
> Ah, well I had also sort of thought it would be a good idea to try my own app on something more bleeding edge. There are some things broken I need to address. But unless you have problems with something in the new release on default command line usage it seems you can easily control version in other scenarios.
>> That's how it's working for me anyway. :-)
> The above currently works for me. Different people have different preferences for how things work.
>> I wonder if it would be easier if, while we're in this packager gap, to provide jpackage as a jlinked app image rather than a full jdk? Is that possible?
> Not sure on that.
>> -- 
>> Rachel

More information about the core-libs-dev mailing list