Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[gmf-dev] Build machine up and running

Hi All,

 

The build machine is (finally!) up and running under CruiseControl with reports available at http://gmf-dev.borland.com/cruisecontrol (note build times are Pacific, as the machine is in California).  The machine’s local development update site is accessible at http://gmf-dev.borland.com/updateSite.  I don’t recommend we use this for installs (and certainly not for the community), but it does give you an indication of our build dependencies, as they are mirrored locally for the builder.  Once we have cleaned up our builds and have a decent end-to-end story and doc, we can start publishing the builds to the Eclipse.org download and update site.

 

There have been some CVS connectivity issues recently, causing some build failures (not just for GMF, it seems).  Also, we need to do a bit of cleanup to get the builds refined and tests working properly.  For example, we should scan all build.properties files to make sure we’re including what we need in both the bin and src builds.

 

A number of other issues remain:

- I’ve requested another gig of RAM be added to the machine.

- The printing plug-ins are still excluded.  I will investigate why they were causing build problems later this week and re-include them.

- There is an org.eclipse.gmf.runtime.source plug-in in CVS that I think we can delete (from the IBM contribution).  All source plug-ins are generated by the build so we don’t need it.  Objections?

- I will work on creating a new feature for documentation (org.eclipse.gmf.doc) and move the existing runtime doc plug-in into the /doc module in CVS.  This will reduce the size of our runtime download, better isolate the doc build (which seems to have some special needs I haven’t explored yet), and be in line with other projects (e.g. EMF).

-  I’d like to reduce the number of dependencies we have, if possible.  Currently, we have dependencies from tests to examples and to UML2, a dependency on WST (and therefore SDO, XSD, and JEM), and obviously EMFT, which should become “cleaner” shortly.  I guess my concern here is with our opting-in to the release train for the 3.2 release (our 1.0 release) these will make things more complicated for us (and for our users).  Ideally, we would only have dependencies on EMF, GEF, and EMFT.

- If you want to receive build notifications via email, let me know (just failures, or all).  With enough interest, I’ll have a gmf-releng@xxxxxxxxxxx list created.  Alternatively, you can use the RSS feature on the CruiseControl reporting site (let me know if it actually works ;-).

 

I will continue to test and refine the build this week and next, with regular integration builds coming soon to help us synch up with the train as soon as we can.  The M2 milestone is Sept. 23rd, with M3 on November 4th.  We should be able to follow EMF + GEF milestone builds by 1 week of theirs, which should be within 1 week of the platform.  This gap will need to narrow accordingly as we approach the “big bang” release at the end of June 2006.  I did a quick SDK build with 3.2M1 and EMF2.2M1 Monday with no obvious problems (read: it compiled ;-).

 

Thanks for your patience and help getting this done! 

 

Best,

Rich

 

PS - Henrik, yesterday I followed and updated the build instructions, so hopefully we’ll get you working now.  For others interested, the instructions for running locally are posted on the Developer Resources page of our website: http://dev.eclipse.org/viewcvs/index.cgi/*checkout*/org.eclipse.gmf/releng/org.eclipse.gmf.releng.builder/readme.html?cvsroot=Technology_Project

 

 

Richard C. Gronback

Borland Software Corporation

richard.gronback@xxxxxxxxxxx

+1 860 227 9215

 


Back to the top