Issues with building Eclipse Plugins

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

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

Re: Issues with building Eclipse Plugins

[Richard Eckart de Castilho <re...@apache.org>]

There's still a bunch of dependencies used by Ruta which are currently obtained
from the UKP public Maven repository.

It would be good if we would upload all bundles that require to Maven Central.
There is a project which allows to expose a OSGi repository as a Maven Repository [1].

It might work to point that at a local Eclipse which contains all the bundles
that we need, then crawl them, and then upload them to Maven Central.

Didn't try it yet.

-- Richard

[1] http://code.google.com/p/maven-osgi-repo/

On 18.12.2013, at 21:13, Marshall Schor <ms...@schor.com> wrote:

> 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