Mailing-List: contact dev-help@netbeans.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@netbeans.incubator.apache.org
Subject: equinox (was Re: Integrating with complex third-party software)
From: Antonio <antonio@vieiro.net>
To: dev@netbeans.incubator.apache.org
References: <E5D28FC9-A630-4C5C-8B95-65793445690B@vieiro.net>
 <1508873401.9216.7.camel@doppel-helix.eu>
 <539e9925-4dea-5f36-8d81-bc381eeb22ff@vieiro.net>
 <2C3A7892-0F66-424E-85C5-DB5D721E4BEF@vieiro.net>
Message-ID: <19624af1-1336-126a-d893-17f9c7a9147c@vieiro.net>
Date: Thu, 26 Oct 2017 00:47:29 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <2C3A7892-0F66-424E-85C5-DB5D721E4BEF@vieiro.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
archived-at: Wed, 25 Oct 2017 22:48:25 -0000

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.preferences:jar:3.7.0:provided
org.eclipse.equinox.common:jar:3.9.0:provided (version selected from 
constraint [3.2.0,4.0.0))
org.eclipse.equinox.security:jar:1.2.300:provided
org.eclipse.equinox.app:jar:1.3.400:provided
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.

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 <antonio@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
>