On Mar 9, 2007, at 3:13 AM, Rupert Smith wrote:
On 3/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote:
What is the timeline for your Qpid release? There have been a few
new additions, like translate-war... and I have been trying to figure
out how to make integration tests for this plugin to help ensure the
quality of releases, both of which have slowed down the release.
But, its unlikly I will have time to make a decent integration
testsuite for this any time soon, so I will start the release march
now for 1.0-alpha-2.
Release over the next couple of weeks. We are just about to branch for
the release but there will probably be fair bit of bug fixing/ensuring
documentation is up to date etc. Should leave a big enough gap to pick
up the 1.0-alpha-2 release. Many thanks.
Sure, that sounds very plausible. Hope to have a release sometime
next week.
I've been trying out AHP, and must say I'm pretty impressed. One of
the challenges of automating the Qpid build is that it needs to be
built and tested over multiple operating systems, and it has messaging
clients written in mutliple languages (Java, C++, C#, python, ...).
The server/agent/workflow architecture of it seems appealling in that
respect.
Yup, should be very easy to setup AH agents for each of your
platforms and then execute the correct bits on each platform from a
workflow.
Right now we don't use this feature, as all of our agents are Linux
FC5 systems, though eventually I had hopped to get a few (evil)
windows machines in the mix so that we can run the TCK on that
platform too. Though I'm not looking forward to administering those
machines ;-)
Anyways, AH is a no-brainer IMO if you need this type of build
environment.
Also, as you say, the ability to correlate artifacts and test
results over an extended build process is going to be extremely handy.
Ya, this is key IMO. Not sure what you folks use to build with, but
if you use Ant w/o any remote repo muck (like the mvn or ivy tasks)
then you can get really reliable/solid builds almost out of the box.
If you use Maven (or remote repo tasks), then there is a little bit
more work involved, and a bunch of dependency artifact shuffling from
server to agent that needs to be done to get the same effect (though
its not quite as solid). But its relatively easy to implement that w/
AH... though it makes it a little harder to use agents which are not
on the local network, as the time/bytes to push/pull deps to/from the
AH codestation repository becomes problematic for large datasets.
But, chances are your builds are a tad smaller than the Geronimo
builds, so you might not even notice ;-)
Thanks for your comments, and kind offer to share more details. If
I've got further questions, I'll post them on the Geronimo list.
Sure, lemme know. I've setup our AH configuration to use some Groovy
glue to make the configuration a wee bit easier to manage, the bulk
of which is available here:
https://svn.apache.org/repos/asf/geronimo/sandbox/build-support/
Cheers,
--jason
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
