ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [PROPOSAL] Ant2 Files/FIleSets/Cullers (long)
Date Fri, 20 Apr 2001 04:22:01 GMT
Hi,

Excellent - someone else who agrees with the things I been preaching about
for ages ;)

At 08:54  16/4/01 -0700, David Rees wrote:
>Ant2 File/FileSet/Culler Proposal
>By: David Rees (dave@ubiqsoft.com)
>2	Ant2 Design Assumptions
>This proposal depends on a few features being available in Ant2. I
>also feel they are good ideas in general.
>
>2.1	Element Sub-Types
>Ant2 needs to provide support for the transparent use of a sub-type
>where a type is expected. The methods of a element should not have to
>be extended just to support new sub-types.
>
>This is needed for this design to support addition of new AntFiles and
>other items without having to change the many elements that use them.
>
>For purposes of the below design I will assume that if a element
>accepts A (addA() or seta()) it will accept subclasses of A.

Agreed - even better - in setA( Type a ) where Type could be an interface
etc. (A feature that used to be requested a lot ... but not so much anymore).

>2.2	Element Creators
>Ant2 needs to extend the framework of IntrospectionHelper to support
>creators for types. In general, a creator is a static method or a
>Factory class that is used to create the instance of a type. This
>allows the actually class created to be a sub-type of the class that
>the IntrospectionHelper expects. Note that constructors could be still
>be used as a fallback if a type does not support the creator API.

It is not necessary for this to be part of the engine because the actuall
task can discover it. This could be implemented in much the same way that
container tasks will be implemented.

>2.3	Type Registry
>Ant2 needs to support a registry of types and elements. 

Hell yes !!!!

It is essential if we want to have any decent (ie non-hardwired) extensible
(without spit and glue) system. In my proposal (proposal/myrmidon) I
actually had 2 registries - one registry for tasks and one for datatypes.
In hindsight this was not really necessary as a single registry would be
sufficient.

>This registry needs to support inheritance.

I don't see this as desirable. Instead I would like to see it supporting
"roles". So you could ask for type "org.apache.ant.datatypes.AntFile" using
hint "ftp". This way you don't have to worry about inheritance (which can
be complex) but you still get to deal with separate roles. FWIW this is the
architecture of Cocoon2 and it works for them ;)

Using "roles" and "hints" is basically a radically simpler version. (And it
conforms to the Coponent Orientated Programming model).

>2.4	Finalization/Handle Registry
>Ant2 needs to support a registry for handles that need to be finalized
>at the end of a task execution.
>
>This needed for this proposal to close FTP, File, HTTP and other
>handles that are opened for AntFiles.

I am not sure this needs to be supported outside task. We can have the
following instead which keeps engine clean.

try
{
  //do work here
  ...
}
finally
{
  //do cleaning here 
  ...
}

>4.1	Auto-Inclusion of Sub-Elements
>Some Ant1 types include their sub-element and support the sub-elements
>attributes and sub-elements in their own API (FileSet in Copy).
>Personally I would rather force people to do extra typing, but if we
>did want to support this then I would suggest we support
>auto-inclusion where a element can indicate it auto-includes a
>sub-elements type and then Helper would do all the work. As a possible
>example includeType() instead of add/createType.

-1 for magic behaviour - we should support one method (my preference would
be setType()) for all things - including attributes and sub-elements.

>4.2	Named Sub-Elements and Attribute/Sub-Element Equivalence
>Generally it seems that in many cases an attribute and a sub-element
>are used for the same thing. Also, it is possible for the same type to
>be included for different "types". The problem is that there is no way
>(that I know) to indicate the "name" of included element. For
>instance, in the following contrived example here is no way to
>indicate 
>
><CopyAndDelete>
>  <FileSet ... /> "files to copy"
>  <FileSet ... /> "files to delete"
></CopyAndDelete>

Sure you can you can just name them different things in the set/add/create
methods ;)

>5	AntFile
...snip Virtual File System blurb...

Yes it sounds really kewl ... but I suspect it maybe overkill or at least
duplicating work already done. There is already a number of VFS specs and
implementations about. 

There is one included with the opensource version of forte IIRC (forget
name of project atm), sun also has a specification you can implement for
remote files (they use it for their NFS in java API, as does
jcifs.samba.org IIRC) and finally there is supposed to be one coming out
with java1.4 (the extended io API). If at all humanly possibly I would like
to use one of these existing APIs (or even a generic one like JNDI) and
possibly their implementations. If for some reason this is not possibly I
think it could be best to implement the VFS in jakarta-commons-sandbox so
other projects will reuse it. 

For instance TC and AvalonPhoenix both access directories and jars
transparently to get to their .war/.sar files. I suspect slide could also
benefit from it (and maybe other projects). It would be widely used I
believe (FWIW over the course of 4 years I have developed three different
VFSes for three different products).

>7.3	Developing Cullers
>Additional FileCullers can be added easily by creating a class that
>implements the Culler API of shouldCull(AntFile).

+1 (And these culler classnames can live in registry aswell)
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message