Hi,
I recently set about to look into upgrading the JCasGen "codemerge" facility,
based on Eclipse's EMF's codegen. The old versions of this were based on the
"JDOM" representation of Java source code. The newer (since EMF 2.2.0?)
(several years ago) version switched to being based on the AST (Abstract Syntax
Tree) representation of Java source code.
The new version of Codegen in EMF supports Java 5 (and later?), the old doesn't.
In preparation for investigating this, I thought the JCasgen project would need
to depend on more modern versions of EMF. But there are no stable, public Maven
repos for this stuff.
The dependencies are used in 2 places in the build:
1) in Compiling - they serve to satisfy imports
2) in building the bundles - the "bnd" uses these (I think) to find out how
to set up the package imports needed for the bundle.
The web suggested using the mvn goal:
mvn eclipse:to-maven -DeclipseDir=xxxxxx -DstripQualifier=true
to populate your local .m2 repo with the jars and generated poms from my Eclipse
installation (kepler 4.3.1); this seemed to work fine.
This resulted in my .m2 repo having 2 versions of many eclipse jars: a recent
one (based on kepler 4.3.1), and a very old one (perhaps based on Eclipse 3.2?).
I was not too surprised when my maven build of uimaj eclipse plugins failed.
What seemed to happen was that more recent versions of Jars (packages) were
picked up by some dependencies which had versions written like [3.3.0.0,4.0.0),
which, in turn, needed other versions of jars which were not in my .m2 repo.
My .m2 was missing the levels in-between my very old version and the 4.3.1
version. So I would get some kind of dependency chain which ended up resolving
to some version which was in between these two levels. Maven would create a
directory for this version in my .m2 repo, but only populate it with files
ending in ".lastUpdated", which reflected the last date when it tried and failed
to fetch that level in any Maven repo.
To work around these, I did a hack (which worked, but is not recommended): I
wrote a small program that went through the .m2 repo in the org.eclipse subtree
(and, it turns out, some org.w3c things), and looked for directories which were
missing the jars but had the .lastUpdated files. Then it would go find some
sibling directory which did have the jars, pick a closest named version (in case
there were multiples) and copy / rename the jars and pom (if it was missing
too). These siblings were from a different "version" than the one being copied
into, so the renaming faked the version to be the expected one.
With this fix, I got the whole uimaj (all the plugins) to compile once again.
All of these dependencies (on Eclipse things) are "provided for" and supplied by
Eclipse when you run these plugins (bundles) in the Eclipse framework OSGi
world.
The jars themselves are only used by Maven builds (as far as I can tell) to
resolve imports during compile, and to construct the OSGi bundle manifest.
So, there's a chance that building this way will generate working Eclipse
plugins.
But I admit, it seems somewhat shaky. I'm looking for a better approach that
would enable me to upgrade the JCasGen plugin based on more recent versions of
EMF... Any suggestions would be much appreciated!
-Marshall
