Re: why rmic task doesn't support selector?

[Bruce Atherton <br...@callenish.com>]

On Ant Users List <an...@jakarta.apache.org>,
At 08:04 PM 5/27/2002 +0200, Levente Farkas wrote:
>hi,
>I reasd in the rmic's task description:
>"This task forms an implicit FileSet and supports all attributes of
><fileset>..."
>but it seems to me it doesn't true. at least rmic doesn't support nested
>selector. I'd like to write a selector form rmic to compile all of my
>class which is not an interface and implements Remote. but after I wrote the
>selector it seems rmic doesn't support nested selector.
>anyway it'd be a VERY useful attribute to select just these kind of files!!!
>thanks in advance.
>
>--
>   Levente                               "Si vis pacem para bellum!"
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>


This is correct, and I'm not quite sure what to do about it.

The Rmic task claims to be an implicit fileset, but it does not extend 
fileset and neither does it support a fileset element. Instead, it extends 
MatchingTask. MatchingTask exists for the sole purpose of allowing tasks to 
act as if they were filesets without actually inheriting from AbstractFileset.

I assume this is all here for hysterical reasons, but the question is what 
to do about it. Here are the options as I see them:

   1) Extend MatchingTask to support all the selector stuff by implementing 
SelectorContainer
   2) Extend MatchingTask to support a nested <fileset> element, and tell 
people who want to use selectors to use an explicit <fileset>
   3) Change the documentation to say that <rmic> (and other MatchingTask 
tasks) support only a subset of <fileset>'s elements

My inclination would be to implement both option 1 and option 2, but I'm 
getting a little uncomfortable with how many classes have to be touched to 
add a new Selector. If MatchingTask is the only other one that will have to 
implement SelectorContainer that isn't too bad, but are there others lurking?

What do others think about this? What should the solution be?



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: why rmic task doesn't support selector?

[Stefan Bodewig <bo...@apache.org>]

On Mon, 27 May 2002, Bruce Atherton <br...@callenish.com> wrote:

> The Rmic task claims to be an implicit fileset,

to support an implicit fileset.

> it extends MatchingTask. MatchingTask exists for the sole purpose of
> allowing tasks to act as if they were filesets without actually
> inheriting from AbstractFileset.

As if they supported an implicit fileset.  MatchingTask predates
FileSet by several months.

> I assume this is all here for hysterical reasons,

historical, but I like hysterical ;-)

>    1) Extend MatchingTask to support all the selector stuff by
>    implementing SelectorContainer

+1

>    2) Extend MatchingTask to support a nested <fileset> element, and
>    tell people who want to use selectors to use an explicit
>    <fileset>

No, leave that up to the task writers to decide whether they want to
deal with multiple filesets.  Extending MatchingTask means "I'll
support exactly one fileset, not zero and not more than one".

Stefan

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>