ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Filter and Filtersets (was SQLExec and Properties)
Date Thu, 03 May 2001 12:15:15 GMT
OK, I will try to explain some of the issues here.

> From: Stefan Bodewig []
> Michael McCallum <> 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}?

The main point here is to be able to use, on the SQL task, SQL script files
that can work using the SQL shell scripts interpreters of major RDBMS
providers. (like MSSQL, ORACLE, etc.).

All of them use SQL as the basis for their language, but they all have their
own conventions about parameter passing in the scripts.
If we want to maintain just ONE set of files, we need to be able to pass
parameters to those scripts from ANT and we will need to be able to do
parameter substitution based on the particulars of the file syntax.

So since every sqltool has its own consistent way one needs something
flexible enough to support all of them. Hence the need to support &&foo,
&foo, @foo@, #foo#, or whatever else is needed.

> >> > 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.

Each tool is consistent on its own, but the task needs to be flexible enough
to allows for different users to use files consistent with different tools.
The point here is that you need a task that is flexible enough.

This may not be the only approach, I grant you that.

Here we are starting with the premise that you have SQL files for a
particular 3rd party tool, that you want to incorporate in your build.
Some of them may be yours to modify, but others may have been provided to
you by others.

We could say, NO, the correct approach is to start with files specific for
the ANT SQL task, (i.e., using ${foo} syntax) and then use some replacement
task to generate files specific to a particular tool. But, what do we do
with files provided by third parties? Do we need to maintain our own copies?
And how do we do the pattern replacement? The last I saw, replacement tokens
have a syntax that is incompatible with ${foo}.

So, what is for us SQL users to do?

> > 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.

Can your changes define a task of its own? Or do they affect the core of
ANT? Why can't your changes be put as a new task on its own? A subclass of, something like and let people try it.

After all, I can always replace one definition with another by just using
<taskdef name"sqlexec" classname="....InprovedSqlExec" />.

Jose Alberto

View raw message