Bugzilla – Full Text Bug Listing
| Summary: | [build] galileo build can't find buckminster feature | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | David Williams <david_williams> | ||||||||
| Component: | Cross-Project | Assignee: | Cross-Project issues <cross-project.inbox> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | aniefer, simon_kaegi, thomas | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | 267282 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
David Williams
Created attachment 129860 [details]
one log from attempt at local build
Rich, can you tell anything from the attached log? Have I set up something wrong? This is running as an M6 based "batch build", not from dev. env. Please move to more specific project, if you can see what the problem is, and if not, feel free to assign back to me. Well, it seems to have installed OK, but then apparently is not found in the base. Perhaps a metadata update misfire that for some reason didn't throw an exception? I'll try to run another local build here to look at the state of the repo. Created attachment 129919 [details]
similar log from build.eclipse.org build
apparently not just on my local machine
(In reply to comment #3) > Well, it seems to have installed OK... Then again, looking at the latest log and build directory, it seems as though the install operation is completing, the feature directory in the base does not agree. There are no buckminster feature directories at all present, though the log indicates that the first ones are installed. I'll attach latest log from build.eclipse.org. It implies it can not find a buckminster feature: Missing feature org.eclipse.buckminster.cvs.feature. It does not appear in the map file nor in the base location. But, looking at the build machine, I do see org.eclipse.buckminster.cvs.feature_1.0.0.r09930.jar in /shared/galileo/build/galileo/base/eclipse/features So, I'm not sure what the exact issue is. Could it be a P2 bug? Could the buckminster.cvs.feature have the wrong ID inside of it? Created attachment 130239 [details] log from latest Galileo run This was the result after removing the reina feature, due to bug 270368. Now I'll try removing buckminster features to see if everything (anything) else installs. (In reply to comment #6) > So, I'm not sure what the exact issue is. Could it be a P2 bug? Could the > buckminster.cvs.feature have the wrong ID inside of it? > I've run some tests: First I made a attempt to install the buckminster core and cvs features into a fresh Eclipse IDE from our updates-ganymede site. That was succesful. This Eclipse IDE was however fairly recent (March 23) so I made a renewed attempt with an older, pre M6 IDE. That failed. It says that the repository is not found. I peeked at the header of our repository and I find this: <?metadataRepository version='1.1.0'?> Looking into the repository at releases/galileo I find this: <?metadataRepository class='org.eclipse.equinox.internal.p2.metadata.repository.LocalMetadataRepository' version='1.0.0'?> So perhaps the issue at hand is that the Galileo build system is older then the system we use for publishing and hence, is incapable of reading the repository that we produce? What meta-data version can Galileo use at present? The change from 1.0.0 to 1.1.0 should be a compatible change for old clients to read. (In reply to comment #8) > (In reply to comment #6) > > What meta-data version can Galileo use at present? > To be honest, I do not know the answer to this question. It is using M6 as the base, is all I know. OK, so where do that leave us? I can install all Buckminster features into an Eclipse IDE of version 3.5M6 so obviously the features both present and in good shape. I have checked an double checked that the versions are the same as in our buckminster.build file. Any ideas of what to do next? (In reply to comment #11) > OK, so where do that leave us? I can install all Buckminster features into an > Eclipse IDE of version 3.5M6 so obviously the features both present and in good > shape. I have checked an double checked that the versions are the same as in > our buckminster.build file. > > Any ideas of what to do next? > Not really. I noticed you changed your build file today, at 11 AM, to use http://download.eclipse.org/tools/buckminster/updates-galileo/ instead of a "ganymede" site. Think that'll do it? That might explain a lot. (In reply to comment #12) > Not really. I noticed you changed your build file today, at 11 AM, to use > http://download.eclipse.org/tools/buckminster/updates-galileo/ > instead of a "ganymede" site. > Think that'll do it? That might explain a lot. > No, I don't think that changes anything since I also changed the location of the update site. It appointed the correct bits before too. Looking at the logs attached to this bugzilla I can see that the features are indeed installed correctly by the director app (from our updates-ganymede site referenced earlier). It is the subsequent call to genericTargets.xml that fails on line 46. So the director finds the feature (with correct version) and installs it without errors. Just like my M6 IDE does. The fact that I made a galileo copy of the site yesterday should not matter. As I suspected! Scanning the build log from Build #192 (Apr 1, 2009 5:04:12 PM), the builder still mysteriously fails to find the Buckminster cvs feature *after* it has been successfully installed by the director. What is it that the builder tries to do at this stage? Could it be that it fails on something that is completely unrelated to Buckminster? (In reply to comment #15) > As I suspected! Scanning the build log from Build #192 (Apr 1, 2009 5:04:12 > PM), the builder still mysteriously fails to find the Buckminster cvs feature > *after* it has been successfully installed by the director. > > What is it that the builder tries to do at this stage? Could it be that it > fails on something that is completely unrelated to Buckminster? > I agree. It appears all the "director" steps are finished, for all features, and the Rich-o-matic is trying to start a "product build"? -application org.eclipse.ant.core.antRunner -buildfile /shared/galileo/build/galileo/basebuilder/eclipse/plugins/org.eclipse.pde.build_3.5.0.v20090312-1500/scripts/productBuild/productBuild.xml I know next to nothing about "product builds", but wonder if there's some basic parameter missing ... such as -builddirectory? I found something that might be the cause of this. When the Buckminster features are installed, they end up as jars, not folders, under the features directory. We use the P2 publisher to create our meta-data and apparently this is a known bug. See bug #267282. Aside from being a jar instead of a folder, everything works as normal so I haven't really noticed this before. Could this be what's causing the errors? (In reply to comment #17) > I found something that might be the cause of this. When the Buckminster > features are installed, they end up as jars, not folders, under the features > directory. We use the P2 publisher to create our meta-data and apparently this > is a known bug. See bug #267282. Aside from being a jar instead of a folder, > everything works as normal so I haven't really noticed this before. > > Could this be what's causing the errors? > Could be ... the other features I see being installed (with director) are folders. I've removed buckminster to try again. I was expecting it to fail again, on what ever else is then first in the list thereby indicating the product build itself ... but, if it succeeds, then your theory will be our top candidate. The current test build will be done about 9 PM Eastern, give or take 2 or 3 hours :( So, hopefully you can have a new set to test with around that time? I built galileo locally and verified that the problem is solved if the features are unpacked. My guess is that the eclipse.fetch ant-task only looks for directories under the <baseLocation>/features directory. I'll try patching our build process so that correct touchpoints are generated. I'm a bit uncertain on what bits to publish. Are you still trying to assemble a working M6 or can I assume that the build now uses the latest I-build of the platform? I can do both but the question is relevant to us because we are dependent on changes in the provisional p2 api made post M6. (In reply to comment #19) > I built galileo locally and verified that the problem is solved if the features > are unpacked. My guess is that the eclipse.fetch ant-task only looks for > directories under the <baseLocation>/features directory. > > I'll try patching our build process so that correct touchpoints are generated. > > I'm a bit uncertain on what bits to publish. Are you still trying to assemble a > working M6 or can I assume that the build now uses the latest I-build of the > platform? I can do both but the question is relevant to us because we are > dependent on changes in the provisional p2 api made post M6. > Let's stay with strictly M6 for now. I'd like to change as little as possible until we get that working with all the projects that have something to contribute, then we'll move up. Ok, the build without buckminster succeeded, verify your theory. Let me know when you are ready for me to re-include buckminster. (And, if by chance it won't be for 4 or more hours, let me know that too, and I'll experiment with adding some other projects before that. Thank you very much. A published a new content.jar for our current M6 release (the one listed in buckminster.build). It contains the needed touchpoint datas. I tested it on a fresh M6 IDE and it installs correctly with unzipped features. Please include it in the next build. I spent 30 minutes looking at buckminster features trying to understand why the build failed when I re-added buckminster, then looked at the log closer, and saw it was not buckminster at all (but instead bug 271077) so I'm going to assume buckminster is all fixed now. You can bet I'll reopen if it happens again while trying to get a complete build :) Thanks for proactively tracking down this issue. (We'd be waiting a long time before I ever found an issue like you describe :) |