netbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio <>
Subject equinox (was Re: Integrating with complex third-party software)
Date Wed, 25 Oct 2017 22:47:29 GMT
Hi all,

So I created a small Bill-Of-Materials (BOM) Maven project for Eclipse 
Equinox at [1], with the latest packages from Eclipse at maven central 
(mid october).

There's also a simple NBDEPS project that uses the BOM. Running a mvn 
dependency:tree on the NBDEPS project suggests the following versions:

org.eclipse.equinox.common:jar:3.9.0:provided (version selected from 
constraint [3.2.0,4.0.0))
org.eclipse.equinox.registry:jar:3.7.0:provided (version selected from 
constraint [3.4.0,4.0.0))

(The BOM has only three dependencies, the other two: common & registry 
are computed by Maven).

We could choose those versions in our o.eclipse.equinox.* modules, right?

Unless someone reasonable stops me, I'll try to find out suggested 
versions for binaries affecting our o.eclipse.core* and 
o.eclipse.mylyn.* modules.



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/
> And leave the responsibility of choosing (verifying) an appropriate version of “”
to the download task.
> Opinions? Too complicated? Should we leave this for later on?
> Thanks,
> Antonio
> [1]
> [2]
> [3]
> [4]
>> El 24 oct 2017, a las 22:42, Antonio <> 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 ( 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]
>> For wildfly-javaee7-10.0.1
>> For wildfly-javaee7-9,0.1
>> 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):
>>> They obviously setup a nexus instance for themselves:
>>> The solution could be, that the DownloadBinaries task is modified to
>>> fetch binaries from multiple maven repositories.
>>> What do the others think?
>>> Greetings
>>> Matthias

View raw message