Long story short: Eclipse is currently working in publishing to Maven central ([1], [2]). They’ve released some preliminar tests in Maven central as of 2017/10/17 ([3, 4]), this is, a few days back.
(Their target milestone for this is 4.6.2, but they’re currently @ 4.7, so I imagine they’re late). The good news is that they use version ranges for many artifacts. For instance, o.eclipse.core.runtime binary (see [4]) depends on org.eclipse.platform:org.eclipse.osgi [3.7.0,4.0.0). In the following days I’ll try to enumerate all eclipse binary ranges (as recently published by them in Maven central) and compare those with the versions of our binaries, to see if we’re depending on a compatible version set. I think it would be a good idea if we upgrade all our eclipse binary dependencies to match their, say, 4.7 release? I was wondering we could upgrade the “download task” in nbbuild to automatically select binary versions for eclipse binaries, so, for instance, our binaries-list could be something like: eclipse://4.7/org.eclipse.core.jobs And leave the responsibility of choosing (verifying) an appropriate version of “org.eclipse.core.jobs” to the download task. Opinions? Too complicated? Should we leave this for later on? Thanks, Antonio [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=510072 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=484004 [3] http://repo1.maven.org/maven2/org/eclipse/platform/org.eclipse.core.runtime/3.13.0/ [4] http://repo1.maven.org/maven2/org/eclipse/platform/org.eclipse.core.runtime/3.13.0/org.eclipse.core.runtime-3.13.0.pom > El 24 oct 2017, a las 22:42, Antonio <anto...@vieiro.net> escribió: > > Hi, > > I've been trying to find something similar to Wildfly BOMs [1] in the eclipse > nexus repository without success. Maybe they don't have them. I'd like to see > a well defined set of module versions (o.eclipse.core.net X.Y.Z, > o.eclipse.core.runtime A.B.C, etc.), that are tested to work together. I'll > keep trying. > > I think NetBeans should also provide these BOMs for different releases, so > you could include the "NetBeans 8.2 Platform BOM", or the "NetBeans 9.1 > Platform BOM" in your project and forget about individual module versions. > Something to think about in the future. > > I'll keep you posted of my findings. > > Cheers, > Antonio > > [1] https://github.com/wildfly/boms > > For wildfly-javaee7-10.0.1 > https://github.com/wildfly/boms/blob/wildfly-javaee7-10.0.1.Final/pom.xml > > For wildfly-javaee7-9,0.1 > https://github.com/wildfly/boms/blob/jboss-javaee-7.0-wildfly-9.0.1.Final/pom.xml > > > On 24/10/17 21:30, Matthias Bläsing wrote: >> Hey, >> Am Dienstag, den 24.10.2017, 19:35 +0200 schrieb Antonio Vieiro: >>> I’m currently reviewing one of the “o.eclipse.core.*” modules and I >>> can’t find a binary, so I should either upgrade or downgrade it. >>> >>> I was wondering if we should either upgrade or downgrade the binaries >>> of _all_ of the “o.eclipse.core.*” modules at once. In order to avoid >>> subtle bugs that may arise if we choose versions coming from >>> different Eclipse releases. >> there was some talk, that eclipse hosts its artifacts in its own >> repository (Emilian raised that already): >> https://repo.eclipse.org/content/groups/releases/ >> They obviously setup a nexus instance for themselves: >> https://repo.eclipse.org/ >> The solution could be, that the DownloadBinaries task is modified to >> fetch binaries from multiple maven repositories. >> What do the others think? >> Greetings >> Matthias
