-
Task
-
Resolution: Fixed
-
Neutral
-
5.0
-
None
-
None
-
-
Empty show more show less
-
Empty show more show less
I removed the currently unused/unneeded bundle of the workflow module. This caused dependency resolution issues with the ee-bundle that I will describe below. Should this bundle ever be needed again, please be aware of the following.
There is a bug in Maven 2.2.1; it is apparently solved in Maven 3.1, but I haven't found a bug report yet, so it could also be fixed in 3.0.x.
(see http://maven.40175.n5.nabble.com/Changes-in-how-exclusions-are-applied-transitively-td5765098.html)
Maven bug description
- A has dependencies on B and C. Both transitively
depend on D (through X, which is irrelevant, I think) but B excludes
it (on its dep declaration of X)
- With 2.2.1, D was (wrongly) completely excluded from A (possibly depending on
dependency order), even though C needs it and did not exclude it.
- With 3.1, it appears to behave "correctly", i.e D is part of the dependency tree of A (through C).
Symptoms
In the case of workflow and ee-bundle, the impacted dependency was antlr. magnolia-module-jbpm was excluding it by means of an <exclusion> on its dependency on jbpm-flow-builder. This exclusion was apparently added to reduce the size of said bundle. I'm assuming the intention was to avoid redundancy with artifacts that were already in EE bundle. (indeed, the 4-5-migration module, upon which many modules depend, uses antlr).
What to do
- Verify antlr is indeed needed in either case. (see below)
- If so, verify antlr is included in the ee webapp. (both versions - see below)
- If you added an exclusion, verify the consequences.
- If you removed an exclusion, ditto.
- If you change the order of dependencies in the ee bundle or webapp, ditto.
Alternatively
- Consider upgrading to Maven 3.1 (preferably if/when we identified this specific issue) (thereby upgrading the parent pom, our <prerequisites> and our configuration for the enforcer plugin)
Further weirdness
Most uses of antlr i've seen actually declare a dependency on org.antlr:antlr:3.x. For some weird reason, this ends up transitively depending on antlr:antlr:2.7.7. This shouldn't have consequences at runtime, since both use a different package structure. I'm not sure what the intention of this was; perhaps the author intended for users to exclude antlr themselves ?
And for some reason I can't explain either, the bug above only seemed to impact (i.e exclude) antlr:antlr, not org.antlr:antlr