Bugzilla – Full Text Bug Listing
| Summary: | RCP example in the buckminster book does not produce a runnable result | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Peter Kullmann <peter.kullmann> |
| Component: | Buckminster | Assignee: | buckminster.core-inbox <buckminster.core-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | henrik.lindberg, milesparker, thomas |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Peter Kullmann
While working with the example, I was wondering why the developer.cquery has the advisor node not to consider the target platform: <cq:advisorNode namePattern=".*" useTargetPlatform="false"/> If one wants to add something (as was trying) it takes ages to re-resolve everything. I added the org.eclipse.equinox.executable feature to the product definition, re-resolved developer.cquery, re-created the site.p2 for the releng project and finally provisioned a app with the direcor as above and it created a runnable product. kup@ubuntu:~$ ls tmp/bmtutlinux/ about_files about.html artifacts.xml configuration launcher libcairo-swt.so mailapp mailapp.ini p2 plugins So, I think the example product should also include the org.eclipse.equinox.executable feature (I think the feature contains some root artifacts that are only produced if the feature is present but this is only a wild guess...) Now, here is my real problem: kup@ubuntu:~$ director/director -r file:///home/kup/bmtutorial/org.eclipse.buckminster.tutorial.mailapp.releng_1.0.0-eclipse.feature/site.p2/ -i org.eclipse.buckminster.tutorial.mailapp.product -d /home/kup/tmp/bmtutmac -p2.os macosx -p2.ws cocoa -p2.arch x86_64 Installing org.eclipse.buckminster.tutorial.mailapp.product 1.0.0. An error occurred while collecting items to be installed session context was:(profile=/home/kup/tmp/bmtutmac, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Collect, operand=, action=). No repository found containing: binary,org.eclipse.buckminster.tutorial.mailapp.product.executable.cocoa.macosx.x86_64,1.0.0 Application failed, log file location: /home/kup/director/configuration/1283530321911.log The example from the book does not work for any mac configurations. Comment #3 is no longer a concern. This was fixed with bug 323907 and buckminster pde feature version 11577. (In reply to comment #2) > I added the org.eclipse.equinox.executable feature to the product definition, > re-resolved developer.cquery, re-created the site.p2 for the releng project and > finally provisioned a app with the direcor as above and it created a runnable > product. > > kup@ubuntu:~$ ls tmp/bmtutlinux/ > about_files about.html artifacts.xml configuration launcher > libcairo-swt.so mailapp mailapp.ini p2 plugins > > So, I think the example product should also include the > org.eclipse.equinox.executable feature (I think the feature contains some root > artifacts that are only produced if the feature is present but this is only a > wild guess...) I need some confirmation regarding how it should be done, and if that is actually working before I know how to revise the information in the chapter in question. In the meanwhile, I included a reference to this issue in the documentation (at the start of the example). (In reply to comment #5) > I need some confirmation regarding how it should be done, and if that is > actually working before I know how to revise the information in the chapter in > question. In the meanwhile, I included a reference to this issue in the > documentation (at the start of the example). Hi guys, I'm a bit lost too. I've been trying to get an osx based build that used to work running, and went back and tried to get Ralf's example model running and hit the same issue. Right now I'm feeling pretty stuck as I think I've gone through everything obvious. What exactly is the recommendation? Henrik, are those updated docs available? Or any other ideas please? thanks, Miles Perhaps one of my issues is that I don't even see a org.eclipse.equinox.executable feature anywhere, not even in my deployed IDEs. Where are you getting this from, Peter? The equinox executable feature is a built time feature and is deliberately excluded from the result. The launchers that it contains should be included though. OK, thanks Thomas. I am making progress as with a bit more .target fiddling / rearranging I have a working build from my IDE -- I was afraid this might turn out to be an issue with Indigo M5 launchers but that seems ok. The Hudson->Jenkins build isn't there yet, but that "should" fall into place now. Still mysterious to me, though. (In reply to comment #9) > OK, thanks Thomas. I am making progress as with a bit more .target fiddling / > rearranging I have a working build from my IDE -- I was afraid this might turn > out to be an issue with Indigo M5 launchers but that seems ok. The > Hudson->Jenkins build isn't there yet, but that "should" fall into place now. > Still mysterious to me, though. FWIW, I've moved away from using .target definitions altogether. I find it much easier to just let Bucky provision the target platform while it provisions the workspace. The TP contains exactly what I want and it's dynamically adjusting. Not to mention that I get rid of some extra artifacts and calls. The flow I'm using is: 1. Do a setpref targetPlatformPath=<and empty directory> 2. Import a CQUERY (the RMAP has p2 readers set up for platform milestones and Indigo staging) 3. Build 4. Perform ... The import resolves all source using our svn/cvs readers and all target platform features/bundles using p2. All in one go. A side note: When building with Hudson at Eclipse.org, we use the prefix file:/home/data/httpd/download.eclipse.org/ for the p2 repositories so provisioning the TP is quite fast. (In reply to comment #10) > (In reply to comment #9) > > OK, thanks Thomas. I am making progress as with a bit more .target fiddling / > > rearranging I have a working build from my IDE -- I was afraid this might turn > > out to be an issue with Indigo M5 launchers but that seems ok. The > > Hudson->Jenkins build isn't there yet, but that "should" fall into place now. > > Still mysterious to me, though. > > FWIW, I've moved away from using .target definitions altogether. I find it much > easier to just let Bucky provision the target platform while it provisions the > workspace. The TP contains exactly what I want and it's dynamically adjusting. > Not to mention that I get rid of some extra artifacts and calls. > The flow I'm using is: > 1. Do a setpref targetPlatformPath=<and empty directory> > 2. Import a CQUERY (the RMAP has p2 readers set up for platform milestones and > Indigo staging) > 3. Build > 4. Perform ... Yes, I have too for the AMP p2 Eclipse hosted builds. I agree that it makes things way simpler at perhaps a little extra cost in server churning. And the very last thing I want to do is maintain *yet another* separate set of manually maintained dependencies -- after all, that's the whole point of using buckminster in the first place. The issue I'm running into with RCP builds is that without a well defined target platform, I have a hard time docking what's happening on the IDE side with what's happening in the Jenkins/Headless builds. And of course I need a target platform on the IDE side. IOTW, there doesn't seem to be a way to debug the provisioning step interactively. I've finally realized that trying to fix things by a) making changes locally, b) committing them, c) manually triggering a remote hudson build might not be the most efficient way to work through dependency issues. All of that server side churning means the longest edit-compile-debug cycle since punchcards, which I finally realized is why I've been able to measure my progress on build issues in weeks. ;) And naturally, all of the really opaque edge cases come up with RCP builds.. Is there some way to invoke hudson actions from the IDE without having it use the pre-existing workspace target platform? cheers, Miles (In reply to comment #11) > Is there some way to invoke hudson actions from the IDE without having it > use the pre-existing workspace target platform? > Not sure what you mean by this. I use the same TP provisioning mechanism in the IDE as I do when running headless. Here's what I usually do: 1. Create an empty, general project and call it TP. 2. Go to "Window" -> "Preferences" -> Plug-in Development" -> "Target Platform" 3. Create a new target platform and call it TP. It consists of one Directory. The Directory is set to ${workspace_loc:TP} 4. Make sure that this target platform is the active one. 5. Add properties that are normally passed on the command line as "Run/Debug" -> "String Substitution" preferences. 6. Open your CQUERY and click Resolve and Materialize. 7. Get some coffee... 8. Once the materialization completes, the workspace builds automatically. 9. Right click on the project containing the action that you want. Choose "Buckminster" -> "Invoke Action". In the dialog that opens, choose a property file and the action to perform. Note that once everything is materialized, you might want to refresh the TP project. You can then browse it and see exactly what was materialized and how it was unpacked (or not). A renewed Resolve and Materialize at some later point in time, will either be a no-op or add more bundles to the existing TP. (In reply to comment #12) > (In reply to comment #11) > > Is there some way to invoke hudson actions from the IDE without having it > > use the pre-existing workspace target platform? > > > Not sure what you mean by this. I use the same TP provisioning mechanism in the > IDE as I do when running headless. Here's what I usually do: > > 1. Create an empty, general project and call it TP. > 2. Go to "Window" -> "Preferences" -> Plug-in Development" -> "Target Platform" > 3. Create a new target platform and call it TP. It consists of one Directory. > The Directory is set to ${workspace_loc:TP} > 4. Make sure that this target platform is the active one. > 5. Add properties that are normally passed on the command line as "Run/Debug" > -> "String Substitution" preferences. > 6. Open your CQUERY and click Resolve and Materialize. > 7. Get some coffee... > 8. Once the materialization completes, the workspace builds automatically. > 9. Right click on the project containing the action that you want. Choose > "Buckminster" -> "Invoke Action". In the dialog that opens, choose a property > file and the action to perform. > > Note that once everything is materialized, you might want to refresh the TP > project. You can then browse it and see exactly what was materialized and how > it was unpacked (or not). A renewed Resolve and Materialize at some later point > in time, will either be a no-op or add more bundles to the existing TP. OK, that's what I was looking for, some way -- any way -- to align the IDE and the Jenkins build. What I'd been trying to do was provision a target platform by creating target platforms using software sites and hoping that I could somehow get them to match up, which of course they never did. So the second best semi-automated approach I could come up with was to work it the other way around: take the IDE target platform and try to use it with the Jenkins build, which is what lead me back to using the target platform based approach for RCP. I'm assuming that must be why the examples use it as well. But the real problem with that is that then you have to hope and pray that you have a target platform that will work with all of the issues for various build targets, etc..and you still have to maintain the thing afterwards. The piece that is new to me above is to use the target platform directory as opposed to trying to create a .target file and use that. I think it would make a lot of sense to think about some way to provide deeper IDE support for the above strategy. Joy! The key here was to be able to get something transparent that I could muck around with. So this is what I did:
Thomas' steps 1-9.
Now, as Peter say's for some reason we need to explicitly include that feature. So:
1. Manually add to your applications feature:
<includes
id="org.eclipse.equinox.executable"
version="0.0.0"/>
You can't use the PDE UI because of course it doesn't exist yet.
2. You will see an error in the feature.
3. Open site cquery and select "Resolve and Materialize"
4. Feature should now build.
5. Invoke site.p2, create.product..
One annoying peculiarity is that now I have an executable for both "MyApp" and the broken one for "Eclipse". Don't know if there is something that I've got setup wrong that leads to this, or if it is caused by manually having to add the equinox executable in.
WRT to 2, Buckminster bootstrapping necessarily adds some circularity to the process. OT, but when Buckminster is fully integrated into the Eclipse IDE and has taken over the PDE build process ;), it would be really neat to have some sort of discovery process:
1. In feature PDE UI, when you choose "Add.." it reads "select a feature from target platform" and there is an additional option for "find a feature from update site".
2. Using pieces from p2 UI, you then select an update site and choose the features you want.
3. That feature is then:
a) added to your feature, *and*
b) provisioned to the target platform, and
c) added to the buckminster rmap.
One can dream, can't one?
I just realized that the other issue is that this means that the build won't work for standard IDE builds. So instead of adding the feature to the application feature, I placed it in the .site feature. That way you still use the application feature for a simple IDE based build, while supporting the automated build and everything is kept nice and tidy. As a side effect, the issue with inclusion of the bad "Eclipse" icon/executable went away too?! Also see the recent discussion about site setup on the forums. Thomas, one other issue about using the shared TP I just realized. If we're doing an RCP build, we typically won't want to include source. This means that the materialized platform also will not include source which means that platform source code won't be available from the IDE. Is there a convenient / recommended way to selectively install platform source code into the IDE TP only? (In reply to comment #16) > Thomas, one other issue about using the shared TP I just realized. If we're > doing an RCP build, we typically won't want to include source. You can control the generation of source features using the property cbi.include.source = true/false The default setting is true. > This means that > the materialized platform also will not include source which means that > platform source code won't be available from the IDE. Is there a convenient / > recommended way to selectively install platform source code into the IDE TP > only? Yes. Populate the TP using Buckminster with our without the property buckminster.download.source set to true. The default setting for this is currently false but this is likely to change, see bug 336601. (In reply to comment #5) > (In reply to comment #2) > > I added the org.eclipse.equinox.executable feature to the product definition, > > re-resolved developer.cquery, re-created the site.p2 for the releng project > and > > finally provisioned a app with the direcor as above and it created a runnable > > product. > > > > kup@ubuntu:~$ ls tmp/bmtutlinux/ > > about_files about.html artifacts.xml configuration launcher > > libcairo-swt.so mailapp mailapp.ini p2 plugins > > > > So, I think the example product should also include the > > org.eclipse.equinox.executable feature (I think the feature contains some root > > artifacts that are only produced if the feature is present but this is only a > > wild guess...) > > I need some confirmation regarding how it should be done, and if that is > actually working before I know how to revise the information in the chapter in > question. In the meanwhile, I included a reference to this issue in the > documentation (at the start of the example). Hi Henrik, I tried the example again with more or less the same results but can now be a bit more clearer. I think my problem was that I was missing the org.eclipse.equinox.executable feature in my target platform. If the feature does not exist in the target, the generated p2-site will produce rcp-apps without a launcher. Adding the org.eclipse.equinox.executable feature to the product is not necessary to produce a correct build. It suffices that it exists in the target. In the book it says under Prerequisites: "you must have the Eclipse Delta Pack installed in your IDE." - so that's that. Since I almost never work with the IDE as a target, I tried to set up the project the way Thomas advocates. In this case it is very easy: Checkout the releng feature, materialize the mspec and you end up with a perfect workspace and target platform. The only problem with this setup is, that the target is missing the org.eclipse.equinox.executable feature. For our own products and/or components we have usually a releng feature as in the example here and also a target feature. The target feature usually includes the platform or just the rcp-feature, the launcher feature and perhaps some other stuff. It doesn't have to be crafted very carefully because buckminster will add other dependencies to the target if needed. But it is necessary for things that are needed in the target but are never included in the finished product. Thanks Peter, this is starting to make sense, and explains why it is so confusing :) I think it is possible to put this in the Bucky Book now in a way that is more clear than just stating a prerequisite on the delta pack. (In reply to comment #19) > I think it is possible to put this in the Bucky Book now in a way that is more > clear than just stating a prerequisite on the delta pack. If you set it up as described above, I think it is not necessary to deal with the delta pack at all. It is possible to manually add the equinox.executable and then build a full RCP app. That ends up with a much more straightforward configuration for Hudson and IDE installs. So it would be good I think to document that possibility. I agree with Miles. There's absolutely no reason to use the delta-pack. IMO, it's a relic from the pre p2 days and have no place in a modern build. Any mention of it in the documentation should be removed. Our build (the build that builds Buckminster itself) is based on a general release engineering project[1] that contains a buckminster.cspec. This cspec declares a dependency to the org.eclipse.equinox.executable feature. That's all that's needed. This dependency ensures that this feature and all it's dependencies are present in the target platform. [1] Our releng project is primarily intended to run as a Hudson Buckminster job, but is easy to tweak to run in your workspace as well. It can be viewed here: http://dev.eclipse.org/svnroot/tools/org.eclipse.buckminster/trunk/org.eclipse.buckminster.releng/ |