--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
------ Forwarded Message
From: Jason van Zyl <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2001 14:24:33 -0400
To: Vincent Massol <[EMAIL PROTECTED]>
Subject: Re: Central Repository for JARs
On 8/8/01 2:08 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote:
>>
>> I use build.properties for everything
>>
>> ~/build.properties
>> <project>/build.properties
>
> good for you ... :)
> but again don't assume everyone uses them ... focus on Ant properties
> instead. Your properties in build.properties are ant properties in the end
> ...
Ah, do you use .ant.properties? I consider what's in build.properties to be
ant properties.
>>
>> There is an order in which the properties files are loaded that must be
>> followed in order for things to work correctly. Again I need to finish the
>> example so people have something to look at.
>
> why don't you do it as I have proposed ? It looks fine and simple to me.
I actually don't understand what you're saying.
>>
>>>>
>>>>> In other words, I would still keep the Cactus build.properties but the
>>> paths
>>>>> within it will point to the JJAR repository directory instead and I'll
>>> just
>>>>> have to add a call to the JJAR task in my init target.
>>>>
>>>> You would have something like:
>>>>
>>>> velocity.jar = ${lib.repo}/velocity-1.2.jar
>>>
>>> this is what I don't like. How do I specify the latest version of the
>>> velocity jar ?
>>
>> We could get gump to build velocity-latest.jar and put that into the
>> repository as well though I think it will always be the case that a
> project
>> binds to a version.
>
> nope ... velocity-latest is the same as velocity-1.2, it contains version
> information in the name! :)
How would you know that velocity-1.2 is the latest for sure?
>>
>>>>
>>>> The ${lib.repo} property should be setup, and hopefully can be done
>>>> automatically at some stage.
>>>
>>> no, manual is fine.
>>
>> Manual is not fine for an automated build system. It won't work if people
>> have to stop and edit things. That's what I don't want. Just grab a
> project
>> from CVS and build.
>
> No you don't understand what I mean. What I mean is that choosing wheer
> lib.repo is located is part of Ant configuration (and thus up to the build
> writer), not of jjar !
That's what I'm saying. As a user of ant you decide where you want to put
the jars. I think we're on a different wavelength. Where ${lib.repo} is
located is fully up to the user of ant. I'm definitely not advocating a
standard location like /usr/local/jjar or C:/jjar or anything like that.
>>
>>>>
>>>>> And everyone building
>>>>> Cactus will need to ensure that the JJAR task is in Ant (it should be
>>>>> possible to test for it and not do anything if not in the classapath,
>>>>> though). Is that right ?
>>>>
>>>> Yes, hopefully taking care of having ant with JJAR can be handled
>>>> automatically. I would like to make the process as transparent,
> seemless
>>> and
>>>> easy as possible.
>>>>
>>> -Vincent
>
>
> -Vincent
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
------ End of Forwarded Message
