| Summary: | buckminster fails to find bundle in update site | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Nicolas Bros <nicolas.bros> |
| Component: | Buckminster | Assignee: | buckminster.core-inbox <buckminster.core-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | thomas |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Nicolas Bros
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 ... Perhaps you could try and use the "Buckminster 3.6 Integration" builder in your Hudson job. That's the one I'm using. 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? (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? Sorry, I was looking at the wrong build log. In fact, it does work with "Buckminster 3.6 Integration". Thank you for your help! 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. *** Bug 322882 has been marked as a duplicate of this bug. *** 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. |