Community
Participate
Working Groups
Having a common build infrastructure would be a good thing (tm).
*** Bug 178148 has been marked as a duplicate of this bug. ***
Having support here for Cruise Control to run, schedule, and queue builds would also be a good thing (tm). See also http://dev.eclipse.org/blogs/releng/2008/07/02/build-workshop-2-build-harder/
As someone who has tried (unsuccessfully) to convince the board of directors and EMO last year that this is an essential infrastructure facility that should not be left for each project to re-invent, I am encouraged that there might finally be some traction on this.
(In reply to comment #3) > As someone who has tried (unsuccessfully) to convince the board of directors > and EMO last year that this is an essential infrastructure facility that should > not be left for each project to re-invent, I am encouraged that there might > finally be some traction on this. Considering Bjorn flew in specifically to attend this workshop, and has since provisioned a new Dash project for it, I'd say the EMO is on board here. :) That said, we're always looking for more people to contribute...
(In reply to comment #4) > That said, we're always looking for more people to contribute... > FWIW, I was thinking about this effort the entire time I was wrestling with PDE build last week. I thought it might be helpful to capture some of the steps I had to take to get build to work (identify some of the pain points, and what-not)... 1. I used the Eclipse 3.4 documentation to get started. As suggested, I copied the build.properties file and set about modifying it for my own project. I decided to get the build working first on my laptop and then, second, on the build server. ** There are numerous tiny mistakes (spellings, mistypings) in the template file. It's also not entirely clear what each of the properties is for and why it's there. As a minimum effort, the template file could use some love. 2. I managed to get plug-ins and features built with little ado. However, to build an update site, I needed to go and look at what another project did. I happened to know about the EPP project, so I went to it and basically copied what Markus did for the UDC update site. It took a while for me to get all the properties right; one-property in particular, outputUpdateJars, nearly resulted in some localized fatalities (it turns out that I wasn't really building right as suggested in #1). 3. Adding pack200 and signing to the output was another challenge. Again, I looked to the work that Markus had done on the EPP project (which I assume he got from somewhere else). In order to do signing, I had to get permissions configured by the webmaster to actually invoke the signing executable on the build server. I modified the scripts that I found for signing to conditionally sign only if the signing executable is available. This way, build works (albeit incomplete) on my workstation as well as on the build server. 4. Building a package using EPP was dead easy; though I've only tried to run this on my local workstation. Since my code doesn't all conform to the rules set out by the EPP, I have to build my package separately for now... As I was working through this, I tried to parameterize as much as possible, rather than hard-code everything. I'm close to a point, I believe, where I can do builds of other projects by creating a different shell script to invoke the build process. I have shied away from leveraging the build.properties more completely, but this might be an option to explore. Of course, using an XML file would make it easier to specify things like maps... Initially, I ran my builds against an instance of Eclipse 3.3 added to the build server by the EPP project. It quickly became clear that this wasn't going to work, so I created my own 'base' using the 3.4 release version. It'd be nice if a handful of common bases were already available on the server (rather than each project having their own copies). My project only needs the base to compile; a more general solution would need to consider the inclusion of code from other sources. Frankly, most of this effort was that of comparing what other people did to spot differences to figure out why the heck something wasn't working. Error messages were actually generally helpful, though they are cryptic and difficult to identify in the output.
Thanks for the insight, Wayne. This is quite timely with what I have just posted to dash-dev: http://dev.eclipse.org/mhonarc/lists/dash-dev/msg00272.html
Moving to new Dash.Common Build
Moving to default assignee so that Mylyn-created subtasks default to the correct assigneem too.
A preliminary draft project plan is available in CVS here: /cvsroot/org.eclipse/www/dash/athena/project-info/plan.xml,v It's taking aeons to appear on the website or in viewVC, but when it does it will be accessible here: http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/dash/athena/project-info/plan.xml&component=Athena Feel free to revise the entirely arbitrary milestone markers in Bugzilla and the milestone dates if you feel they're crazytalk or should better align with Galileo dates. -- Note: I used the status whiteboard field in Bugzilla because there are as yet no Target Milestones for the Dash project -- Bjorn, can you add some or empower me so I can add some via the committer tools? kthxbye.
I'm declaring success on this bug as, IMHO, the Athena efforts were successful.
