Bugzilla – Full Text Bug Listing
| Summary: | was settings.xml introduced redirecting dependencies to maven.eclipse.org ? | ||
|---|---|---|---|
| Product: | Community | Reporter: | Matthias Sohn <matthias.sohn> |
| Component: | CI-Jenkins | Assignee: | David Carver <d_a_carver> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | denis.roy, d_a_carver, gunnar, kaloyan, mober.at+eclipse, mtaal, steffen.pingel |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
|
Description
Matthias Sohn
This is likely also causing Virgo IDE Tooling builds to fail: https://hudson.eclipse.org/hudson/job/virgo.ide.snapshot/78/console [INFO] Adding repository http://dist.springframework.org/snapshot/IDE/nightly/ [WARNING] Failed to access p2 repository springide (http://dist.springframework.org/snapshot/IDE/nightly/), will try to use local cache. Reason: org.eclipse.equinox.p2.core.ProvisionException: Communication with repository at http://dist.springframework.org/snapshot/IDE/nightly/ failed. And I guess that this is related to issues I have myself with building 2 modeling projects (EMF Teneo and EMFT Texo). Remote download locations for dependencies are not working anymore.
I get:
[java] ERROR [0002] : Rejecting provider p2(http://www.elver.org/eclipse/update[http://www.elver.org/eclipse/update]): No component match was found
[java] ERROR No repository found at http://www.elver.org/eclipse/update/.
I filed that as issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350992
gr. Martin
Hi, FYI, I set the instance to run the build to fastlane and this worked for me to get the builds running. gr. Martin Re comment 1 and comment 2: AFAIK there is some proxy in place which prevents "remote" downloads from builds. Frankly, "remote dependency" are also problematic from a legal point of view. All dependencies need to be IP reviewed and placed on Eclipse.org infrastructure. I think comment 0 is different, though. It's not a dependency required for EGit but a plug-in of the build technology. (In reply to comment #4) > Re comment 1 and comment 2: > AFAIK there is some proxy in place which prevents "remote" downloads from > builds. Frankly, "remote dependency" are also problematic from a legal point of > view. All dependencies need to be IP reviewed and placed on Eclipse.org > infrastructure. > > I think comment 0 is different, though. It's not a dependency required for EGit > but a plug-in of the build technology. exactly, I filed bug 351138 to get this version of the signing plugin deployed on maven.eclipse.org. The 1.0.1 version currently available there has some bugs which are fixed in the newer 1.0.1.2-SNAPSHOT version available from the intalio repository only. I had changed the maven settings.xml as part of bug 345792 .. it solved problems on the Mac slave, but apparently it is causing problems on the regular slaves. I've reverted it. (In reply to comment #6) > I had changed the maven settings.xml as part of bug 345792 .. it solved > problems on the Mac slave, but apparently it is causing problems on the regular > slaves. > > I've reverted it. What we need to do is add the Spring maven repositories to the Nexus repo. If there is anybody that is accessing other maven repositories besides the ones that are on central, please post them to this list, and I'll have maven.eclipse.org proxy these requests. We want to start to make sure that we use maven.eclipse.org, and it may take a few tries to get the settings setup correctly. Please also include the repository id that is being used to identify the repository, as this way we can make sure it redirects correctly. (In reply to comment #6) > I had changed the maven settings.xml as part of bug 345792 .. it solved > problems on the Mac slave, but apparently it is causing problems on the regular > slaves. > > I've reverted it. Could you announce such changes which potentially affect many projects on the cross list ? This would simplify problem analysis. Yep, will do that going forward. It's always the items that you don't think will cause issues, that end up causing issues. (In reply to comment #10) > Yep, will do that going forward. It's always the items that you don't think > will cause issues, that end up causing issues. I think global settings.xml should be visible to everybody, where is this versioned ? Probably it would be a good idea to review changes publicly on cross list before they get used so that all projects have a chance to raise concerns. (In reply to comment #11) > (In reply to comment #10) > > Yep, will do that going forward. It's always the items that you don't think > > will cause issues, that end up causing issues. > > I think global settings.xml should be visible to everybody, where is this > versioned ? Probably it would be a good idea to review changes publicly on > cross list before they get used so that all projects have a chance to raise > concerns. It is version here: http://git.eclipse.org/c/dash/org.eclipse.dash.maven.git/ There is a global settings.xml file there, that we can update to make it the recommended one to use as a template. Any settings.xml would have to be installed by the web masters. So they have final control on when it gets updated on the Hudson servers. maven.eclipse.org doesn't exist anymore, so I think this bug can go away. |