[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] ECF build v2 -- Build easier
|
Hi Thomas,
Sounds like a discussion which needs to go off-line, over a good beer. I
appreciate your comments and replies, and I hope I can convince you I do
not mind hearing people speak their mind about my rantings, no matter
how strong the verbiage ;) I am the first to admit that some of my
statements could benefit from a stronger argumentation, and some, as you
point out, are based on misunderstandings. What's left should guarantee
a lively discussion at the bar, at the next EclipseCon :)
Even though I prefer open, direct discussions, I also hope you
understand that I only refrain from rebutting too much, because I see a
very long interleaved reply train coming up here, possible without end.
Especially on the EMF thing, which now affects Buckminster, too. I *do*
have strong opinions on the matter, and I'm waiting for a better moment
to voice my concerns on some e4 design decisions, as Doug Schaeffer
already did http://cdtdoug.blogspot.com/2009/07/my-biggest-fear-for-e4.html
My concern is genuine, and based on actual experience of trying
*everything* the Eclipse ecosystem has to offer in production scenarios,
only to see productivity in the team plummet in some cases, because of
scale and continuity issues. But, I'm not going to open up that can of
worms, now. But it is similar to what developers have been reporting
about the WSAD+Rational ball-and-chain experience.
So far, my experience with Buckminster, that while ago, was quite the
contrary: a real productivity boost for several teams over different
sites. Hence my cringe moment when I saw some dreaded acronyms pop up,
all over again.
I do prefer to sit this one out on the bench, though, as far as post-EMF
Bucky is concerned!
Best regards,
Dann
Thomas Hallgren wrote:
Hi Dann,
I feel that some of your statements are based on misunderstandings and
others on the status of the project as it were two years ago (still in
incubation). Some answers inline in an attempt to clarify our position.
Dann Martens wrote:
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.
As I recall it, the mention of "reinvention of the wheel" concerned a
Javadoc actor, nothing else. Writing it was on your TODO list and my
"resistance" was more intended as a hint about priorities then
anything else. I'm still interested in your "packaging" actor unless
there are issues with third party libraries (JBoss). There's an
unanswered question in the thread about what that actor does exactly.
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.
Your text about the Javadoc actor and my answer, in verbatim:
>> And high on my TODO list: the Javadoc actor; I'm not a fan of
falling back to Ant for standard artefacts in release engineering.
>>
> Neither am I. But I'm not a big fan in reinventing the wheel either
;-) and Ant has a fairly good Javadoc task readily available, so
unless you
> have endless time to spare, why bother?
Do you see the "Neither am I" in there? What I meant was that there's
a balance between purism and effort. We probably would like a native
Javadoc actor eventually but given the effort it would take to write
one, perhaps other things are more interesting and should have a
higher priority. The Ant actor will be retained in any case (hard to
remove once people has started using it).
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.
I think that we've made substantial progress. Both in Buckminster
project itself and in other projects (P2 especially but we've helped
ECF and PDE build as well) in order to improve the Buckminster offering.
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.
You managed Thomas Spiessens back then and he contributed the
Subversive support for Buckminster. That was an example of very good
cooperation within the community and how users can contribute to the
project. But besides Thomas contribution, none of your proprietary
extensions has been contributed. We don't know what "that stuff" is
since you haven't told us. Please enter bugzillas with enhancement
requests. That's the way to get things done.
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.
You shared some words with Ed Merks and myself about the subject and I
must agree with his final assessment. The start of that discussion can
be found here:
http://dev.eclipse.org/mhonarc/newsLists/news.eclipse.tools.buckminster-dev/msg00580.html
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 ant-script needed for signing is already bundled. You'll find
actions like "site.signed" and "site.p2" in cspecs generated for the
"eclipse.feature" component type. Page 135:
http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/doc/BuckyBook.pdf
And again, I'm not particularly fond of delegating to Ant and
Buckminsters use of it o may change over time. But getting rid of Ant
is not a top priority.
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.
I doubt that ECF will need to do that. AFAIK, Buckminster can build
ECF out of the box.
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.
Perhaps contributing them had been a better option? Chances are we
have had invited you (or the author) as a committer to the project in
order to maintain them.
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),
There won't be any major changes in the 3.5 codebase so you can safely
remain there and benefit from the bugfixes that we provide for 3.5.x
releases. We are keeping the API stable nowadays. It's not like it was
2 years ago when Buckminster had incubation status.
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.
So are we. And we are constantly improving both P2 and Buckminster as
we move forward.
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?
Markus, don't you have a build system in place for Buckminster already?
Kind Regards,
Thomas Hallgren
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
