You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Cliff Jansen <cl...@gmail.com> on 2013/03/22 05:12:02 UTC
Review Request: swig java for windows proton - compile
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/10076/
-----------------------------------------------------------
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
Re: Review Request: swig java for windows proton - compile
Posted by Keith Wall <ke...@gmail.com>.
-----------------------------------------------------------
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
>
>