ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simeon H.K. Fitch" <>
Subject RE: Antidote Implementation [PROPOSAL] for: fileset
Date Sat, 10 Mar 2001 15:43:22 GMT

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



View raw message