ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Creating Filesets based on file contents
Date Mon, 15 Oct 2001 10:02:53 GMT

You have almost described exactly what I want to do in Ant2 context for this 
sort of stuff except you have better terminology ;)

Heres how I see I see it the FileSet functionality id made up of the 
following concerns.

1. Generate a list of items, where each item has attributes.
2. Select a set of items from candidates
3. Transform set of items to destination

In the case of of FileSet the items are files (or ZipEntrys in some cases) 
and the only attribute we look at is "name" or "designator". Stage (1) occurs 
in Scanners and they essentially generate a list of file names. 

Stage (2) is left up to task, most have default excludes or only include 
desired files (ie **/*.java in case of javac). However we have talked about 
separating them out and there has even been a patch to add this functionality 
to ant though it used the terminology "Culler" (search archive for 
references). And I think we have universally agreed that it will be present 
in Ant2. However I like your terminology (selector) *much* better ;)

Some other selectors you may consider include selecting based on whether file 
is readable, writable, under a specified size, altered after a specified date 

Stage (3) we partially have now. Mappers transform one attribute "name" but 
leave rest of functionality up to task. I tried to convince Stefan to 
increase mappers to work with other attributes but failed so we will probably 
have some other mechanism for general purpose item transformation.

Hopefully all this will be provided in the Ant2 framework and writing tasks 
to use this will be a piece of cake. You should even be able to hook it into 
the dependency service and have it automatically apply different dependecy 
strategies as a further "selector".

On Mon, 15 Oct 2001 19:08, Jesse Glick wrote:
> Magesh Umasankar wrote:
> > I have hacked some code so that we would be able to
> > create a patternset/fileset based on the contents of
> > the file.  For example, we can do:
> > [snip]
> I did something similar recently (not based on contents but CVS status):
> Writing the FileSet subclass was not so much of a problem, as how to use
> it. As written in a bug I filed recently, <typedef> did not seem to get me
> anywhere and I needed to modify tasks I wanted to use with it:
> public void addCvsFileSet(CvsFileSet fs) {
>     addFileSet(fs);
> }
> Clearly putting additional behavior like this into plain FileSet is out of
> the question, some extensibility mechanism is needed. How do you extend
> such things? I assumed there would be some kind of data type like
> <selector> that you could use, along the lines of <mapper> which is not
> quite right for this purpose:
> <copy todir="...">
>     <fileset dir="...">
>         <include name="..."/>
>         <selector type="org.netbeans.nbbuild.CvsFileSet"
>                   criterion="text"/>
>     </fileset>
> </copy>
> This would create a new CvsFileSet instance, cast to
> or whatever, initialize it with a
> generic argument setCriterion("text"), and use it to filter out non-text
> files.
> Unfortunately there does not appear to be any such construction, as there
> is for <mapper>s. Should there be?

Hell yes ! ;)

> One nasty problem I see with the pluggable mapper system is that there is
> no way for a custom mapper class to be configured using richer data than a
> String for 'from' and a String for 'to'. Specifically it cannot use
> additional attributes, subelements, etc. This is a basic limitation of
> Ant's system of introspection and XML configuration as far as I can tell.
> Maybe something like <mapperdef/> would be a better solution: add to the
> "namespace" of mapper elements, so instead of writing:
> <copy ...>
>     <mapper type="glob" from="*" to="*.orig"/>
> </copy>
> you would write:
> <copy ...>
>     <globmapper from="*" to="*.orig"/>
> </copy>


Thats how I was talking about and prototyped doing it in the context of Ant2.

> (Possibly plain <typedef/> could do instead of <mapperdef/>.)


Thats also in the proposal ;)

> Somehow the
> Copy task would need to indicate that it could accept any subelements with
> a defined name whose class is assignable to FileNameMapper. The task could
> have:
> public void addGeneric(FileNameMapper mapper);
> where the keyword "generic" means to actually look in the name -> type
> mapping for the actual sub element names. Only the add- and not
> create-variant of this method could be supported of course. The same
> mechanism could be useful for other purposes, esp. the EJB tasks I think.

I don't think generic keyword is needed. We just need to discover that 
parameter is an interface and behave appropriately. The proposal I built did 
this fine ;)



"The only way to discover the limits of the possible 
is to go beyond them into the impossible." 
                             -Arthur C. Clarke

View raw message