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

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

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

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,

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

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

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 +-

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

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

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

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