buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: Quick Start Documentation
Date Wed, 29 Jul 2009 21:15:04 GMT
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).  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
- 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.


> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message