Re: [dash-dev] Re: [buckminster-dev] There must be 50 ways to build your

[Achim Demelt <a.demelt@xxxxxxxxxxxxx>]

Nick,

Comments below.

> Does Bucky handle javadoc generation 

There's no support for javadoc generation out-of-the-box, at least none that 
I am aware of. That said, with a few lines of XML and Ant code, it is 
possible to hook javadoc generation into the build process. We are doing 
this in our company's product build and include the resulting javadoc in doc 
bundles that provide it as Eclipse Help content.

As a side note, we also pull our product's user guide content from our in-
house Confluence wiki, transform it into HTML, produce a toc.xml, and add 
this to the Eclipse Help, too. All orchestrated by Buckminster on our build 
server.

> or running of headless UI tests and
> collecting JUnit results in XML/HTML?

That's work in progress. We (speaking as a Buckminster committer now) are 
working with the JDT and PDE teams to clean up their JUnit launching code 
(see [1] and [2]). We'll then be able to run JUnit tests in Buckminster 
headless. By reusing the regular JDT/PDE JUnit launchers running in a 
regular (headless) workspace, we can more or less guarantee that these tests 
do the same things that they're doing in your IDE. Same classpath, same 
target platform, same environment, same everything. We'll actually simply 
run a saved *.launch config.

> Can it run tests on different
> platforms from the one on which the build's run?

I think that'll be hard to do.

> Those pieces work in
> Athena (except build on platform X, test on Y), but they're still rough.
> If it's in Bucky already, reuse would certainly be better than
> reinvention.
> 

That's actually one of the ideas behind Buckminster: reuse existing 
technologies. The platform with JDT, PDE et al. does a very nice job of 
building your stuff in your IDE. We're "just" calling it in headless mode, 
thus producing the same build results without any extra configuration. 
Unfortunately, some of these parts were not meant to be reused in that way 
(again, see [1] and [2]).

> I've also been asked to look at a better approach to target provisioning
> prior to building. Today, we unpack an Eclipse SDK zip + any referenced
> SDK/runtime/update zips, p2.director install from referenced update
> sites / zips any required features, then start fetching sources and
> orbit bundles. But requiring an SDK when you're running in Eclipse is
> not the best scenario for RCP and equinox people

I'd say that Buckminster has a very good story for providing the target 
platform, both in your IDE and your automated build: Specify the bundles and 
features you're building against---version ranges ensure you'll get those 
your want to have---and Bucky uses p2 to fetch it from wherever you tell it 
to.

Regards,
 Achim

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=278844
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=278845