ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Filter and Filtersets (was SQLExec and Properties)
Date Thu, 03 May 2001 11:03:44 GMT
Michael McCallum <michael@spinsoftware.com> wrote:

> It is not enough either to just use expansion of ${foobar} it has to
> be flexible. ie need to be able to replace @foobar@ and #foobar# and
> anything else you might consider.

Where do these @foobar@ things come from?  I.e. why can't they be
${foobar}?

> On 2 May 2001, at 14:23, Stefan Bodewig wrote:

>> > I do not believe that property replacement should be carried out
>> > on file loaded sql.
> Yes it should it is absolutely necessary when running the scripts
> using other tools like sqlplus they have their own file substitution
> patterns that ant needs to be flexible enough to work with.

I don't understand this, sorry.  You say, you have a tool that
performs some substitution that follows either @foobar@ or #foobar#
convention (but not consistently) and want Ant to adjust to this tool,
right?  Excuse me, if this is a dumb question, I've never used sqlplus
- I'm a DB2 guy with some occasional project using Interbase or MS SQL
Server.

> I guess what Im saying is the the use of a token replacement
> mechanism should be standard.  Which we could use properties for (I
> just thought that the filter task was hackish so improved it).

Agreed on everything you've said (including the "filter was hackish"
part 8-).

>> If we add filtersets in Ant 1.4 but decide to drop filters
>> completely, change the concept in some other way, we are going to
>> confuse users more than we need to do.  I'd simply prefer to see
>> how we are going to change it in Ant2 - and I'd like to take your
>> filterset concept as one proposal to achieve it.

> One thing I cant stand is spoon feeding.

Sorry, my English language parser has left me - "untranslatable metaphor"
8-)

> Plus you have a solution that may not be perfect but people will get
> to try it out and give feedback. So you can either improve the
> concept or discard it for Ant2. But sitting the code on the fence
> does not achieve anything except we sit around and discuss it merits
> and then the users use it in completely unexpected way later.

I guess I see us much closer to agree on how we want something to work
in Ant2 than you do.  I expect this to happen in a few weeks (prior to
an Ant 1.4 release), but I may be wrong.  I'll be pushing for it.

> if I copy files from root /usr/local/src/foobar to
> /usr/local/build/foobar and then there are compile errors all ides i
> have seen will let me easily open the file in
> /usr/local/build/foobar and not the file in /usr/local/src/foobar.

Use case understood, thanks.

Stefan

Mime
View raw message