On Tue, Sep 23, 2008 at 5:20 PM, Tal Rotbart <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]
>wrote:
On Tue, Sep 23, 2008 at 11:08 AM, Assaf Arkin
<[EMAIL PROTECTED]> wrote:
On Tue, Sep 23, 2008 at 10:44 AM, Matthieu Riou <[EMAIL PROTECTED]
>
wrote:
On Tue, Sep 23, 2008 at 8:59 AM, Alex Boisvert <[EMAIL PROTECTED]
>
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 <
[EMAIL PROTECTED]
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.
