There is a issue (RT-11182) about having the runtime jar in a Maven repository and it contains motivation why this is important (it is). The JFXtras project we've already setup using Maven and we install the jar manually (mvn install:install-file -Dfile=/Users/sjc/dev/javafx-sdk2.0-beta/rt/lib/jfxrt.jar -DgroupId=com.oracle -DartifactId=javafx-runtime -Dversion=2.0-beta -Dpackaging=jar), so that somewhat resolves RT11182.
However, one thing we cannot quick-fix is the loading of the associated DDL's. It seems JFX always loads from a path relative to the runtime jar (../lib) and that path does not exists in Maven. The patch here is to manually copy the lib directory to the Maven local repository, but that is not even a patch, or a hot fix, but a kludge. The standard approach to having DLL dependencies is to either 1) include every dependency or 2) put all DLL's in a single jar and include that as a dependency (http://docs.codehaus.org/display/MAVENUSER/Projects+With+JNI). If more than one DLL and more than one platform the second approach usually takes preference, but in any case is it required to load the DLL's from the classpath and not via a relative path.
Maven support is mandatory nowadays, and the DLL / SO loading should support that.
However, one thing we cannot quick-fix is the loading of the associated DDL's. It seems JFX always loads from a path relative to the runtime jar (../lib) and that path does not exists in Maven. The patch here is to manually copy the lib directory to the Maven local repository, but that is not even a patch, or a hot fix, but a kludge. The standard approach to having DLL dependencies is to either 1) include every dependency or 2) put all DLL's in a single jar and include that as a dependency (http://docs.codehaus.org/display/MAVENUSER/Projects+With+JNI). If more than one DLL and more than one platform the second approach usually takes preference, but in any case is it required to load the DLL's from the classpath and not via a relative path.
Maven support is mandatory nowadays, and the DLL / SO loading should support that.
- duplicates
-
JDK-8100563 Maven DLL loading
- Closed
- relates to
-
JDK-8128437 NativeLibLoader fails to load libWebPaneJava.dylib when loading jfxrt.jar via OSGi
- Closed