Marshall Schor created UIMA-3538:
------------------------------------
Summary: increase stability of eclipse plugin builds by tightening
version ranges
Key: UIMA-3538
URL: https://issues.apache.org/jira/browse/UIMA-3538
Project: UIMA
Issue Type: Improvement
Components: Core Java Framework, Eclipse plugins, Tools
Reporter: Marshall Schor
Priority: Minor
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.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
