On 8/21/01 4:06 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
>
> The first definition of a property wins -- that is understood. Now, play
> the following scenario (real life for me right now):
>
> * In ${user.home}/build.properties, I've defined my "commons-foo.jar"
> to point at the released version of the foo package, because that is
> what I generally want to use in my builds.
Ok, with the way we do things the jar properties are defined at the project
level. Hmmm, I'll ponder that one, but I think that ~/build.properties
should have the final say on any value set.
> * In building this particular component, I need to use hot-off-the-presses
> CVS code because I use features added since the release, so I override
> "commons-foo.jar" in my component-local version.
>
> Using your ordering, my override does not take effect -- putting the "user
> local" import third lets me do it.
Yup, I see. With the other ordering it doesn't work with the lib.repo thing.
Hopefully we'll work this out when JJAR is rolling.
> Craig
>
>
>>
>>> The check-available stuff is a nice addition.
>>>
>>> Craig
>>
>> --
>>
>> 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
>>
>>
>>
--
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
