Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
From: David Rees <reesd.l@ubiqsoft.com>
To: ant-dev@jakarta.apache.org
Subject: Re: [PROPOSAL] Ant2 Files/FIleSets/Cullers (long)
Date: Thu, 19 Apr 2001 22:58:43 -0700
Reply-To: reesd.l@ubiqsoft.com
Message-ID: <6civdt4a631gqg2bensemucjq42v3g9et2@4ax.com>
References: <ciendtc25c6q0vlhs85ihu9koj1fr3j6bb@4ax.com>
 <3.0.6.32.20010420142201.00a2bd80@mail.alphalink.com.au>
In-Reply-To: <3.0.6.32.20010420142201.00a2bd80@mail.alphalink.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On Fri, 20 Apr 2001 14:22:01 +1000, Peter Donald wrote:

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

Well that is a gratifying way to start a response ;).

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

absolutely

>>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.=20
>
>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).
>

that is fine and in fact better represents what is going on

>>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=20
>  ...
>}
>

Not sure exactly what you are saying, so here is what I am saying:=20
there needs to be a place to register things that will be called in a
finally at the completion of each task. Sort of a finalize() at the
task level. This finally block needs to be called for all tasks
outside of the task developer code because a task developer is not
aware of the AntFiles (and their handles) that will be used in his/her
task.

Its possible that the proper scope might be target or file as well.
Perhaps based on the scope of the handle (in this case the scope of
the AntFile).


>>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=20
>>
>><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 ;)
>

If I am understanding you, you are suggesting that you would have a
setCopyFileSet() and setDeleteFileSet() and the XML would look like
<CopyAndDelete>
<CopyFileSet ... /> "files to copy"
<DeleteFileSet ... /> "files to delete"
</CopyAndDelete>
the problem I see with that is that there is no way to use a sub-type.
The set/add/create methods currently (IMO) do not distinguish between
type and attribute/sub-element name.=20

>>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.=20
>
>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.=20
>
>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).
>

I agree that if we can find/steal/adapt an existing one we should. I
also agree that it would have usefulness beyond Ant (I kind of planned
that part). I will look around for a JSR or something on other VFSs.
If anyone knows of one please post here and/or email me. Here is what
I have so far:

I found the JSR which is 51. However, they have yet to post any
specifications. I've sent the expert group an email to see if I can
get any information.
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_051_ioapis.html

The Sun WebNFS proposal has support at the URL level which plugs
nicely into the above and also has an "XFile" proposal which might be
close to what we want. I will take a look at it and report back. For
some reason the download isn't working this evening.
http://www.sun.com/software/webnfs/ds-webnfs.html

The samba project is using/references the WebNFS XFile proposal which
is another vote in its favor.


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


Thanks for the comments.

d