ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Christoph Wilhelms)
Subject RE: Antidote Implementation [PROPOSAL] for: fileset
Date Fri, 09 Mar 2001 21:05:29 GMT
Hi Sim!

Ok, Unfortunately I generally have an opposite opinion on some items you

1st thing my opinion differs from yours in case of the tree - I think the
tree should contain nearly everthing, for XML-files hava a tree structure -
ever opend an .xml in MS Internet Exporer 5.x ? Do you know the netbeans
IDE? Everything is in the tree, and people are used to it! It would be nice
if Antidote look familiar ;-)!

2nd: You say that we need ACSElements for EVERY Task - IMHO This would be a
mess for Antidote :-(. Nobody (or at least I don't ;-)) wants to implement
an ACSElement everytime a new Task has been submitted! I'd propose to become
MORE generic! Ok, tasks to not implement a FileSetUser interface OSTLT, but
we can ask targets yia reflection if they have a "addFileset",
"createInclude", "setIncludes", "createExclude", "setExcludes" method and we
can find attributes by looking for set-methods... It'll be hard, but
possible - and it is a chance! And of course for there are no conventions
this will not cover EVERY case but 90%+, I hope!

I'd like to hear what others say... :-)!


Here is what Simeon wrote:

> I had a side discussion what to implement next in Antidot; Sim pointed
> that filesets are still missing, so here is my proposal!
> 1st: I think we need at least one new ToolbarButton/ContextMenuItem: New
> Fileset (or something like that, wich just is enabled when a node is
> activated where fileset is a valid option.

To make this possible we will have to start creating ACS classes with
their associated BeanInfo classes for each of the tasks. Right now all
tasks are covered by a generic ACSTaskElement class, which treats all
tasks the same (as attribute containers; not very elaborate). It's
probably time to start providing more sophisticated editing of each of the
tasks. This, unfortunately, is where Antidote would have benefited from a
more consistent set of API conventions in the task implementations.
Obviously we will run up against maintenance issues as tasks change and
evolve over time. It's too bad that the tasks that use filesets don't
implement a "FileSetUser" interface (or the like).

> Do we need another
> Button/MenuItem for "Add Include" or should this function should
> be provided
> by the PropertyEditor???

My current feeling is that it should be done via a property editor,
requiring us to have a fileset type that is referenced in the appropriate
BeanInfo classes. But I'm somewhat on the fence with this one. I certainly
don't think you should be able to add filesets to things that shouldn't
have them, and the best way I can think of right now to limit that is via
the BeanInfo approach.

> 2nd: An extension of the project tree is needed:
> project
> |
> +-property
> | |
> | +-fileset
> |   |
> |   +-property/include
> |
> +-target
>   |
>   +-task
>     |
>     +-fileset
>       |
>       +-property/include

If the fileset is represented as a class like "ACSFileSetElement", then
this comes for free. But I'm also on the fence here as to whether that is
just too much detail in the tree view. Already I think showing properties
in the tree view is not a good idea (and some other mechanism is needed),
and I feel that adding filesets will make it even more unmanageble. It all
really depends on how good a fileset property editor ends up being.

> 3rd: The PropertyEditor can look like the task-propertyeditor.

Version 1 yes (that's where a generic Object[] editor would help). I think
later it would be nice to extend it to help with glob generation and path

> BTW: Can one Task/Property contain multiple FileSets?

It it can, should we allow it?

> Implementation:
>   New Ant Construction Set Elements:
>     ACSFilesetElement (similar to ACSTaskElement)
>     ACSIncludeElement (similar to ACSPropertyElement)
>     and the BeanInfoClasses belonging to the Elements
>   PropertyEditors:
>     IncludesPropertyEditor

Probably FilesetPropertyEditor instead, which takes care of adding the
includes/excludes to the fileset.

>   Command Classes:
>     NewFilesetCmd
>     NewIncludeCmd

If adding these is done via a property editor, they probably aren't

>   Events:
>     NewFilesetEvent
>     NewIncludeEvent

Looks good to me, although I'd go ahead and add exclude as well.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message