Conversation
# Conflicts: # storage/inchi/src/test/java/org/openscience/cdk/inchi/InChIToStructureTest.java
|
I think the idea is to fix this instead by (runtime?) depending on the new |
|
yeah I wasn't sure if the idea going forward was to assume JNA-inchi and have additional support for jni so things should default to jna or if you wanted to make it more flexible based on which modules are loaded? |
|
@dkatzel-ncats, can you try the current <dependency>
<groupId>org.openscience.cdk</groupId>
<artifactId>cdk-jniinchi-support</artifactId>
<version>2.7.1</version>
</dependency>Does that solve it? |
|
That would fix the compiler error but my downstream software can't use JNI inchi we must use JNA |
|
No, I think this |
|
@dkatzel-ncats, check https://github.com/cdk/cdk/tree/master/storage/jniinchi-support/src/main/java/net/sf/jniinchi and if you like that module's pom file too... I think it's really just these two classes. |
|
Yep include the jniinchi-support-module for now, not doing another release sorry am swamped ATM. |
|
I'll fix on master though, it's just a mater of not using the INCHI_OPTION etc |
|
To clarify as Egon said it's jus the Enum's not the actual JNI stuff. It's basically to provide backwards compatible API support, everything still uses JNA inchi. |
|
I can confirm using 2.7.1 with jniinchi-support to my software that uses cdk does make everything work using 2.7.1 thanks! |
|
Fix on master once pulled, sorry about that - experimenting with optional dependencies and so they are a little magical such that even the tests didn't pick this up. Please let us know if you find other issues. |
This is the fix for #797 as well as adding the fix for 2.7.1 to the 2.8 branch.
This is as small a change as possible. Alternative approaches are to make the inchi options and return value Strings instead of enums so there wouldn't be a dependency for either JNA or JNI inchi. but there would then be a lot more String parsing into those enums every time which would might lead to performance problems.
Another approach would be to make a CDK inchi interface that wraps the underlying JNI/JNA implementation but that would be more code changes and API breaking changes.