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 <[email protected]> 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
