Extended search #35
Closed
Extended search #35
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
michael-o
reviewed
Mar 20, 2017
| * <ol> | ||
| * <li> as "<code>${name}-${version}</code>" library name if the version can be determined. | ||
| * <li> as "<code>${name}</code>" library name | ||
| * </ol> | ||
| * <li> system library path: This is where the JVM looks for JNI libraries by default. | ||
| * <ol> | ||
| * <li> as "<code>${name}${bit-model}-${version}</code>" library name if the version can be determined. |
There was a problem hiding this comment.
Why did you add that? System library path (LD_LIBRARY_PATH, rpath) will unlikely contain the bit model. It looks unnecessary to me.
There was a problem hiding this comment.
why did I add to documentation what was done in code?
There was a problem hiding this comment.
Then this is OK, assumed you have changed the code too. It's an unrelated change though.
michael-o
reviewed
Mar 20, 2017
| * <li> as "<code>${name}-${version}</code>" library name if the version can be determined. | ||
| * <li> as "<code>${name}</code>" library name | ||
| * </ol> | ||
| * <li> classpath path: If the JNI library can be found on the classpath, it will get extracted | ||
| * and then loaded. This way you can embed your JNI libraries into your packaged JAR files. | ||
| * They are looked up as resources in this order: | ||
| * <ol> | ||
| * <li> "<code>META-INF/native/${platform}/${arch}/${library}</code>": Store your library here if you want to embed | ||
| * <li> "<code>META-INF/native/${platform}/${arch}/${library[-version]}</code>": Store your library here if you want to embed |
There was a problem hiding this comment.
How is this version necessary for our usecase? Especially because only one version of the native library should exist once in the classpath OR the JAR from central contains its version anyway.
There was a problem hiding this comment.
once again, I'm not judging anything: I'm just keeping existing features, even if I never used it myself
|
Looks good to me after review. |
|
Could you rebase your PR please ? |
michael-o
reviewed
Apr 26, 2017
|
|
||
| if( customPath!=null ) { | ||
| // Try to extract it to the custom path... | ||
| File target = extract(errors, resource, prefix, suffix, file(customPath)); | ||
| File target = extracttoTmpFile(errors, resource, tmpFilePrefix, tmpFileSuffix, file(customPath)); |
| @@ -240,7 +284,7 @@ private boolean extractAndLoad(ArrayList<String> errors, String version, String | |||
|
|
|||
| // Fall back to extracting to the tmp dir | |||
| customPath = System.getProperty("java.io.tmpdir"); | |||
| File target = extract(errors, resource, prefix, suffix, file(customPath)); | |||
| File target = extracttoTmpFile(errors, resource, tmpFilePrefix, tmpFileSuffix, file(customPath)); | |||
| * <ol> | ||
| * <li> as "<code>${name}-${version}</code>" library name if the version can be determined. | ||
| * <li> as "<code>${name}</code>" library name | ||
| * </ol> | ||
| * <li> system library path: This is where the JVM looks for JNI libraries by default. | ||
| * <ol> | ||
| * <li> as "<code>${name}${bit-model}-${version}</code>" library name if the version can be determined. |
There was a problem hiding this comment.
Then this is OK, assumed you have changed the code too. It's an unrelated change though.
| * <li> as "<code>${name}-${version}</code>" library name if the version can be determined. | ||
| * <li> as "<code>${name}</code>" library name | ||
| * </ol> | ||
| * <li> classpath path: If the JNI library can be found on the classpath, it will get extracted | ||
| * and then loaded. This way you can embed your JNI libraries into your packaged JAR files. | ||
| * They are looked up as resources in this order: | ||
| * <ol> | ||
| * <li> "<code>META-INF/native/${platform}/${arch}/${library}</code>": Store your library here if you want to embed | ||
| * <li> "<code>META-INF/native/${platform}/${arch}/${library[-version]}</code>": Store your library here if you want to embed |
|
Manually merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Extended search in library.$name.path to do the same as in META-INF/native:
this will enable scenario where a distribution extracts native libraries to avoid temp file creation if the lib auto-extracts on each run
see https://issues.apache.org/jira/browse/MNG-6186 for a use case in Maven