Re: Downloading from other Maven repositories was: Integrating with complex third-party software
On 30/10/17 20:02, Antonio Vieiro wrote: I’ll add this to PR#204. Let’s get this done ASAP. Ready for review. Let's find some nice maven repos to add to nbbuild/default-properties.xml#binary.repositories Cheers, Antonio
Re: Downloading from other Maven repositories was: Integrating with complex third-party software
> El 30 oct 2017, a las 20:47, Matthias Bläsing > escribió: > > Hey, > > Am Montag, den 30.10.2017, 20:02 +0100 schrieb Antonio Vieiro: On the other hand during review of HTML/Java API I had to remove download from google Maven repository - it was seen as untrusted. I assume the same will be said about the eclipse repository. >>> >>> I don't follow that argument. The trust basis is the SHA1 hash that is >>> checked at download time. At this point in time I consider SHA1 as a >>> save basis and thus I don't care if the binary comes from maven centra, >>> the eclipse repository or whatever. >> >> Untrusted because missing https certificates, maybe? >> >> The DownloadBinaries.java ant task currently uses plain http, so no worries >> about https certificates (but we could use a custom SSLSocketFactory with >> some certs if required). >> > > Please see the DownloadBinaries#doDownload method. The download is done > and after that the file hash is compared with the reference from the > binaries-list. I agree with you that the SHA1 is enough. I meant that maybe Yaroslav was talking about “untrusted HTTPS” connections. Cheers, Antonio > > So you'd need to create a SHA1 collision to inject code when > downloading. While theoretically possible, I'd currently not think > about the problem. > > We should think about making the hashing extendable, so that we can > later switch to saver hashing algorithms. > > Greetings > > Matthias
Re: Downloading from other Maven repositories was: Integrating with complex third-party software
Hey, Am Montag, den 30.10.2017, 20:02 +0100 schrieb Antonio Vieiro: > > > On the other hand during review of HTML/Java API I had to remove download > > > from google Maven repository - it was seen as untrusted. I assume the same > > > will be said about the eclipse repository. > > > > I don't follow that argument. The trust basis is the SHA1 hash that is > > checked at download time. At this point in time I consider SHA1 as a > > save basis and thus I don't care if the binary comes from maven centra, > > the eclipse repository or whatever. > > Untrusted because missing https certificates, maybe? > > The DownloadBinaries.java ant task currently uses plain http, so no worries > about https certificates (but we could use a custom SSLSocketFactory with > some certs if required). > Please see the DownloadBinaries#doDownload method. The download is done and after that the file hash is compared with the reference from the binaries-list. So you'd need to create a SHA1 collision to inject code when downloading. While theoretically possible, I'd currently not think about the problem. We should think about making the hashing extendable, so that we can later switch to saver hashing algorithms. Greetings Matthias
Re: Downloading from other Maven repositories was: Integrating with complex third-party software
> El 30 oct 2017, a las 18:35, Matthias Bläsing > escribió: > > Hey, > > Am Montag, den 30.10.2017, 13:58 +0100 schrieb Jaroslav Tulach: >> 2017-10-25 6:21 GMT+02:00 Antonio Vieiro : >> >>> >>> 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. >>> >> >> I was thinking about adding List repositories; attribute into the >> download task and then configure it to list as many Maven repositories as >> possible. The download would then try them one by one as regular Maven >> does. Then default.xml or some other file would register all the Maven >> repositories we need for the build. This should solve our issues >> temporarily. > > I think this idea is sound and it would be direction I would take. I > would not add complexity by adding a repository prefix. I’ll add this to PR#204. Let’s get this done ASAP. Later on we can fine-tune the downloads mechanism, using some sort of parallelization to speed things up. > >> On the other hand during review of HTML/Java API I had to remove download >> from google Maven repository - it was seen as untrusted. I assume the same >> will be said about the eclipse repository. > > I don't follow that argument. The trust basis is the SHA1 hash that is > checked at download time. At this point in time I consider SHA1 as a > save basis and thus I don't care if the binary comes from maven centra, > the eclipse repository or whatever. Untrusted because missing https certificates, maybe? The DownloadBinaries.java ant task currently uses plain http, so no worries about https certificates (but we could use a custom SSLSocketFactory with some certs if required). Cheers, Antonio
Re: Downloading from other Maven repositories was: Integrating with complex third-party software
Hey, Am Montag, den 30.10.2017, 13:58 +0100 schrieb Jaroslav Tulach: > 2017-10-25 6:21 GMT+02:00 Antonio Vieiro : > > > > > 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. > > > > I was thinking about adding List repositories; attribute into the > download task and then configure it to list as many Maven repositories as > possible. The download would then try them one by one as regular Maven > does. Then default.xml or some other file would register all the Maven > repositories we need for the build. This should solve our issues > temporarily. I think this idea is sound and it would be direction I would take. I would not add complexity by adding a repository prefix. > On the other hand during review of HTML/Java API I had to remove download > from google Maven repository - it was seen as untrusted. I assume the same > will be said about the eclipse repository. I don't follow that argument. The trust basis is the SHA1 hash that is checked at download time. At this point in time I consider SHA1 as a save basis and thus I don't care if the binary comes from maven centra, the eclipse repository or whatever. There are reasons to limit the trusted repositories: - reduce attack vectors - improve download persformance So I'd like to hear reasonable objections to this. Greetings Matthias
Downloading from other Maven repositories was: Integrating with complex third-party software
2017-10-25 6:21 GMT+02:00 Antonio Vieiro : > > 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. > I was thinking about adding List repositories; attribute into the download task and then configure it to list as many Maven repositories as possible. The download would then try them one by one as regular Maven does. Then default.xml or some other file would register all the Maven repositories we need for the build. This should solve our issues temporarily. On the other hand during review of HTML/Java API I had to remove download from google Maven repository - it was seen as untrusted. I assume the same will be said about the eclipse repository. -jt
Re: Eclipse binaries (was Re: Integrating with complex third-party software)
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 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 wildfl
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 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 upg
equinox (was Re: Integrating with complex third-party software)
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 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
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 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
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
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
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).
