uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Created] (UIMA-3538) increase stability of eclipse plugin builds by tightening version ranges
Date Thu, 09 Jan 2014 21:37:51 GMT
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:[,4.0.0)
(provided), org.eclipse.core:resources:jar:[,4.0.0) (provided), org.eclipse:ui:jar:[,4.0.0)
(provided), org.eclipse.swt:org.eclipse.swt.win32.win32.x86:jar:[,4.0.0) (provided),
org.eclipse.ui:ide:jar:[,4.0.0) (provided), org.eclipse.ui:views:jar:[,4.0.0)
(provided), org.eclipse.ui.workbench:texteditor:jar:[,4.0.0) (provided), org.eclipse.jface:text:jar:[,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

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

View raw message