fixing up eclipse plugin refs in multiple projects

[Marshall Schor <ms...@schor.com>]

I found that after a nexus mirror I was using got relocated, and needed to
replenish it's cache, that one of the sources we had been using for a long time
for Eclipse Plugins, repo1.maven.org/eclipse, had disappeared (gave 404 not found).

That now-removed repo had put most of the eclipse plugins into a repo structure
org.eclipse.xxx.yy.zz  etc.  This was the eclipse structure in the repo around 2007.

We coded our dependencies using those groupId/artifactId coordinates.

Currently, almost all of these groupId/artifactIds have been changed in the
current eclipse maven artifacts at maven-central.  The common groupId is
frequently now org.eclipse.platform, and the artifact id is now frequently a
dotted name, e.g. org.eclipse.jface.text etc.

I'm updating the uimaj-ep-xxx plugins to be able to use the eclipse plugins in
maven central.  The main update consists of these steps:

  * replace the groupId/artifactId with current repo coordinates, usually
org/eclipse/platform as the groupId (except for the org.eclipse.jdt artifacts).
  * set the version to the lowest version that works (to provide for better
chance of the plugins working with older Eclipse versions)
  * run mvn dependency:tree to see what exclusions might need to be added. 
    ** scan the dependency tree to see what might need to be excluded, and if
the "provided" scope is properly set, and if there are "extra" top level
dependencies that aren't needed because they duplicate existing transitive
dependencies.
  * run mvn clean install to insure the fixed project has enough things.

I see several other projects that look like they might need updating at some
point, because they are using the now defunct repo1.maven.org/eclipse repo;
these include:

ruta, ruta-parent

ConceptMapper (was part of add-ons, now separately released)

addons, addons-parent

uima-ducc, uima-ducc-parent

-Marshall

Re: fixing up eclipse plugin refs in multiple projects

[Marshall Schor <ms...@schor.com>]

One quirk.  The swt support in org/eclipse/platform : org.eclipse.swt, started
using a environment var: osgi.platform, to include a choice of target swt impl. 
The line in the pom for this now looks like:

<dependencies>
  <dependency>
    <groupId>org.eclipse.platform</groupId>
    <artifactId>org.eclipse.swt.${osgi.platform}</artifactId>
    <version>[3.105.3,3.105.3]</version>
  </dependency>
</dependencies>

If you don't set this osgi.platform (e.g. mvn dependency:tree
-Dosgi.platform=win32.win32.x86_64 ), you get a complaint about unparsable
dependencies, or if you are using mvn install, and supply this, you get a
complaint about the version - it doesn't like [x.y.z, x.y.z] - identical version
numbers as the range.

The work-around is to continue to use the "old" style swt ref, not in
org/eclipse/platform groupId.  The only version in maven central is 4.3, so the
upper bound was set to 5.0.0 )

<dependency>
   <groupId>org.eclipse.swt</groupId>
   <artifactId>org.eclipse.swt.win32.win32.x86</artifactId>
   <version>[3.2.0,5.0.0)</version>
   <scope>provided</scope>
</dependency>

-Marshall

Since this is a "provided" scope, only the API is being used, and it will work
with non-windows eclipse versions.