On Friday, May 31, 2002, at 01:08 PM, Steve Loughran wrote:
> ----- Original Message -----
> From: "Scott Ellsworth" <[EMAIL PROTECTED]>
> To: "Ant Users List" <[EMAIL PROTECTED]>
> Sent: Friday, May 31, 2002 12:22 PM
>
>> On Friday, May 31, 2002, at 10:51 AM, Steve Loughran wrote:
>>
>>> ----- Original Message -----
>>> From: "Christian Wolfgang Hujer" <[EMAIL PROTECTED]>
>>> To: <[EMAIL PROTECTED]>
>>>
>>>> I think the driver attribute of the SQL task should be optional, not
>>>> required. It is possible to load a JDBC Driver using the
>>>> -Djdbc.drivers property,
>>>
>>> we are trying to move away from all the magic properties, so no, I
>>> think it should stay as an attribute. Also, in my experience, the
>>> driver is often application dependent, so that I have different
>>> drivers for each app and the db they talk to.
>>
>> The nice thing about having it be a property is that you can always
>> grab an environment variable to fill out that property within ant, and
>> depending on how you write your build.xml, the environment can either
>> override or be overridden by properties specified by the user.
>>
>> <property file="user.properties">
>> <property environment="env">
>> jdbc.drivers = env.jdbc.drivers
>>
>> which will mean that if the user sets it in user.properties, they get
>> that one, regardless of the environment variable. By reversing the
>> order of the property tasks, you get the other behavior.
>
> yeah, but you get the same effect with
>
> <sql driver="${jdbc.drivers} />
Right - I was unclear. Perhaps I should have said it as "The benefit of
having it be a standard property supplied to the attribute, rather than
a magic property which cannot be easily altered by the user, is that one
can then set that property by a variety of ways, including reading from
the environment.
Scott
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
