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 Vieiro <an...@vieiro.net> on 2017/10/24 17:35:02 UTC
Integrating with complex third-party software
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.
I imagine this also applies to all “o.eclipse.equinox.*”, maybe we want to upgrade all binaries matching a given Eclipse release.
Do you think we should match a given Eclipse release or is all this unnecessary?
Thanks,
Antonio
P.S.: I’ll try to find out which versions of different binaries correspond to a given Eclipse release (maybe we can find a POM/BOM somewhere at Eclipse’s Nexus).
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
>>>
Eclipse binaries (was Re: Integrating with complex third-party
software)
Posted by Antonio <an...@vieiro.net>.
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
>>
equinox (was Re: Integrating with complex third-party software)
Posted by Antonio <an...@vieiro.net>.
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 <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: Integrating with complex third-party software
Posted by Antonio Vieiro <an...@vieiro.net>.
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: Integrating with complex third-party software
Posted by Antonio <an...@vieiro.net>.
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: Integrating with complex third-party software
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
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