Open Anzo dependency management

The technology stuff

Open Anzo's has two major dependency trees:

1. Maven dependencies (pom.xml files)
2. Eclipse plugin dependencies, aka OSGi dependencies (manifest.mf and build.properties files)

The maven dependencies are used for the official Open Anzo build process.

The Eclipse plugin dependency tree is primarily for development in Eclipse. But is also provides OSGi dependency management. It's important to note that OSGi dependency management:

1. Differs from "normal eclipse project" classpaths and is not bound to the eclipse IDE.
2. Is a requirement for developing Eclipse RCP applications.

In our current situation we use the least common denominator feature set of both dependency management mechanisms. This has worked out well so far and we don't anticipate any reason for that to change. Being such, it does not seem that the features of either mechanism will play a large part in determining our strategy.

The people stuff

Developers have a tendency to grasp onto new shiny things. Usually this is a good thing. We need to be able to take advantage of new features, it can save us lots of time. But when we release stable versions of our software that depend on unstable version of other peoples software we can start to get into real trouble (the "-pre-alpha-0.0.1-SNAPSHOT" postfix to a jar file might be trying to tell you something). I believe we need some sane policy that provides stability but allows developers to migrate to newer libraries when they really need to.

Technology details

Maven and OSGi handle dependency conflict in fundamentally different ways:

1. Maven selects the "best" version of a dependency according to a set of well defined rules (that do provide for some overrides)
2. OSGi allows multiple versions of the same dependency to coexist. It makes sure that only the correct version of a dependency is visible to artifacts that depend on it.

m2eclipse is a eclipse plugin that generates eclipse classpath containers from the dependency information in maven pom files. It also allows for dependencies to be added from the eclipse UI via a simple instant search widget similar to that of the eclipse plugin dependency lookup tool. One major difference is that that m2eclipse uses maven to find and download jars from anywhere on the web.

Change is coming

To deal with the technical issues, there seems to be a few major options on the table:

1. Elect the maven dependency tree as the primary dependency tree
2. Add process to make sure all dependency changes are made to both trees

Steps I'm aware of that might make (1) viable:

1. find a way to keep the eclipse classpath containers up to date with the maven dependency tree so the IDE continues to function properly (m2eclipse seems to provide this)
2. find a way to export our maven dependency tree to OSGi files for eclipse plugin developers
3. improve our multi-module dependency tree in maven by adding (pom-poms) to all non-leaf projects so that the dependency tree fully models both project and artifact dependencies