On Wed, Jul 29, 2009 at 2:20 PM, Ittay Dror <itt...@tikalk.com> wrote:
>
>
> 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?
I didn't know there's a part like that.
Assaf
>
>
> 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>
>
>
>
