jpackage custom resources not found

[Rachel Greenham]

... 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.

That's how it's working for me anyway. :-)

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?

-- 
Rachel

On 15/01/2019 16:04, Michael Hall wrote:
>> On Jan 15, 2019, at 9:18 AM, Rachel Greenham <rachel at strangenoises.org> wrote:
>>
>> surely simpler just unpack the jpackage jdk into, say, /opt/jdk-13, ie: emphatically *not* installed as a JVM in /Library/Java/JavaVirtualMachines, and then it doesn't get in the way of anything else. When you want to use jpackage invoke, directly, /opt/jdk-13/bin/jpackage, which is a path you can put in a convenient system variable perhaps, or symlink it into your path somewhere.
>>
>> -- 
>> Rachel
>>
>> On 15/01/2019 12:09, Kustaa Nyholm wrote:
>>>> On 15 Jan 2019, at 12.57, Michael Hall <mik3hall at gmail.com> wrote:
>>>>
>>>> Usually the latest jdk with the command would be the one you’d want?
>>> Funnily enough, I wanted to quickly test something (jdeps) from the command line,
>>> and sure enough it evoked jdk-13 ea which is NOT what I want cause my main goal
>>> is to move all my stuff to jdk-11 and stay with that for next 5 years or so.
>>>
>>> For those who are not aware here is tip how to disable a jdk on MacOs:
>>>
>>> cd /Library/Java/JavaVirtualMachines/jdk-13.jdk/Contents/
>>> sudo mv Info.plist Info.plist-disabled
>>>
>>> i.e. just rename the Info.plist so that it cannot be found by the tools,
>>> after that command line tools reverted to jdk-11.0.1
>>>
>>> wrb Kusti
>>>
>>>
> What advantage does this have over JavaVirtualMachines and /usr/libexec/java_home? There is a currently active JDK, from JavaVirtualMachines.
> I move the jdk-13 to my ~/Documents folder. Then…
>
> java -version
> openjdk version "12-internal" 2019-03-19
> OpenJDK Runtime Environment (build 12-internal+0-jdk12-jpackage.7)
> OpenJDK 64-Bit Server VM (build 12-internal+0-jdk12-jpackage.7, mixed mode, sharing)
>
> is the current in the JavaVirtualMachines directory.
>
> Now I run jpackage like so…
>
> ~/Documents/jdk-13.jdk/Contents/home/bin/jpackage --version
> jpackage version 13-internal
>
> Which is a little disappointing for the purposes of this demo. It was supposed to totally fail. I was told jpackage was only meant to work with jdk-13 but it clearly at least somewhat works with jdk-12.
> Still, this is not actually correct. I believe it is using the JavaVirtualMachines jdk-12 for any java and not the jdk-13 it is included with. You could probably get around that by setting JAVA_HOME and maybe setting the PATH environment variable. This is what I just did on an Ubunutu image on VirtualBox. However, it was not the Mac way from the very beginning. Why bother to do this when you can simply use the provided JavaVirtualMachines and /usr/libexec/java_home on OS X. As was pointed out in the prior posts. What advantage does another directory give you? What is being interfered with by using the JavaVirtualMachines directory? With /usr/libexec/java_home you can get any other java to use any of the other included jdk’s and an application can be made to use an embedded jre/jdk of whatever version.
>