为什么Maven修剪“ lib” Java期望此约定链接时，安装本机库时的前缀？
最近，我正在恢复两个涉及基于JNI的项目（带有本机库）代码的项目。构建系统是遗产（基于makefile，而不是Maven或Gradle），但是考虑到项目的年龄（其成立于Maven），这是可以的，并且因为该代码的某些重要部分未用Java编写。
没有计划用maven或gradle配置脚本替换makefile（或配置）脚本（我继承的构建系统正常工作，并且鉴于软件不是纯java的事实，可能不会更简单地使用其他工具。 。
但是，在Maven Repo中部署JARS（甚至是使用另一个工具构建的）使用Maven安装插件很简单，并且通过第三方代码的使用更加简单，因此我这样做了。
我可以使一切都起作用，但是我无法弄清楚为什么Maven（或更具体地说，Maven Install插件）表现得像它一样，这似乎使事情变得比需要更复杂。很可能缺乏对Maven的行为或Java链接系统的理解。
这是问题：要安装JAR及其本地库，可以使用以下命令。
mvn install:install-file -Dfile=$(jarFile) -DgroupId=$(groupId) -DartifactId=$(artifactId) -Dversion=$(libraryVersion) -Dpackaging=jar
mvn install:install-file -Dfile=$(nativeLibraryFile) -DgroupId=$(groupId) -DartifactId=$(artifactId) -Dversion=$(libraryVersion) -Dpackaging=$(soExtension)
在这里，可以根据操作系统 dylib 取决于操作系统。 这两个文件最终位于Maven本地存储库的同一位置，即.m2/repository/groupId/artifactid/destryId
但是，我观察到，本机库，最初称为libmylibrary 。结果，即使给出了Java的适当库路径（-djava.library.path选项），它也会发出链接错误，因为它找不到正确的库名称（它确实期望' lib“前缀，至少在我的可用实现中）。
链接错误可以通过几种方式解决：
- 将文件（修剪为Maven修剪）回到其正确的名称
- 通过将文件（修剪为Maven修剪）以后创建链接（在支持链接的系统上），
。前两个解决方案是一种相当笨拙的方法，因为他们对Maven存储库的内部有了了解（违反了封装原则）。
- 另一个解决方案是不依靠Maven，而是在通常期望动态库的系统目录下安装本机库（LD_LIBRARY_PATH或等效）。这是我选择的解决方案，但我发现它很难维护，因为现在两个文件（JAR和本机库）在两个不同的位置都分开了。这也使卸载包装更加困难。
有人知道为什么Maven安装系统以其方式行事？如果有解决方法吗？
谢谢
I have been reviving two projects lately involving JNI-based (Java with native libraries) code. The build system is legacy (Makefile based, not Maven or Gradle), but that's ok given the age of the projects (their inception predates Maven), and because some significant parts of the code are not written in Java.
There is no plan for replacing the Makefile (or configure) scripts with Maven or Gradle configuration scripts (the build systems I inherited work fine, and would probably not been made simpler with other tools, given the fact that the softwares are not pure Java).
However, deploying the jars (even built with another tool) in the Maven repo is straightforward with the Maven installation plugin, and makes their use by third party code much simpler, so I went this way.
I can make everything work, but I have been unable to figure out why Maven (or more specifically, the Maven install plugin) behaves like it does, that seems to make things more complex than they need to be. Most probably, my understanding of Maven's behaviour or of the Java linking system is lacking.
Here is the issue: for installing a jar and its native library, one can use the following commands.
mvn install:install-file -Dfile=$(jarFile) -DgroupId=$(groupId) -DartifactId=$(artifactId) -Dversion=$(libraryVersion) -Dpackaging=jar
mvn install:install-file -Dfile=$(nativeLibraryFile) -DgroupId=$(groupId) -DartifactId=$(artifactId) -Dversion=$(libraryVersion) -Dpackaging=$(soExtension)
Here soExtension can be dll, so, dylib depending on the operating system.
The two files end up in the same location of the Maven local repository, namely .m2/repository/groupId/artifactId/versionId
However, I observed that the native library, initially called, say libmylibrary.so, was systematically renamed by Maven mylibrary.so in the repository. As a consequence, even when java is given the proper library path (the -Djava.library.path option), it issues a link error because it cannot find the right library name (it does expect the "lib" prefix, at least in my available implementations).
The link error can be solved by several means:
- by renaming the file (trimmed by Maven) back to its correct name
- by creating a link afterwards (on systems that support links).
The two previous solutions are a rather clumsy way to go, because they assume a knowledge of the internals of the Maven repository (going against the encapsulation principle).
- another solution is not to rely on Maven, and to install native libraries under the system directories where dynamic libraries are usually expected (LD_LIBRARY_PATH or equivalent). It has been my solution of choice as a last resort, but I find it rather fragile and harder to maintain, since both files (the jar and the native library) are now separated in two different locations. It also makes the uninstallation of the package more difficult.
Does anyone know why the Maven installation system behave the way it does? And if there is a workaround for it?
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
存储库中的工件名称是由
artifactid生成的，没有可能更改它。如果您愿意或需要更改，则您必须更改artifactid。对于在特定平台上运行的，我将创建一种安装软件包，其中包含正确命名的工件。
The name of artifacts in a repository is generated out of
artifactIdand no there is no possibility to change that. If you like or need to change thatyou have to change theartifactId.For running that on a particular platform I would create a kind of installation package which contains the correctly named artifacts.