[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] ECF build v2 -- Build easier
|
Hi Scott,
Just to give you some feedback on your specification of missing elements
in a Buckminster-based build system, I'd like to share some of my
tribulations.
As I have been an early adopter of Buckminster, I have a solid two years
of experience running a complete build system with said tool. I have
been negotiating recently with the project lead to return some of the
proprietary build actors (e.g. a very necessary packaging actor), but
surprisingly met resistance in terms of those actors considered a
reinvention of the wheel (sic!), as I should have written Ant scripts to
do the same work, and call those Ant scripts using Buckminster.
Needless to say, I disagree with this position. The original appeal of
Buckminster was, from my point of view, to move beyond the Ant script
bonanza. I can only testify that our pursuit of what we believed the
vision to be, worked incredibly well, and we managed to roll this thing
out in the company over different teams without the headaches of getting
started with Buckminster as it still stands today. Unfortunately, that
is no longer the road the Buckminster wagon seems interested in
traveling on.
In addition, I was surprised to see the project itself had made no
substantial progress over a very long time, at least in terms of what
you might expect from a product maturing and evolving as they normally do.
Ironically, we managed to get Buckminster to do everything a releng nerd
desires with our proprietary extensions, already years ago, yet a lot of
that stuff is still not available today. As much as it pains me to say
this, I have become very skeptical about the project. I will spare you a
description of the look on my face when I discovered that, apart from an
overhaul to replace overlapping parts with p2 (which came out of left
field to duplicate a lot of functionality), now it seems that this
particular build tool seems lost without EMF, thus prompting the
introduction of EMF into B. But don't expect it to make your packages
for you, or signing of those for that matter. You'll need an Ant script
to that.
The problem I see is that there is no reason to consider moving to
Buckminster from an existing system, as it stands today. You would need
to contribute additional components yourself, first. As a project
manager, I would like to see a compelling reason to warrant such an
effort under the ECF project umbrella. Speaking from experience, hooking
yourself onto the Buckminster train means a lot of work in terms of
keeping up to date with updates and bugfixes. We got tired of the heavy
maintainance of our plug-ins and simply forked and never looked back.
Not an option anymore given Buckminster's status in the ecosystem. Even
though I'm still considering forking myself (on the last EMF-free code
base), and have a complete snapshot at my disposal to that end, right
now I'm checking out if it simply doesn't make more sense to see if
building something on top of p2 isn't the way to go. It would appear p2
has almost made Buckminster redundant; I'm still investigating the
validity of that claim.
Any which way, sounds like hell of a lot of work still to do before you
can actually build and release. Can you afford that?
Best regards,
Dann
Scott Lewis wrote:
Hi Folks,
Now that Galileo is past us, many of us would like to move toward
fully using our new (and much improved) automated build and test
system. Markus and Ted have already done quite a lot of work to get
Hudson and Buckminster installed, configured, and it's now running at
the OSU Open Source lab sight. Overall, we're actually pretty close
to replacing/removing our existing builder with this new, better,
easier, more managable one.
There are, however, several things to address/add in the new build
system before we can pull the plug on the existing builder:
In broad strokes, we need to:
1) Add bundle signing (for dev.eclipse.org build)
2) Setup/refactor the features so that we can build
a) weekly platform integration builds (i.e. filetransfer and ECF core)
b) auto, daily, integration and release builds (on-demand for
release...others can be automated)
3) Add a builder for the features/bundles at OSU OSL (including
JMS/ActiveMQ, Yahoo provider, TweetHub (product), and perhaps other
things...e.g. SOC student work)
4) Add automated junit testing
5) Add support for Markus' work on distributing testing framework
6+) The million other things that have to be done for 'build system
care and feeding' :)
7) The other things that I've forgotten
I think the first thing to do is to arrange to have a conference call
with Markus (Lemmy)...so Markus can explain and demo the buckminster
and hudson-based builder...and those of us that will be working with
it can know what's happening, how it can be configured/added to to
setup the things listed above (as well as others).
So if Markus would respond to this email with an indication of the
days/times (UTC) he would be available for hosting a shared screen
session (with screen sharing tech of choice) over next two weeks we'll
set it up and then have it.
If you are interested in participating in the ECF building/deployment
process (which I strongly encourage, BTW...even if you aren't a
committer)...please try to come to this conference call. This is an
area where we can/could absolutely use some further contributions from
the community, as a couple of us (Ted and Scott) are wanting to spend
more time/effort this year on development, and have 'paid our dues'.
It's also great experience (IMHO), as building/deploying for any
significant system is always (and always going to be IMHO), a
technical, process, and community challenge.
Thanks,
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
