[UIMA-3538] increase stability of eclipse plugin builds by tightening version ranges

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Component/s: Core Java Framework, Eclipse plugins, Tools
• Assignee: Unassigned
• Reporter: Marshall Schor
• Created: 09/Jan/14 21:37
• Updated: 09/Jan/14 21:37

Description

We see frequently Jenkins builds which fail with messages like:

[ERROR] Failed to execute goal on project uimaj-ep-cas-editor: Could not resolve dependencies for project org.apache.uima:uimaj-ep-cas-editor:jar:2.4.3-SNAPSHOT: Failed to collect dependencies for [junit:junit:jar:4.5 (test), org.apache.uima:uimaj-core:jar:2.4.3-SNAPSHOT (compile), org.apache.uima:uimaj-tools:jar:2.4.3-SNAPSHOT (compile), org.eclipse.core:runtime:jar:[3.3.0.0,4.0.0) (provided), org.eclipse.core:resources:jar:[3.3.0.0,4.0.0) (provided), org.eclipse:ui:jar:[3.3.0.0,4.0.0) (provided), org.eclipse.swt:org.eclipse.swt.win32.win32.x86:jar:[3.2.0.0,4.0.0) (provided), org.eclipse.ui:ide:jar:[3.3.0.0,4.0.0) (provided), org.eclipse.ui:views:jar:[3.2.0.0,4.0.0) (provided), org.eclipse.ui.workbench:texteditor:jar:[3.3.0.0,4.0.0) (provided), org.eclipse.jface:text:jar:[3.3.0.0,4.0.0) (provided), org.eclipse.equinox:app:jar:[1.0.0,1.0.1) (compile)]: No versions available for org.eclipse.equinox:common:jar:[3.6.100,4.0.0) within specified range

only to succeed later with no obvious changes. The change that happens, I think, is that the build runs on a different machine, where the build engine's ".m2" local repo has different sets of Eclipse dependencies.

I've seen this happen on my local machine - if my .m2 repo gets some later versions of Eclipse plugins, then the cas editor build starts getting these kinds of errors. What I'm guessing is happening is that the dependency resolution is getting to pick a later version of some artifact, and that artifact, in turn has dependencies on other ranges, that are higher, and not in the .m2 repo.

I think this can be "solved" by doing something like a) getting a .m2 configuration which works, and then doing a mvn dependency:tree and seeing what the versions are the dependencies, and then adding (all) or (some subset) of these with locked down dependency ranges to the list of dependencies - so that even if a higher-level version was available, it wouldn't be picked.

The downside of this is that when these plugins are installed, they will pull older versions of the plugins into the .p2 repo, slightly bloating things, perhaps, unnecessarily. It would be nice to be able to tell exactly which dependency artifact(s) needed to be "locked down" to avoid this issue, and only do that one, but I don't know how to determine that.