Sharing dependency configuration over multiple projects (Maven)

Question

From a big SVN repository we want to switch to Maven/Gradle for handling dependencies so that programmers can work with a single project without checking out the whole thing.

We are writing plugins for a server (its interface). Some of our plugins depend on other plugins that are also installed on the server. So our plugins should always be build against the versions that are currently (or going to be) used on the server.

For example lets say my plugin A depends on an external plugin B. Today B is installed with version 1.2.3, but tomorrow it could be installed with 1.2.4. When building A it is important to always build against the right version.

My problem is that we have hundreds of plugins like A so it would be nearly impossible to manually update the versions of all dependencies just if one plugin like B is used with a new version.

Now I thought about two options even if I am not sure how to accomplish them.

1. Using some kind of global configuration for dependency versions (no idea if or how this could be done)

2. Always hosting the current used artifacts in a seperate repository

Global dependency resolver
Since I am new to Maven I do not know if this might be a possible or even acceptable solution. I just thought about creating some kind of artifact, that contains all the dependencies that plugins like A could have. The really bad thing (even if this would work) is that plugin A would have dependencies it does not really need.

Global version configuration
Then I thought about a way to tell Maven/Gradle what the latest dependency version of a specific artifact is. I dont know if this is possible or if this would lead to other problems.

Hosting the artifacts
At the moment im testing hosting the external dependencies on a seperate repository as snapshots so that our plugins will be able to always resolve them to the highest available version. Currently this leads to problems when resolving the dependency dependencies but I guess that I just missted something in the configuration. However I am unsure if this could be a right way to go.

I hope that you understand what we need so maybe you can give me some advices or keywords for concepts that could solve our issue. We want to switch to a dependency management system (at the moment all dependencies are included locally) but all options seem more complicated than staying with our messed up repository.

Answer 1

If I understand your situation clearly, it seems like you have many A type Maven artifacts, and these mostly all define a dependency to a few B type artifacts.

The A type artifacts are product of your development Group. The B type artifacts that A depends on are from an external Group. Your runtime environments for A type and B type Artifacts will have bundled into them the B Artifacts already.

The problem is that when the Version of a B Artifact changes on the server, you do not want to be hassled with manually updating many POM files with all of the dependency changes that happened in B initially.

Your first suggestion I think is the best approach:

I just thought about creating some kind of artifact, that contains all the dependencies that plugins like A could have.

You can absolutely do this and it is an accepted practice. What you do is define a parent POM file that declares all of the dependencies an A type Artifact could need. This parent POM file can be deployed to your Maven repository as it's own unique Group, Artifact and Versioned module. This parent POM module can then be referenced in your A type projects POM files using the <parent> element. The benefit is that you can update all of the B type plugin versions in the parent project and reversion just the parent POM. Now your A type POM's only need to update their version number if they are to get the new dependencies. For more information on Parent POM projects see below.

https://stackoverflow.com/questions/14400642/maven-parent-pom

The really bad thing (even if this would work) is that plugin A would have dependencies it does not really need.

But you see this isn't actually a bad thing!

<dependency>
  ...
  <scope>provided</compile>
</dependency>

Using the provided scope on a dependency to a B plugin is basically telling Maven that it is ONLY going to use this Artifact for compiling sources and unit testing. It will ignore the dependency specifically during packaging of the build artifact with the assumption that the JDK or the application container will provide this for the plugin during runtime.

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

If some of the dependencies aren't being used it won't matter. They won't be bundled, they are only downloaded and used to compile and run test cases.