Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [buckminster-dev] tips on headless buckminster in CI environment?

Todd_Lee@xxxxxxxx wrote:
Many thanks to the community at large (especially Thomas & Adrian) whose
help has got us to the point of resolving a workspace headlessly :D
As you can probably tell from the deluge of posts to this forum, we're
currently on our way from 0 to 60 in getting an autobuild system up and
running, so thanks in advance for your patience!

I'm wondering at this point if anyone would have any tips as to best
practices using buckminster for headless builds? Looking to those who've
successfully implemented similar systems, I guess I'm asking, "what do you
wish someone told you when you were starting out that would have saved some
bruising on your forehead..."?

We're building an eclipse IDE based product which uses alot of external
stuff. We're automating using a Pulse CI build server and looking to
buckminster to solve our 'middleware' issues (resolving/materializing
workspaces and dependencies). The current build is PDE based.

Specific questions:
1) what's the best entry point for buckminster in a real-world build setup
- standalone or ant integration?
In my opinion, you have two entry-points. One that is configuring your build system and one that executes tasks in that build system.

Configuring:
The Buckminster product is a very thin headless Eclipse Runtime executable. It cannot do much more then configure itself. The intention is that an organization maintains a pre-configured Buckminster that is suitable for their needs, i.e. if you work with OSGi bundles and uses SVN repositories, you would configure your Buckminster with the pde and svn support.

The first entry-point in my opinion, is the script that configures this Buckminster runtime and publishes it at some shared place where everyone that needs it can find it. You only need to rebuild this configuration when you need a new version of some feature in Buckminster. This build-tool would also contain an ant-script with the Buckminster macro.

Executing:
This entry-point is an ant-script that uses the configured Buckminster. The typical flow is to first a CQUERY and then perform a series of perform commands on the resulting workspace.

2) once the workspace is materialized, is buckminster's role finished? ie -
is it best to just hand off to ant from there and execute the build or is
it better to use buckminster's 'perform' command to execute actions to
accomplish build tasks?
Buckminsters role is to orchestrate the build. After a materialization Buckminster knows where all components reside and how they fit together. Many of the ant-tasks that are provided with Buckminster are tailor made to make use of the environment that the Buckminster ant actor propagates to them.

3) artifacts/cacheing - cleaning vs. retention - given the large amount of
caching that buckminster seems to use, is there any concern about clean up
post-build? Do people clear caches or just let them accumulate. And related
to products of buckminster, is there anything that you'd really suggest
keeping for posterity (obviously the bomfile comes to mind...)
In a headless scenario, I think that a complete clean of the "${buckminster.output.root}" is the preferred way. Although Buckminster keeps track of what to rebuild, it cannot know about artifacts that used to be there but has since been removed (if you remove a project for instance, old builds of that project may remain).

4) specifically to those using pde builds - any tips/pitfalls with
buckminster?


Make sure you define the ${buckminster.output.root}. The default folder is probably not what you want.
Use OSGi manifests in all plug-ins
Make sure all bundles have a build.properties with correctly defined src/bin and bin.includes Using SVN, the revision number is great to use in the version qualifier. Using CVS, a timestamp isn't half bad. Buckminster is able to compute the feature qualifier based on included features and plug-ins. You can use one of two settings:

for SVN
qualifier.replacement.*=generator:lastRevision
generator.lastRevision.format=r{0,number,00000}

for CVS
qualifier.replacement.*=generator:lastModified
generator.lastModified.format='v'yyyyMMdd-HHmm

Any suggestions are certainly appreciated!

Also, as an aside - any plans to include tutorials on this subject on the
wiki? Seems like a good candidate for a walk through. The documentation is
a big help and I know for me, it would be great to see buckminster at work
in the context of a sample build from beginning to end to demonstrate full
scope.

Yes. We have plans to do this. In my opinion, the task of providing such content it's way overdue. Any help in making it happen is greatly appreciated.

Regards,
Thomas Hallgren



Back to the top