Original Synopsis:
[macos]: Include the application directory $APPDIR in class path
ADDITIONAL SYSTEM INFORMATION :
Mac OS 10.15.7 Catalina
Java 16
A DESCRIPTION OF THE PROBLEM :
Previously the appbundler tool that was available related to the macport project had a Java/Classes directory that was included in java.class.path. I had various non-class resources added that I loaded off of class path. When jpackage didn't have such a directory entry in class path I jar'ed them instead. Being able to access these resources would be one use for this.
Another reason would be if there was actually a need for exploded classes as in the following bug report.
https://bugs.openjdk.java.net/browse/JDK-8263940
This concerns nio DefaultFileSystemProvider not working with jars, not modular, in class path. A workaround is to have the classes exploded.
There might be other situations where 'app' or perhaps some directory in 'app' could be useful to have in class path.
Updated Synopsis
Allow class path specification in java-options:
Currently, specifying "-cp", "-classpath", or "-Djava.class.path=..." in the value of "--java-options" argument to jpackage would likely cause the application to not run, since the classpath generated by jpackage tool would be overridden by the classpath in the value of the --java-options option.
The proposed change is to append the classpath given by --java-options to the classpath generated by jpackage.
An app wanting to access files from either the input dir or a sub-directory of it) as resources could just include "--java-options='-cp \$APPDIR'" or "--java-options='-cp \$APPDIR/<subdir>'"
[macos]: Include the application directory $APPDIR in class path
ADDITIONAL SYSTEM INFORMATION :
Mac OS 10.15.7 Catalina
Java 16
A DESCRIPTION OF THE PROBLEM :
Previously the appbundler tool that was available related to the macport project had a Java/Classes directory that was included in java.class.path. I had various non-class resources added that I loaded off of class path. When jpackage didn't have such a directory entry in class path I jar'ed them instead. Being able to access these resources would be one use for this.
Another reason would be if there was actually a need for exploded classes as in the following bug report.
https://bugs.openjdk.java.net/browse/JDK-8263940
This concerns nio DefaultFileSystemProvider not working with jars, not modular, in class path. A workaround is to have the classes exploded.
There might be other situations where 'app' or perhaps some directory in 'app' could be useful to have in class path.
Updated Synopsis
Allow class path specification in java-options:
Currently, specifying "-cp", "-classpath", or "-Djava.class.path=..." in the value of "--java-options" argument to jpackage would likely cause the application to not run, since the classpath generated by jpackage tool would be overridden by the classpath in the value of the --java-options option.
The proposed change is to append the classpath given by --java-options to the classpath generated by jpackage.
An app wanting to access files from either the input dir or a sub-directory of it) as resources could just include "--java-options='-cp \$APPDIR'" or "--java-options='-cp \$APPDIR/<subdir>'"
- relates to
-
JDK-8264730 Document java-options limitations
- Resolved