You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Antonio <an...@vieiro.net> on 2017/10/27 05:55:30 UTC
Eclipse binaries (was Re: Integrating with complex third-party
software)
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 <an...@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
>>
Re: Eclipse binaries (was Re: Integrating with complex third-party
software)
Posted by Antonio <an...@vieiro.net>.
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 <an...@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
>>>