ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: why rmic task doesn't support selector?
Date Mon, 27 May 2002 19:19:57 GMT
On Ant Users List <ant-user@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:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:ant-user-help@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:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message