Intelligent dependency handling with Maven

Question

I am currently involved in the conversion of a large multi-module project (~ 100 submodules) to use Maven. We are currently using Ant + Ivy.

So far, no serious problems have arisen, and I am comfortable that Maven is still suitable. However, I am wondering if there is a better way to deal with native dependencies.

So far I have come to the following conclusions.

• It is best to install each of your own dependencies in the maven repository as a stand-alone library or archive package containing several dependencies.

• Instead of being mistaken in declaring each dependency with the Maven dependency plugin, I decided to give each classifier (for example, natives-win32) and use the following in the parent POM:

  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <version>2.4</version> <executions> <execution> <id>copy</id> <phase>compile</phase> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <includeScope>runtime</includeScope> <includeClassifiers>natives-win32</includeClassifiers> <outputDirectory>${project.build.directory}/natives</outputDirectory> </configuration> </execution> </executions> </plugin> 

So far, this seems like a simple comprehensive solution that does not require too much to add new own dependencies. He also offers me a simple comprehensive solution for managing the natives. The only thing I have to do is make sure the directory my / natives / is defined on java.library.path.

One thing that bothers me (a bit) about this approach is that all of my own dependencies are copied around each submodule that expresses a transitive dependency on them, while my lucky jar libraries are added to the class path referencing where they are sitting in my local storage (no copy required).

Is there no way to be smarter in this matter, and my indigenous people refer to their location in the repository (if I do not have them in the archive, i.e. dll). This would save a bunch of unnecessary copying.

Are there any other potential errors that should be affected by the above approach?

Answer 1

In the end, I used the maven natives plugin and dealt with the fact that I have redundant copies of the native libraries around the place. The reason for this was primarily due to the simplicity that the plugin offers, and the fact that it also has an eclipse plugin associated with it, which configures the natives in an eclipse development environment without intervention.

Answer 2

Your fragment displays a target that is tied to the build phase, not a dependency. Is the target of “copy dependencies” in the superpome and inherited by all modules? There is no way to move it only to modules that will be launched / packaged as an application?

Answer 3

Maybe I didn’t get it. But why don't you deploy all your own libraries in the repository. If native libraries are stable and rarely change, this can be done in a separate reactor.

And after that you refer to these own dependencies simply through GAV like any other dependency. Also, the problem with unnecessary copying is solved by this.