Of interest:
Remove org.eclipse.core.runtime.compatibility* bundles
https://bugs.eclipse.org/bugs/show_bug.cgi?id=394739
It seems these were removed around 2016. Maybe we can get rid of these
modules and keep the rest of binaries which are available in Maven Central.
Cheers,
Antonio
On 27/10/17 07:55, Antonio wrote:
Hi all,
I'm trying to find a coherent subset of Eclipse binaries. It's
difficult. I've built some sample BOMs for org.eclipse.equinox.* and
org.eclipse.core.* at [1].
The resulting dependencies are:
org.apache.netbeans:NBDEPS:jar:1.0-SNAPSHOT
+- org.eclipse.platform:org.eclipse.equinox.preferences:jar:3.7.0:provided
| \- org.eclipse.platform:org.eclipse.equinox.common:jar:3.9.0:provided
(version selected from constraint [3.2.0,4.0.0))
+- org.eclipse.platform:org.eclipse.equinox.security:jar:1.2.300:provided
+- org.eclipse.platform:org.eclipse.equinox.app:jar:1.3.400:provided
| \-
org.eclipse.platform:org.eclipse.equinox.registry:jar:3.7.0:provided
(version selected from constraint [3.4.0,4.0.0))
+- org.eclipse.platform:org.eclipse.core.contenttype:jar:3.6.0:provided
+- org.eclipse.platform:org.eclipse.core.jobs:jar:3.9.0:provided
+- org.eclipse.platform:org.eclipse.core.net:jar:1.3.100:provided
| \- org.eclipse.platform:org.eclipse.osgi:jar:3.12.0:provided (version
selected from constraint [3.4.0,))
+- org.eclipse.platform:org.eclipse.core.runtime:jar:3.13.0:provided
\-
org.eclipse.core:org.eclipse.core.runtime.compatibility.auth:jar:3.2.200.v20100517:provided
\-
org.eclipse.equinox:org.eclipse.equinox.common:jar:3.6.0.v20100503:provided
\- org.eclipse.osgi:org.eclipse.osgi:jar:3.6.0.v20100517:provided
Note that this subset of Eclipse binaries span different NetBeans
modules (netbinox, o.eclipse.equinox.*, o.eclipse.core.runtime.*)
The main problem is that o.eclipse.core.runtime.compatibility.auth
3.2.200 is very old and requires special (old) versions of
org.eclipse.equinox.common (3.6.0) and org.eclipse.osgi (3.6.0). I'll
try to find a recent version of this and try to make it work with the
more recent Eclipse versions.
I think the rest of dependencies are a coherent subset of eclipse binary
versions available in Maven central, and we could try to upgrade to them.
I'll try to take a look at mylyn binary versions (binaries are
unavailable as reported in our "List of Modules to Review"). Will keep
you posted in my findings.
Cheers,
Antonio
[1] https://github.com/vieiro/nbdeps
On 25/10/17 06:21, Antonio Vieiro wrote:
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 <[email protected]> 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
