-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10076/#review18254
-----------------------------------------------------------
Hi Cliff
-- cp ./build/proton-c/bindings/java/proton-jni-0.4.jar
./build/proton-c/bindings/java/proton-jni.jar
So, the test/pom.xml is relying in the fact that the cmake build has made a
symlink from ./build/proton-c/bindings/java/proton-jni.jar -->
./build/proton-c/bindings/java/proton-jni-0.4.jar but on Windows the symlink is
not created. This is because the Cmake script UseJavaSymlinks.cmake creates
symlinks only on Unix.
I think that windows does not follow the Unix tradition of sym-linking
libraries to their versioned counterparts (e.g. libz.so.1 -> libz.so.1.2.3), so
I think the right thing to do it to change the pom to read proton/version.txt
and determine the versioned JAR name. If you feel this is right approach
raise a jira and assign and me and I'll address. In the meanwhile changing the
pom will work around for now.
<jni-jar>${proton-c-build-dir}/bindings/java/proton-jni.jar</jni-jar>
to:
<jni-jar>${proton-c-build-dir}/bindings/java/proton-jni-0.4.jar</jni-jar>
-- java.util.ServiceConfigurationError:
org.apache.qpid.proton.codec.DataFactory: Provider
org.apache.qpid.proton.codec.jni.JNIDataFactory could not be instantiated:
java.lang.UnsatisfiedLinkError: no proton-jni in java.library.path
I think I understand part of the problem. There are two parts:
a) test/pom.xml is using a UNIX path separator in variable jni-native-path
rather than the platform neutral ${path.separator}
b) on Windows cmake/msbuild is generating the .dlls into a /Debug subdirectory,
but test/pom.xml knows nothing about the Debug portion, so it is starting the
JVM with the wrong java.library.path. Now we could change the pom to build a
platform dependent path, but I am not sure if this is best approach. Is there a
better way for Maven to reference the .dll?
btw. I tried the following (non-viable) change, and found that the error
messages changes to java.lang.UnsatisfiedLinkError:
X:\src\proton\build\proton-c\bindings\java\Debug\proton-jni.dll: Can't find
dependent libraries. I tried a tool called DependencyWalker, and this
suggested that it was failing to find library IEShims.dll????
<jni-native-path>${proton-c-build-dir}:${proton-c-build-dir}/bindings/java</jni-native-path>
to:
<jni-native-path>${proton-c-build-dir}/Debug${path.separator}${proton-c-build-dir}/bindings/java/Debug</jni-native-path>
Hope this helps
http://svn.apache.org/repos/asf/qpid/proton/trunk/tools/cmake/Modules/ProtonUseJavaSourceFileList.cmake
<https://reviews.apache.org/r/10076/#comment38464>
Perhaps we could use a safe(?) separator that works for both platforms?
I've googled around this morning and found examples of people using double
colons (::) for this situation. It would avoid the need for the platform
specific code.
It irks me that there is no elegant way to pass a list to a cmake -P script.
- Keith Wall
On March 22, 2013, 4:12 a.m., Cliff Jansen wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10076/
> -----------------------------------------------------------
>
> (Updated March 22, 2013, 4:12 a.m.)
>
>
> Review request for qpid and Keith Wall.
>
>
> Description
> -------
>
> More for proton-254.
>
> Of note is the mechanism proton-c/bindings/java/checkmatch.py to ensure that
> any changes to codec.h will cause a build failure if they aren't also
> included in the corresponding java.i file. All proposed solutions on the
> list thus far have not been particularly elegant. This attempts to address
> the main drawback of this apporach (the two files getting out of sync).
>
> I suspect that the solution for other swig languages will at least differ on
> the %extend pn_atom_t {} section. I would prefer to defer a more generalized
> solution (if any) until another example pops up.
>
> The pieces all build, but ctest fails and I cannot get the equivalent to
> start running from the command line, so I can't work backwards to a better
> cmake build. By hand I must
>
> - cp ./build/proton-c/bindings/java/proton-jni-0.4.jar
> ./build/proton-c/bindings/java/proton-jni.jar
> - resolve PATH for finding maven in ctest (may not be an issue if set
> globally).
>
> Even after this, the maven test fails with
>
> java.util.ServiceConfigurationError:
> org.apache.qpid.proton.codec.DataFactory: Provider
> org.apache.qpid.proton.codec.jni.JNIDataFactory could not be instantiated:
> java.lang.UnsatisfiedLinkError: no proton-jni in java.library.path
>
> I'm not sure where to point fingers (the maven pom, the built files). I will
> attempt a simple java test outside of maven to see if that works.
>
>
> This addresses bug proton-254.
> https://issues.apache.org/jira/browse/proton-254
>
>
> Diffs
> -----
>
>
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/java/CMakeLists.txt
> 1459606
>
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/java/checkmatch.py
> PRE-CREATION
>
> http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-c/bindings/java/java.i
> 1459606
>
> http://svn.apache.org/repos/asf/qpid/proton/trunk/tools/cmake/Modules/ProtonUseJavaSourceFileList.cmake
> 1459606
>
> Diff: https://reviews.apache.org/r/10076/diff/
>
>
> Testing
> -------
>
> rhel 6 and windows 8
>
>
> Thanks,
>
> Cliff Jansen
>
>
