buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grotzke <>
Subject Re: Quick Start Documentation
Date Wed, 29 Jul 2009 21:43:56 GMT
On Wed, 2009-07-29 at 14:15 -0700, Assaf Arkin wrote:
> On Wed, Jul 29, 2009 at 1:49 PM, Martin Grotzke <
>> wrote:
> > On Wed, 2009-07-29 at 12:35 -0500, Daniel Spiewak wrote:
> > > >
> > > > forgive my ignorance, but how exactly does buildr do that? i can see
> > that
> > > > you can download a file from a given url, but where is the code that
> > digs
> > > > into a zip to extract a jar from it?
> > >
> > >
> > > Don't ask me how Buildr does it, but somehow...  Probably just on the
> > > strength of Assaf's brilliance.  The code shown in the
> > quick_start.textile
> > > will download DBPool and auto-extract the JAR from the zipfile,
> > installing
> > > it into the local repository.  I actually copy/pasted that code from a
> > > buildfile I have used in the past which used exactly that functionality.
> >  It
> > > really works.
> > I asume most of the ant users (except for those that are using ivy) are
> > used to store jars locally in some lib/ directory, and then keep a list
> > of compile-libs and run-libs in the build.xml. For those kind of people
> > it's hard to trust the "magic" (hell?) of maven dependencies, and also
> > to depend on the fact, that you have connectivity. Additionally, they
> > want to make sure that no SNAPSHOTS are used, as otherwise there's the
> > possibility of different versions of jars on different build/developer
> > machines. All this throws in a lot of indefinite things a successful
> > build depends on.
> Assuming that you don't care much for the Maven way of doing things, you can
> just place all your dependencies in a lib directory and point to them
> directly. This works in Buildr the same way it works in Ant (compile.with
> file1, file2, file3).
Yes, I know, and that was a selling point for buildr to my colleagues :)

>   You can also download files directly from a given
> URL, extract the from a ZIP, etc.
> The download(artifact("...")=>url) construct looks magical, but it certainly
> is deterministic. artifact defines a task with late action that will
> download the file from remote repository (if doesn't already exist).
>  download defines a task with one action that will download file from
> specific URL (if doesn't already exist).
> Both refer to the same task (artifact returns file task which is used as
> target argument for download), so they both enhance.  The download action
> happens first (since the artifact action is wired to happen last), and it
> either:
> - doesn't do anything because the file exists
> - downloads it from the URL
> - fails
> Running that task has two possible outcomes, either file is there or it
> fails, and one possible state transition from no file to file being there.
Right, that's completely transparent and understandable. Then what's the
logic for extracting the artifact (jar) from the downloaded zip archive?
Is there any naming convention, directory structure or anything that has
to be fulfilled that this works?

But honestly, even if it's completely deterministic, I think it's
important what impression the user gets of buildr when he's reading the
quickstart. And if the impression of the reader is that there's also
lots of magic in buildr (like it's in maven) and that things are not
really transparent/understandable, I would think that lots of people
won't trust buildr and won't use it.

In the beginning exactly that was why I was really happy that the
quickstart was born: a short and quick summary that shows how easy and
understandable buildr is. No magic, no risk, just a simple to understand
and simple to use build tool.

My critics concerning the magic definitely is also caused by the company
I'm currently working in. In this company it's really important that we
push every release at the defined release date (nothing special I'd
say). Any risk that might compromise this is eliminated. And if it's the
build tool that might be a risk then it's replaced by that can be
controlled completely. That's the reason, why lots of projects are still
built with ant, even if it's more loc (or lox - lines of xml :)) to
write for the build. IMHO buildr is the best build tool in the world,
but it has to be sold/propagated cautiously, with the different kinds of
users out there (and my colleagues) in mind :)


> Assaf
> >
> > If then the build tool itself additionally does things that are not
> > really deterministic (are they?), the build feels even more magically
> > and less trustworthy. That's the reason why I would not propagate this
> > feature in the quickstart, or at least it should be clear that it is
> > definitely deterministic and no magic at all.
> >
> > I think no one wants to depend on magic for a successful build, and from
> > my experience that's where a lot of maven critics comes from. A simple,
> > comprehensible and reproducable build is the goal IMHO.
> >
> > So, again, I'd vote for mentioning that buildr can do lots of stuff and
> > link to appropriate places.
> >
> > Cheers,
> > Martin
> >
> >
> > PS. if you definitively want to mention that buildr can download and
> > extract artifacts, what about a sentence in the tip like "and if you
> > want, buildr can even download a zip file and extract the artifact for
> > you - less work for you! (See magic explanation <link>here</link>)"?
> >
> >
> >
> > >
> > > Daniel
> >

View raw message