Re: [buckminster-dev] Field report

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Thomas,
Thanks for the heads-up. This is really great news for the Buckminster 
project. You are the first Buckminster user that managed to do this with 
virtually no help from us (I promise, we will not consider that a reason 
to relax with the documentation :-) ).

I may have some good news for you too. More inlined below...

Thomas Spiessens wrote:
> 1. Being able to export the product using Buckminster (perhaps by a 
> new Buckminster command). It is a bit annoying to be using the PDE 
> build because PDE expects a particular directory structure of the 
> feature and plugin projects. This means that after the materialization 
> we need to reorganize the directory structure through a script. If 
> Buckminster would be able to export a product, we might not have to do 
> this, making our script a bit simpler and easier to maintain in the 
> future.
Buckminster is used in production at BEA in Stockholm and we export 
products without the PDE build today. Buckminster CSPEC actions does it 
all. Here's an example of the CSpec extension that we use today:

<?xml version="1.0" encoding="UTF-8"?>
<cse:cspecExtension
   xmlns:cse="http://www.eclipse.org/buckminster/CSpecExt-1.0";
   xmlns:com="http://www.eclipse.org/buckminster/Common-1.0";
   xmlns:cs="http://www.eclipse.org/buckminster/CSpec-1.0";>

   <cs:actions>
       <cs:action name="create.mc2.product" actor="ant">
           <cs:actorProperties>
               <cs:property key="buildFileId" 
value="buckminster.pdetasks"/>
               <cs:property key="targets" value="create.eclipse.product"/>
           </cs:actorProperties>
           <cs:contextProperties>
               <cs:property key="buckminster.eclipse.productFile" 
value="mc2.product"/>
           </cs:contextProperties>
           <cs:prerequisites 
alias="buckminster.eclipse.product.requirements">
               <cs:local name="runtime.eclipse.feature"/>
           </cs:prerequisites>
           <cs:products alias="buckminster.eclipse.product.product" 
base="${buckminster.output}">
               <cs:path path="mc2.product/"/>
           </cs:products>
       </cs:action>
   </cs:actions>
</cse:cspecExtension>

In short, the action appoints the 'mc2.product' file, a normal Eclipse 
.product file that file resides in a feature component. It in turn 
appoints the feature in which it resides. The rest is automatic, i.e. 
that feature appoints other features and the sum of it all is built in 
the 'runtime.eclipse.feature' prerequisite. We type:

buckminster perform com.jrockit.mc.rcp.product#create.mc2.product

and that builds the rest. It's completely headless and agnostic to 
directory structure etc. We do of course reuse a lot of the PDE models 
when we generate our CSpecs. The actions, dependencies, etc. are all 
generated based on what's in files like manifest.mf, plugin.xml, 
feature.xml, and build.properties.


> 2. Some of the projects are also dependent on a number of JBoss 
> libraries. These libraries become available after register a new JBoss 
> server (available after installing the JBossIDe plugin). The way we do 
> that now in headless mode is by copying a number of files in the 
> metadata folder of the workspace that was created by Buckminster after 
> the materialization. We were thinking of writing our own Buckminster 
> command for registering that server.
Interesting. I'd like to be in on the design if I may. Sounds like it 
would fit right in the "runtime environment" concept that we are working at.


> 3. Generating Javadoc from Buckminster
I attended the 'Eclipse Build Workshop' last week where we met with 
people that has an interest in Eclipse build/release management. Among 
them, two representatives from Maven. Read all about it here: 
http://wiki.eclipse.org/index.php/Europa_Build_Workshop_Report. As you 
can see, we are planning to integrate more closely with Maven (hence the 
votes to get John Casey in as a Buckminster committer). One direct 
consequence of that will be that we can call on Maven plugins from our 
actions. Maven in turn, have great plugins for Javadoc.


> 4. Running all of our unit test, but we are currently investigating that.
Should not be much of a problem using the new CSPECc actions and an ant 
actor.


> 5. We are also in the progress of investigating the actor mechanism.
We are currently working on documenting all new cspec features. I hope 
we will have something out real soon.


> Keep up the good work,
You too.

Kind Regards,
Thomas Hallgren