ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: Extending Ant [was RE: Comparing files in subdirectories]
Date Mon, 28 Oct 2002 23:28:35 GMT
Thanks for taking the time to answer, and provide details Bruce. Again,
maybe it's not apparent from my previous post, the extension mechanism you
put into place is great, and being able to extend the selectors at all is
invaluable.

That said, it's true that I'm pushing for a unique pattern/idiom to extend
Ant, which would be the use of the Bean pattern. The selector extension
mechanism doesn't use that pattern, and given how well it's written and
structured, it was the easier to study (plus the FilterReader didn't come to
me ;-).

Now to come to the meat of the issue... is it possible to be able to extend
the core selectors with 'Bean-selectors' without modifying the Ant code???
You say it's not possible, because one has to add a addXYZ() method to the
selector containers. But as you point out, one can have a single entry point
(a hook as Costin says) using a addBeanSelector() method, and the
BeanSelector has to do the magic of configuring itself using the
Bean-pattern. This is very similar to your addCustom().

The tough part is the creation/loading and configuration of the
Bean-selector, or more precisely the actual class the BeanSelectorWrapper
would delegate to (or configure, and forward isSelected() to).

I think the 'good' solution would be for the framework to do that
automagically! I have no clue how to do that, and do not understand a thing
to RuntimeConfigurable/UnknownElement.

The stop gap solution would be for the BeanSelectorWrapper to implement
Erik's DynamicConfigurator. The problem I see with this approach is that
it's not automated, and one must do the introspection manually. Maybe there
are things from the framework that could be leveraged to not have to recode
everything, but I haven't looked. Having played with DynamicConfigurator
though, I do think it would work. Now that may not be an acceptable solution
for all committers ;-)

The big advantage I see for the writer of the custom bean-selector (or
custom bean-filter-reader) is ease of implementation. If enough can be
abstracted, it might actually be easy to use this extension pattern to
condition/filter-readers, etc...

The XML I would envision would be like so:

<fileset id="myID">
  <or>
    <bean-selector classname="acme.CoolSelector"
                   classpathref="myCoolJars"
                   customAttrib1="true">
      <customElement1/>
    </bean-selector>
    <filename .../>
  </or>
</fileset>

I'm not sure if the same pattern can be used to write new container
selectors??? I'm not sure such container selectors are needed though, since
you covered all the ones I could think off (and more with <none>).

Thanks to let me know what you all think. --DD

-----Original Message-----
From: Bruce Atherton [mailto:bruce@callenish.com] 
Sent: Monday, October 28, 2002 4:54 PM
To: Ant Developers List
Subject: Re: Extending Ant [was RE: Comparing files in subdirectories]

At 11:03 AM 10/25/2002 -0500, Dominique Devienne wrote:
>I've looked at the extension mechanism of selectors, which uses
>Parameterizable, and I'd like to ask why a custom selector writer has to
get
>his attributes that way instead of the normal way task and type benefit,
>i.e. using introspection?

You can write your selector either way, but if you write it the "normal" 
introspection way you will have to touch some of the standard Ant code. See 
http://jakarta.apache.org/ant/manual/CoreTypes/selectors-program.html for 
more info on how to do this if you want to, particularly the part about 
implementing core selectors.


>The same Paramerer/Parameterizable scheme might allow easier condition
>extension in the short term, but the Bean pattern is so much term, and the
>right Ant-way IMHO...

As I say, you are still able to do that if you want to. The custom selector 
option is available so that you can write your own selector and use it in 
all the tasks and selector containers without any change to the core ant
code.

Since this is the developers list, here is the underlying issue. The 
binding of the XML to the java objects is done using the introspection of 
the method signatures in the classes, as you point out. So each selector 
container's class, for example, has an "addContains()", "addDepends()", 
etc. for each type of selector that Ant provides. When a user adds a new 
selector, the selector container code will not have an "addMynewselector()" 
method unless the user also changes the standard container code (or its 
base class).

So for those users that don't want to make those kinds of changes to the 
core code, all the selector containers (as well as AbstractFileset) have an 
"addCustom()" method that does the right thing using the Parameterizable 
mechanism that Magesh introduced with Filters (which have the same issue).

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