I have the following scenario:
mylib is a library (for which I have the sources, so I'd like to put them into a Maven project mylib:mylib for example). This library has a jar dependency for which I only have the jar, and it is not to be found in the Maven repository (and I do NOT want to install it there either). To make it compile, something like this would work: add the jar file to the mylib project in a "lib" folder, e.g. "lib/thirdpartylib.jar" and in mylib's pom.xml, add a dependency with self-chosen group/artifact/version and a "<scope>system</scope><systemPath>${project.basedir}/lib/thirdpartylib.jar</systemPath>
" entry. The mylib project will compile fine.
Note that mylib also has a runtime dependency to a dll file, say thirdparty.dll. But for compilation this is not important.
However, now what I am wondering how to achieve the following:
Any other projects, e.g. project "X", that uses mylib, will need the
- mylib.jar
- thirdpartylib.jar
- thirdpartylib.dll
,
and it'll have to set the java.library.path to the directory (e.g. ".") such that the thirdparty jar and dll are found by the executing VM.
My concern is this: I would like the thirdparty jar/dll things to be the responsibility of the mylib project. I.e. I want to define the knowledge, that you need to copy the thirdparty jar and dll to the target folder and that java.library.path refers to them, to be part of the mylib project (the mylib pom knows how the thing is to be used in other projects). Yet, I want this knowledge (i.e. copy instructions, regardless how they are exactly done in Maven) to be transitively handed over to any other project using mylib, like X for example. Is that somehow possible?
[My hack solution for now would be that I have a copy of the thirdparty things in X, but even then I dunno how to copy/deal with the dll file, so I'd have to write a readme saying that the dll file has to be copied to the bin folder of the executing VM).
Any suggestions are appreciated!
I'd suggest turning the files into Maven modules, by installing them into the local repository using the Maven install plug-in
mvn install:install-file \
-DgroupId=com.demo \
-DartifactId=thirdpartylib \
-Dversion=1.0 \
-Dfile=thirdpartylib.jar
mvn install:install-file \
-DgroupId=com.demo \
-DartifactId=thirdpartylib-runtime \
-Dversion=1.0 \
-Dpackaging=dll
-Dfile=thirdpartylib.dll
One of the neat things about this approach is that the Maven POM will be automatically generated.
The mylib project now declares the thirdparty modules as normal dependencies in it's POM file:
<dependencies>
<dependency>
<groupId>com.demo</groupId>
<artifactId>thirdpartylib</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>com.demo</groupId>
<artifactId>thirdpartylib-runtime</artifactId>
<version>1.0</version>
<scope>runtime</scope>
</dependency>
</dependencies>
Now when the mylib module is referenced by other modules (as a dependency) the thirdparty modules will also be downloaded as transitive dependencies.
The base idea is the following:
- Maven is good in handling with one result per Maven POM.
- It is possible to have libraries and dependencies to these libraries in your local repositories only.
So you have to do the following steps:
- Define for the additional library a separate project (or a module in your project) and define the library as the result.
- Change your POM so that this POM has now a dependency to the new project.
- Do the same steps for your DLL (see the post Managing DLL dependencies with Maven) how to do that).
- Deploy your additional library and your DLL to your local repository.
Now you should be able to use Maven for the build process again, and by using additional plugins like the maven-assembly-plugin
, you are able to pack all together.
来源:https://stackoverflow.com/questions/7515504/maven-project-with-native-dependency-and-copying-files