On 2 May 2001, at 14:23, Stefan Bodewig wrote:
> Michael McCallum <[EMAIL PROTECTED]> wrote:
>
> > On Wednesday 02 May 2001 08:31, you wrote:
> >> Michael McCallum <[EMAIL PROTECTED]> wrote:
>
> >> > The sql patch does not do anything execpt add a call to
> >> > filterset.replaceTokens( sql )
> >>
> >> Why use filters instead of property substitution for this?
> >
> > Because the substitution occurs for all sql statements even those
> > coming from file.
>
> Why couldn't you do this with properties? I think we are consistently
> using property expansions except when copying files and I'd like to
> keep it this way.
I see what you are saying. But you still need some way of specifying which set
of properties you
wish to use. Just saying do a property expansion is not enough as i may want ot
expand X
tokens in file A and X + C tokens in file B.
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.
>
> When you invoke filterset.replaceTokens(sql), how is this different
> from ProjectHelper.replaceProperties(project, sql, project.getProperties())
> - from the point of functionality, you are replacing one pattern with another.
>
> I guess, I'm missing something obvious.
no good point.
>
> > 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.
>
> Why not? To me filters are restricted to the filtered copying of
> files - and I'm even thinking about removing them for this purpose as
> well, like
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).
Using property sets in a token replacement mechanism would be fine.
>
> <copy ...>
> <filterset>
> <property name="prop1" />
> <property name="prop2" />
> </filterset>
> </copy>
>
> where each occurrence of @prop1@ would be replaced with the expanded
> ${prop1}. This is just a random thought.
Thats fine, as long as the power is there. ie must have the ability to specifu
@ and @.
You would need to be able to group all filters that came from a file as one set
as well.
>
> Here we are getting at the point where my main concern with your
> filterset patch originates from. We have decided to give people more
> control over the filtering that happens when copying files - we've not
> decided how we would do that yet.
>
> 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.
I think that the users have the idea that they will need to do a little bit of
rethinking before they
move to Ant 2. I always believe that too much information can never hurt and if
they have to
backtrack a little or find something works the same but is now called something
different they
will get there and benefit from finding the way.
One thing I cant stand is spoon feeding. I require that people always think
about the process
and if a little confusion makes them think a little more next time well thats
all good.
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 could split it all up into patches for Project, copy,
> >> > DefaultCompilerAdapter, Filter, SQLExec etc if you would like.
>
> I've just browsed over the original patch to find out what you've been
> doing with <javac> here (as filtering has gone away with the copying
> of support files in Ant 1.2).
>
> You want to apply filtering to the output from javac? Why? I'd
> prefer to see what an error message really looks like 8-)
Because 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.
So i made a replacement of the /usr/local/build with /usr/local/src/ possible
with the filtersets.
Ok its hacky but it solved my problem. Anyone trying to build a subset of a
source tree will have
problems like I did with compilers dragging in sources not specfied for
compilation and without
dependencies. (just decided they were in a package so should be compiled as
well. I have seen
javac and jikes do this.)
Michael
