Re: [gmf-dev] Build machine up and running

[Steven Shaw <steveshaw@xxxxxxxxxx>]

I would suggest that having a dependency
from the tests to examples is acceptable and desirable.  By instrumenting
the JUnits to use the examples, we are demonstrating sanity of the examples,
and providing robust test harness for the tests.  In the case of the
runtime we are also trying to utilize the logic example and would like
to expand the suite of tests in this context as well. (see org.eclipse.gmf.tests.runtime.diagram.ui.logic#LogicCanonicalTests)

If this is a concern, perhaps we could
create an explicit directory that allows for testing of the examples: i.e.
examples_tests were JUnit plug-ins that test the examples could placed.

-Steve
________________________________________
Steven R. Shaw
Rational Modeling Platform Diagram Layer Lead
Rational Software | IBM Software Group
770 Palladium Drive, Kanata, ON, Canada, K2V 1C8
tel: 613.591.7979
steveshaw@xxxxxxxxxx

Frederic Plante/Ottawa/IBM@IBMCA
Sent by: gmf-dev-bounces@xxxxxxxxxxx

09/15/2005 09:24 AM

Please respond to
"GMF Project developer discussions."

To	"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc
Subject	Re: [gmf-dev] Build machine up and running

This is great news, thanks Rich! 

Some comments/answers: 
  * Deleting the source plug-in is fine, but please wait until we
have builds are published on eclipse.org 
  * Dependencies on WTP (enhanced properties) will go away in 3.2
given the subsystem will move into platform core as per Anthony's reply
  * Dependency on UML2 are only for tests, this gives us a non-toy
meta-model to use in our tests. If possible we should keep
  * Dependency on examples is for the meta-model used in example,
we should probably duplicate the plug-in in tests. Would also allow us
to evolve it independently if needed. 
  * About build notifications, we have at least 15 people here who
would be interested, I suggest creating gmf-relend@xxxxxxxxxxx :-)

    Thanks

       - Fred

_________________________________
Frédéric Plante
Rational Software, IBM Software Group
770 Palladium Drive, Ottawa, ON, Canada 
tel: (613) 591-7034

"Richard Gronback" <Richard.Gronback@xxxxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx

09/15/2005 08:27 AM

Please respond to
"GMF Project developer discussions."

To	"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc
Subject	[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 
 _______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev