[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [buckminster-dev] Field report
|
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