[Subclipse-dev] Building Subclipse with Hudson/Buckminster
From: Stephen Elsemore <selsemore_at_collab.net>
Date: Thu, 27 May 2010 13:01:57 -0700 (PDT)
As Mark Phippard suggested (http://subclipse.tigris.org/issues/show_bug.cgi?id=1144), it would be very nice if Subclipse builds could be automated using Buckminster on Hudson. I will gladly work on such a project but, based on my initial foray into using Buckminster on Hudson, I can see that I will need some help figuring out how to make it all work.
@Thomas Hallgren
I started out knowing nothing about Buckminster and very little about Hudson. My primary resources so far have been:
Buckminster book
Ralf Ebert tutorial “Headless Eclipse RCP builds with Buckminster and Hudson”
Eclipse forum discussion “Mini-Tutorial: Fetching, archiving and re-using a targt platform with Buckminster/Hudson”
As background, you should also know that everything that I’ve tried so far has been on Mac OSX. Several of the early bumps that I encountered were related to that. For example, at first nothing at all was working with headless Buckminster. I finally figured out that my problem is described here:
http://www.eclipse.org/forums/index.php?t=tree&goto=517230&
When I configured the Hudson Buckminster plugin, I’d selected the option to “Install automatically”, which causes the headless Buckminster to be downloaded and installed the first time it is needed. To fix the problem, I had to delete the version that had been automatically downloaded, then load it manually using the parameters that were suggested in the above link. Then I changed the Hudson Buckminster configuration to use the version that I manually loaded, and that fixed the problem.
I suppose it’s possible that some of my remaining issues could also be OS-related.
Anyway, here’s what I’ve done so far:
First I installed Buckminster plugins into Eclipse and Hudson. Then, rather than diving right in and trying to tackle building Subclipse, I decided to try it out with a simple test plugin that does nothing more than contribute a bare bones view. To do this, I basically followed Ralf’s tutorial. The tutorial builds and packages an RCP application, rather than an Eclipse plugin, so I made the changes that I thought were necessary to make it work with a plugin.
Here’s what I have for Eclipse projects, all checked out from an SVN repository:
org.elsemore.steve.MyApplication (Plug-in Project with a view)
org.elsemore.steve.MyApplication.site is not to be deployed. It just hosts the files for the Buckminster build (.cquery, .rmap, .target).
I created a new free-style job in Hudson, with the following attributes:
Project name: MyApplication
I at first named it “My Application” (with space). Big mistake! I found that importtargetdefinition does not work correctly (but doesn’t give any indication that it did not work correctly) when there are spaces in the path to the target platform file. It took me awhile to figure that one out.
Source Code Management:
Selected “Subversion” and added 3 Repository URL’s:
<my repository root>/trunk/org.elsemore.steve.MyApplication
I realized at this point that I had several options:
1. Let Hudson populate the workspace by checking out my projects from Subversion.
I went with option 1 because it matches the RCP tutorial approach, and because it would seem to minimize the chance of conflicts when I eventually get around to trying to build Subclipse itself.
Run Buckminster Build Step:
Commands:
importtargetdefinition -A '${WORKSPACE}org.elsemore.steve.MyApplication.site/platform.target'
Here is how I created platform.target file:
Eclipse->Preferences->Plug-in Development->Target Platform
(I am very unsure about this step.)
Here are the contents of site.cquery:
<?xml version="1.0" encoding="UTF-8"?>
And here are the contents of site.rmap:
<?xml version="1.0" encoding="UTF-8"?>
<searchPath name="resources">
<locator searchPathRef="resources"/>
Results of running the build:
1. Resources are checked out into workspace as expected.
2. importtargetdefinition runs for a long time, with lots of “Retrying request” messages, but ultimately completes and seems to have properly imported the target platform. I can see that all the required jar files are now in:
<workspace>/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/plugins
Ultimately, I would like to avoid refetching the target platform for every build. In an effort to achieve this, I experimented with using the approach described here:
http://www.eclipse.org/forums/index.php?t=tree&th=163429&
So far, I haven’t been able to make that work, which I’ll explain later.
3. build fails with this error:
Error: file /Users/stephenelsemore/.hudson/jobs/MyApplication/workspace/org.elsemore.steve.MyApplication: The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.swt.widgets.Composite. Fix the build path then try building this project
At first I thought that maybe the build path simply did not include the target platform stuff that was created by step 2. But I don’t believe it’s that simple. If I remove the SteveView class from my project (eliminating the SWT dependency), the build will work fine (even though the Activator class in my project still requires org.eclipse.jface.resource, org.eclipse.ui.plugin, org.osgi.framework). So I’m not sure why the error. I can see that the <workspace>/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/plugins folder contains SWT jar files for every platform imaginable (which is perhaps overkill), but Buckminster seems to not find or ignore the one that is needed? Or more likely I am missing something in the configuration? I’ve experimented a lot with this, but am so far still stuck.
4. (if I remove SteveView class from my project to avoid build error) perform -D target.os=* -D target.ws=* -D target.arch=* org.elsemore.steve.MyApplication.site#site.p2:
Works as expected. Update site is built here:
<workspace>/buckminster.output/org.elsemore.steve.MyApplication.site_1.0.0-eclipse.feature/site.p2
So, if I could get around the build error in step 3, I’d be making some progress. Any help would be appreciated!
Regarding my failed attempt to archive and re-use a target platform (step 2, above), this is what I tried:
Create a job exactly as described above, but also check “Archive and publish an Eclipse Platform”.
Path to Target Platform: .metadata/.plugins/org.eclipse.pde.core/.bundle_pool
Run this job.
Create a new job similar to the original job, except that the Run Buckminster build step specifies:
Target Platform: MyTargetPlatform (which now shows up in the dropdown)
In the new job, I removed the importtargetdefinition command, assuming that this is no longer needed now that the archived target platform is being used (I have a feeling I’m starting to go wrong here).
When I run this new job, it fails with this error on the import (which is perhaps not related to the target platform?):
INFO: import '/Users/stephenelsemore/.hudson/jobs/MyApplicationCannedPlatform/workspace/org.elsemore.steve.MyApplication.site/site.cquery'
If you are still reading, THANKS! I’d be very thankful for any information you can give me to help me resolve my problems. Once I get past these issues, I’m sure things will get even more complicated when it comes to applying such a solution to Subclipse builds (so far there’s very little demand for MyApplication), so any ideas or suggestions that you might have regarding that would be fantastic.
Regards,
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
|
This is an archived mail posted to the Subclipse Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.