Bugzilla – Full Text Bug Listing
| Summary: | Galileo build fails with missing cvs feature repo, or quietly | ||
|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> |
| Component: | Cross-Project | Assignee: | Cross-Project issues <cross-project.inbox> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | alex.panchenko, andrey, kim.moir, thomas |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
|
Description
David Williams
I just added the repo to the ep.build file I think the following attribute needs to be added to each feature, too. repo="//@repositories.0" But, even doing that, in my local build, it still fails silently. I did just notice the silent fail seems to happen right while adding the artifact repository for dltk. Would this happen if there was some "contradiction" with the platform's repository? Remember, it does get past this point, but by omitting the platform repo. Adding dltk contacts to CC in case anything rings a bell. You all build/pre-req 3.5 M6, right? Adding child meta-data repository http://download.eclipse.org/technology/jwt/update-site/ Adding child artifact repository http://download.eclipse.org/technology/jwt/update-site/ Adding child meta-data repository http://download.eclipse.org/technology/jwt/stable-update-site/ Adding child artifact repository http://download.eclipse.org/technology/jwt/stable-update-site/ Adding child meta-data repository http://download.eclipse.org/technology/dltk/updates-dev/1.0-stable/ (In reply to comment #2) > I think the following attribute needs to be added to each feature, too. > > repo="//@repositories.0" > No, this is not needed for the EP contribution. In fact, it would be incorrect to add it at this point since its likely to crash the old builder (it would then mirror the platform too). That's why the EP repository is passed as an option on the command line. Once the old builder is out of the way, the EP contribution should look just like any other and indeed provide a repo that matches its features. The new builder is already ready for this. But for now, it's up to the build master to make the right choice and pass that repo on the command line. (In reply to comment #3) > (In reply to comment #2) > > I think the following attribute needs to be added to each feature, too. > > > > repo="//@repositories.0" > > > No, this is not needed for the EP contribution. In fact, it would be incorrect > to add it at this point since its likely to crash the old builder (it would > then mirror the platform too). That's why the EP repository is passed as an > option on the command line. > > Once the old builder is out of the way, the EP contribution should look just > like any other and indeed provide a repo that matches its features. The new > builder is already ready for this. But for now, it's up to the build master to > make the right choice and pass that repo on the command line. > Ok, so the "real" error here is more related to the cvs feature? Contains: Unable to find feature org.eclipse.cvs/1.1.100.v20090123-7E79FBV9BJ99r9JEV39Q8C using composite repository I do not actual see the EP repository in any of the composite repositories. removing the ep.build contents really helps things along though :) Is that how you get things to work? (In reply to comment #4) > removing the ep.build contents really helps things along though :) > Is that how you get things to work? > No, I never removed it. The EP contribution matched the M6 release until very recently. If it doesn't match that anymore, then that's a problem that needs to be fixed of course. The EP contribution is essential and it must match some repository. The builder requires that this repository is provided, either as a command line option, or as a repository in the EP contribution. I much prefer the latter since that makes the responsibility very clear. But, as I mentioned, it will probably break the old builder. (In reply to comment #5) > (In reply to comment #4) > ... The EP contribution matched the M6 release until very > recently. If it doesn't match that anymore, then that's a problem that needs to > be fixed of course. > Hmmm, I just installed (only) the Platform runtime binary, added the milestone update site to "install new software", and from there could only see "Eclipse SDK" and "Platform SDK". I know the actual cvs feature is on the update site ... but, maybe the artifacts.xml file is not fully populated? Kim, I think in your court now? Not sure how Thomas can "see" (fetch) this feature ... suspect he's just working with a cache? Which platform do you use, Thomas ... linux? If so, maybe I'll switch ... sure is getting old not being able to run this builder. Also, I tried removing all from ep.build contribution _except_ for Eclipse SDK ... which seemed ok, things seemed to work longer, but eventually got an error that said "gef features requires eclipse.ui bundle, but couldn't find it" (or similar) so not sure it's just an issue with the CVS feature. We don't have categories defined in the metadata for the cvs features. The only ones that are there are the platform, platform sdk, releng, tools, and agent I think. Perhaps I should change the submission to Galileo to only include the sdk. The rest of the features are included in the sdk so this would take care of it. I think our submission looks like it does because it that was what it looked like for Ganymede which used a different build system. Note that the metadata does reflect the cvs feature, but just doesn't have a category. (In reply to comment #7) > We don't have categories defined in the metadata for the cvs features. ... Doh ... I tried again, unchecked "categorized" and could then see it. Only there, it showed up as named "CVS Client" with an ID of org.eclipse.cvs.feature.group I assume that's the same thing. Perhaps that id is what needs to be changed in ep.build file. I'll give it a try locally. I personally think it's nice to have separate. The other "separate" things there are org.eclipse.pde, org.eclipse.jdt, and org.eclipse.equinox.p2.user.ui. I suspect they all might have "group" IDs? feature.group didn't help ... but now, all of a sudden it started working with original names ... come on, did you change something? I must have had a typo or something. Sorry for the noise. (In reply to comment #6) > Not sure how Thomas can "see" (fetch) this feature ... suspect he's just > working with a cache? > No cache. I'm using a P2 InstallableUnitQuery. It doesn't care about the type of IU's that it finds, nor how they are categorized. The special handling of categories is enforced in the UI only. > Which platform do you use, Thomas ... linux? If so, maybe > I'll switch ... sure is getting old not being able to run this builder. > I'm on Linux. But it's I who must switch, or at least test on Windows too. |