buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Graduation process
Date Wed, 24 Sep 2008 01:01:26 GMT
On Tue, Sep 23, 2008 at 5:20 PM, Tal Rotbart <redbeard@gmail.com> wrote:
> Based on Alex's suggestion and the following comments, how about:
>
> "... that the Apache Buildr project be responsible for the creation and
> maintenance of a scripting-based build system based on the principles
> of DRY (Don't Repeat Yourself), convenience and flexibility."
>
> Short and sweet?

Yep.

I expect that the charter would constrain us in the direction we want
to go.  If the charter says "buildr system", then it's pretty clear
we're not going to build a 3D graphics engine.  But to constrain it
has to be somewhat generic, which is why I'd like to avoid discussing
specific features.  Multi-lingual is a feature we pay attention to
right now, but maybe we'll decide to stop at four languages and go
attend to something more important?

So the charter has to be a bit more generic, but that brings a second
problem: is it testable?  If it's not testable, how do we know we're
on the right path?  "Build system" is broad but testable.
"Scripting-based" is broad and testable.  It does open up the
possibility for other scripting language, so maybe it should be
"Ruby-based" or maybe it should remain no more specific than
"scripting-based"?

But something about the last three "DRY, convenience and flexibility",
I'm not 100% sure about.

I like the fact that in Buildr, if you need to copy a file and add an
SHA1 digest you just write a couple of lines to do that.  You don't
need to search for a pre-defined task or plugin or write one yourself.
 There's a bit more of the scripting/DIY/self-service/UNIX mentality
to it, that you won't see in XML-based build tools.  That's why it's
using a scripting language.

It's trying to minimize what you have to write to only that which is
"interesting" or specific to your build.  Buildr is not the first to
aspire to that goal, we just know it does a better job than Ant and
Maven.  That comes from being DRY, CoC, sane defaults, and using a
language that lets you express things concisely and dynamically.  I
think there's a bigger principle for that.

Like all other build system, we spend a lot of effort reducing your
buildfile into the shortest declarative definition of the build.  But
unlike other build system, we're not afraid to mix it with imperative
code.  The goal is to use declarative style when it adds value, not to
eliminate it altogether, and certainly not to force you into a mess of
configuration/profiles/goals/phases/plugins/properties all so you can
implement a simple if/else.

So to begin with, we need to decide if there are some general and
testable goals in these statements, if we think they capture the
spirit of Buildr -- I'm proposing these because that's what got me
started -- and is there any way we can write them into the short/sweet
statement you proposed?

Assaf

>
> Cheers,
> Tal
>
> On Wed, Sep 24, 2008 at 5:08 AM, Victor Hugo Borja <vic.borja@gmail.com> wrote:
>> Buildr builds your own build tool.
>>
>> The thing I like most of Buildr is that It's pure ruby, and as Assaf
>> mentioned, I think it is the
>> best selling point for it. Having the syntax+power of ruby to build complex
>> projects is awesome.
>> Also we get the most by having access to any Java API and ruby tools out
>> there.
>>
>> On Tue, Sep 23, 2008 at 1:35 PM, Matthieu Riou <matthieu@offthelip.org>wrote:
>>
>>> On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin <arkin@intalio.com> wrote:
>>>
>>> > On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <matthieu@offthelip.org>
>>> > wrote:
>>> > > On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <boisvert@intalio.com>
>>> > wrote:
>>> > >
>>> > >> Charter by triangulation:
>>> > >>
>>> > >> "... that the Apache Buildr project be responsible for the creation
>>> and
>>> > >> maintenance of build system, software configuration and software
>>> > lifecycle
>>> > >> management related tools."
>>> > >>
>>> > >
>>> > > I would say the net is too wide. Maven, Ant, Make or Rake could all
>>> > qualify.
>>> > > A bit of overlap is not necessarily a problem but that would be a
>>> > complete
>>> > > overlap. I'd look for something a bit more discriminating with wordings
>>> > like
>>> > > scripting based, multi-language or dependency management.
>>> >
>>> > +1
>>> >
>>> > Instead of aspiring to be another TLA, I think we should focus on what
>>> > makes Buildr better.  Scripting is the big differentiator, not any
>>> > specific feature (multi-lingual, dependency management, etc).  But
>>> > it's not a goal, it's the way we cut down on the boring and tedious
>>> > work, and make the rest easier and fun.
>>> >
>>> > Builds tend to be very repetitive for the most part, but also very
>>> > specific with a lot of one-of and ad hoc customization.  No two builds
>>> > are the same, snowflakes and such.
>>> >
>>> > So one thing you need in a build system: convenience, framework that
>>> > does the heavy lifting, defaults, reusable components, all standard
>>> > fare that cuts down on repetitive work and boilerplate.  When you
>>> > write compile.with my_depends there's a lot of stuff happening in the
>>> > background to take care of business.
>>> >
>>> > On the other hand, Buildr is very self-service: you should be able to
>>> > solve every build problem without waiting for the next release,
>>> > without struggling with pre-fab components and their limited
>>> > configuration.  That's why underneath there's a scripting language,
>>> > let imagination be the limit.
>>> >
>>>
>>> Thats going to be a long charter ;)
>>>
>>>
>>> >
>>> > Assaf
>>> >
>>> > >
>>> > > Ant has its resolution on its web site and I fished the Maven one from
>>> > what
>>> > > feels like another century, when the board meetings where much shorter
>>> > than
>>> > > now:
>>> > >
>>> > > http://ant.apache.org/mission.html
>>> > >
>>> >
>>> http://www.apache.org/foundation/records/minutes/2003/board_minutes_2003_02_26.txt
>>> > >
>>> > > IMO they're both very good examples of what we shouldn't do :) Both
>>> > reflect
>>> > > an older time when the foundation was much smaller, we should know
>>> better
>>> > > now.
>>> > >
>>> > > Matthieu
>>> > >
>>> > >
>>> > >
>>> > >> alex
>>> > >>
>>> > >> PS: I don't like the definitions of SCM and SLM in wikipedia. 
They
>>> > sound
>>> > >> like they were written by vendors with a very narrow vision.  
You
>>> could
>>> > >> say
>>> > >> SLM has almost become a euphemism for Enterprise Grade DRM <tm>.
>>> > >>
>>> > >>
>>> > >> On Tue, Sep 23, 2008 at 8:54 AM, Matthieu Riou <
>>> matthieu@offthelip.org
>>> > >> >wrote:
>>> > >>
>>> > >> > Hi guys,
>>> > >> >
>>> > >> > So it seems that everybody agrees it's time to get ready for
>>> > graduation.
>>> > >> > There's a nice guide that details the whole process here:
>>> > >> >
>>> > >> > http://incubator.apache.org/guides/graduation.html
>>> > >> >
>>> > >> > The trickiest part is to prepare a resolution for the board
to
>>> adopt.
>>> > >> > Ultimately, that's what we will vote on, what the incubator
PMC will
>>> > vote
>>> > >> > on
>>> > >> > and what the board adopts. And the trickiest parts in the
resolution
>>> > >> itself
>>> > >> > are:
>>> > >> >
>>> > >> >   - The target: Top Level Project or subproject of another
TLP. For
>>> > >> buildr
>>> > >> >   I think it would be TLP but if someone things otherwise
it's a
>>> good
>>> > >> time
>>> > >> > to
>>> > >> >   mention it.
>>> > >> >   - The charter: this should define the scope of the project.
It
>>> > should
>>> > >> be
>>> > >> >   short, sweet and non ambiguous but sufficiently large in
scope to
>>> > cover
>>> > >> >   further expansion of the project. So getting the proper
wording
>>> can
>>> > be
>>> > >> >   tough. There are example here [1] and if you want more I
can point
>>> > you
>>> > >> to
>>> > >> >   others.
>>> > >> >   - The project chair: I'll send another e-mail about that.
>>> > >> >   - The future PMC: actually that's the easiest, it's usually
the
>>> same
>>> > >> >   composition as the PPMC.
>>> > >> >
>>> > >> > So at this point, it would be nice if someone drafted a first
>>> charter
>>> > >> > paragraph so we can increment from it. The rest of the resolution
>>> can
>>> > >> > easily
>>> > >> > be created using the charter and a few names.
>>> > >> >
>>> > >> > Thanks,
>>> > >> > Matthieu
>>> > >> >
>>> > >> > [1]
>>> http://incubator.apache.org/guides/graduation.html#tlp-resolution
>>> > >> >
>>> > >>
>>> > >
>>> >
>>>
>>
>>
>>
>> --
>> vic
>>
>> Quaerendo invenietis.
>>
>

Mime
View raw message