jpackage custom resources not found
rachel at strangenoises.org
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 strangenoises.org> 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.
More information about the core-libs-dev