Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 322506 - buckminster fails to find bundle in update site
Summary: buckminster fails to find bundle in update site
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Buckminster (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: buckminster.core-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 322882 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-08-12 07:26 EDT by Nicolas Bros CLA
Modified: 2019-02-25 14:41 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Bros CLA 2010-08-12 07:26:09 EDT
Buckminster failed to find bundle "org.eclipse.emf.compare" in update site http://download.eclipse.org/modeling/emf/updates/milestones/.
This update site seems to use the old format (site.xml).

If I explore this update site, I see that the bundle is here.

The releng project:
http://dev.eclipse.org/viewsvn/index.cgi/releng/trunk/org.eclipse.gmt.modisco.releng.buckminster/?root=Modeling_MODISCO&pathrev=2676

The build log:
https://build.eclipse.org/hudson/job/modisco-integration/57/console
Comment 1 Thomas Hallgren CLA 2010-08-12 09:16:00 EDT
I cannot reproduce the problem. I tried with the rmap that you mentioned and also with the rmap from branches/0_8_0 (I think that is the one used in the build from the log). The org.eclipse.emf.compare is found in two repositories:

Using 0_8_0
org.eclipse.emf.compare:osgi.bundle: Trying provider p2(http://download.eclipse.org/modeling/emf/updates/milestones/[http://download.eclipse.org/modeling/emf/updates/milestones/])
org.eclipse.emf.compare:osgi.bundle: Found match 1.1.1.v201008110652
...
org.eclipse.emf.compare:osgi.bundle: Trying provider p2(http://download.eclipse.org/releases/helios[http://download.eclipse.org/releases/helios])
org.eclipse.emf.compare:osgi.bundle: Found match 1.1.0.v201006150400
...

Using trunk, it's also found in two repositories.
org.eclipse.emf.compare:osgi.bundle: Trying provider p2(http://download.eclipse.org/modeling/emf/updates/releases/[http://download.eclipse.org/modeling/emf/updates/releases/])
org.eclipse.emf.compare:osgi.bundle: Found match 1.1.0.v201006150400
...
org.eclipse.emf.compare:osgi.bundle: Trying provider p2(http://download.eclipse.org/modeling/emf/updates/milestones/[http://download.eclipse.org/modeling/emf/updates/milestones/])
org.eclipse.emf.compare:osgi.bundle: Found match 1.1.1.v201008110652
...
Comment 2 Thomas Hallgren CLA 2010-08-12 09:21:22 EDT
Perhaps you could try and use the "Buckminster 3.6 Integration" builder in your Hudson job. That's the one I'm using.
Comment 3 Nicolas Bros CLA 2010-08-12 09:45:21 EDT
Yes, the problem is on branch 0_8_0. On trunk, it works as expected.
I tried with "Buckminster 3.6 Integration", but it didn't change anything.

This error started happening when I changed the rmap, replacing
"http://download.eclipse.org/modeling/emf/updates/releases/" by "http://download.eclipse.org/modeling/emf/updates/milestones/" and
"http://download.eclipse.org/modeling/m2t/updates/releases/" by "http://download.eclipse.org/modeling/m2t/updates/milestones/".

I am new to Buckminster, so it is very possible that I made a mistake in the configuration.
Since apparently the rmap is okay, what else do you think could be wrong?
Comment 4 Thomas Hallgren CLA 2010-08-12 09:50:42 EDT
(In reply to comment #3)
> Since apparently the rmap is okay, what else do you think could be wrong?

 I'm suspecting that you may have a cached but damaged copy of something. Does your build start from scratch each time? I.e. does it create a new workspace and new target platform?

Can you reproduce the error locally?
Comment 5 Nicolas Bros CLA 2010-08-12 10:01:23 EDT
Sorry, I was looking at the wrong build log.
In fact, it does work with "Buckminster 3.6 Integration".
Thank you for your help!
Comment 6 Thomas Hallgren CLA 2010-08-17 11:40:15 EDT
I'm reopening this one based on new findings.

If the Buckminster p2 reader type encounters a legacy site such as:

http://download.eclipse.org/modeling/emf/updates/milestones/

then p2 will do a best effort to produce p2 repository meta-data out of this site. It does this by downloading all features, but no bundles. It extracts the information from all feature.xml files that it finds and creates "partial IU's" for the bundles. The reason for this is that it would take far too long to also download the bundles and investigate their content in order to do proper discovery of the bundle dependencies.

The consequence is that a bundle that is downloaded from a legacy site has no dependencies and hence, no traversal will be performed from that point. The same thing is true for Buckminster in this case. In order to continue, it must first download the bundle and perform discovery on it. This would be possible and the performance hit would be bearable since it's likely that the bundle in question will be materialized anyway.
Comment 7 Thomas Hallgren CLA 2010-08-17 11:42:02 EDT
*** Bug 322882 has been marked as a duplicate of this bug. ***
Comment 8 Thomas Hallgren CLA 2010-08-17 13:34:52 EDT
I added a check for partial IU's. When they are encountered, they are now mirrored into a repository maintained by Buckminster (in the core bundle state location). The bundle is then examined and proper meta-data is created. Once materialized, the bundle will be found in the local repository and hence, not downloaded twice.

Fix released to helios-maintenance branch, rev 11555.