Assaf Arkin wrote on 07/30/2009 12:15 AM:
On Wed, Jul 29, 2009 at 1:49 PM, Martin Grotzke <
martin.grot...@javakaffee.de> 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
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.
where is the part where it finds the jar inside the zip and extracts it?
ittay
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
--
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>
