Bug 253266 - Decide on shape of CBI
Summary: Decide on shape of CBI
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Dash Athena (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Common Build Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: Documentation
Depends on:
Blocks: 253278 238626 253271
  Show dependency tree
 
Reported: 2008-11-03 14:47 EST by Andrew Overholt CLA
Modified: 2012-01-30 11:31 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Overholt CLA 2008-11-03 14:47:00 EST
We need to come to a decision about the actual shape of the CBI.

Option #1 (what we currently have):

{project releng}/<properties> and *no* build.xml
{common releng}/<.xml and .sh scripts> --give-location-to-project-releng

Option #2 (what has been proposed in bug 252870 comment #10):

{project releng}/releng/<model or single properties file> *and* build.xml
{common releng}/<build.xml or something>

I personally prefer the former:  no boring build.xml file in each project's releng area.  Each project wanting to do local builds would need to check out the common releng project and invoke from there saying which project they want to build (the only real input aside from .properties or a model).  So my vote is

+1 to option #1
Comment 1 Nick Boldt CLA 2008-11-15 00:34:44 EST
Well, having a model instance doc, including both structure and data (rather than a properties file) would be nice in that we could easily wrap an editor around it rather than just comments in the properties file, and then include data validation.

Unfortuntely, this would mean the CBI would depend on either parsing that EMF model instance into properties Ant can read (perhaps a new custom task?), or use of some generator/templating language to transform .xmi into .properties.

Rich, if you're willing to help here, this would open the door to having EMF/GMF-based tooling for creating builds. 

In either case, we need more than just properties. buildExtra.xml will be required in addition to the data model for properties, though we can use more properties to define what build steps to run (build source zip, build sdk zip, build runtime zip, build tests, run tests, generate update site, generate p2 metadata, etc.)

Comment 2 Richard Gronback CLA 2008-11-17 12:50:02 EST
(In reply to comment #1)
> Rich, if you're willing to help here, this would open the door to having
> EMF/GMF-based tooling for creating builds. 

The initial (crude) build.ecore and associated product.ecore are found here, along with all the QVT/Xpand I use to generate product build scripts for Amalgam and now Galileo: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.amalgam/releng/org.eclipse.amalgam.releng.builder/?root=Modeling_Project

There's a lot to do, as I've only abstracted that which was necessary to get it running.  I will have time to improve later, which shouldn't preclude you making some reasonable templates in the meantime that we can use to target generation later.
Comment 3 Nick Boldt CLA 2009-01-16 11:57:50 EST
slip
Comment 4 Andrew Overholt CLA 2009-04-17 11:02:02 EDT
For now, we've decided on option #2:

{project releng}/build.properties
{project releng}/build.xml (very simple and is just basically a launching point for Athena's build.xml)

We should document this.