ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCallum" <mich...@spinsoftware.com>
Subject Re: Filter and Filtersets (was SQLExec and Properties)
Date Wed, 02 May 2001 19:50:20 GMT

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

> Michael McCallum <gholam@xtra.co.nz> wrote:
> 
> > On Wednesday 02 May 2001 08:31, you wrote:
> >> Michael McCallum <gholam@xtra.co.nz> 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

Mime
View raw message