buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <>
Subject Re: Replacing VERSION/REQUIRES with version/dependencies and using YAML files to pick versions of specific libraries
Date Wed, 17 Sep 2008 17:56:19 GMT
On Wed, Sep 17, 2008 at 12:44 AM, Victor Hugo Borja <> wrote:
> On Wed, Sep 17, 2008 at 1:57 AM, Victor Hugo Borja <>wrote:
>> [...] I'd also like something more qualified (and more rubyish..) like
>>    Buildr::Ant::version: 1
> What do you think about this:
> To let the user specify JUnit::dependencies without having to override the
> method:
> A build.yml having something like..
>  Buildr::JUnit::dependencies:
>    - junit:junit:jar:4.4
>    - jserious:jserious:jar:1.0
>    - jserious:jserious-tools:jar:1.0
> And on Buildr::JUnit @buildr/java/tests.rb:185
>      def dependencies
>        @dependencies ||=[name+'::dependencies'] ||
>            ["junit:junit:jar:#{version}"]+ JMock.dependencies
>      end

There were several requests to change the version of JUnit, my e-mail
archive has one request for JMock, and I remember one for TestNG
(can't find it, though).  So multiple requests by people who could use
the one-line setting feature to solve their problem.

Changing JMock to JSerious is an exercise we should leave for the
truly motivated. It's not a commonly requested feature, actually
nobody presented a use case for it.  Because it's hypothetical, I
don't mind if it requires a bit of open class gymnastics to solve.

test.using(:junit) includes the JUnit/JMock libraries by default.
Because they're included by default, the only way to switch to a
different version is by turning some switch that the framework uses,
in this case a setting in buildr.yml.  On the other hand, if you want
to include JSerious because you like it better, you can do that by
calling test.with, that's the more generic and common solution,

I want to avoid solving a problem that doesn't exist, even if we do
have a very elegant solution in the ready.

The main selling point of Buildr is that it's Ruby.  It's very easy to
make ad hoc changes, one-of features, with a few lines of code we can
share on the mailing list or the wiki.  Because it's DIY, we don't
have to anticipate and address every possible use case, especially
when some use cases have an audience of one, or audience of none.

Instead, we can just wait for enough people to point out the problem,
once we have a pattern we can extract the minimal solution that will
work for all of them.  Until then, Buildr is very self-service in
nature, take advantage of that.

Every feature we add has a cost.  A one-line change doesn't look like
much, but when you factor everything, it can be horribly expensive.
Besides the code, you have test cases.  You need to document it, the
more documentation we have, the harder it is for people to
find/remember which feature to use, so they spend more time being less
productive with Buildr.  We care about backward compatibility, that
makes changes much more complex as you need to support old usage along
with new one (*).  And, when you have to apply the same thing
consistently, multiply that cost several times over.

So the solution, even if it looks deceivingly simple, has to justify
itself by the number of people who actually feel the pain and don't
have an existing recourse.  It raises the bar for accepting new
features, but in the long term it helps us deliver more and better

Most important, it keeps Buildr from turning enterprisey too quickly.


(*) Half the code involved in these changes was written to retain
backwards compatibility, more than half the time spent figuring out
how to support the new methods and the deprecated constants, and turns
out it only partially works.

> --
> vic
> Quaerendo invenietis.

View raw message