ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: antlib
Date Thu, 24 Apr 2003 10:47:59 GMT
Guys, 

Two years ago (or was it three?) this proposal got nowhere because
it got picked appart to death. And at the end sat there and we finished
with no antlib of any sort.

I am really tired of that and have no energy for that again. I will try to 
explain you with what I think it is an intuitive example of how the whole
thing fits toguether. See if ths may work as an starting point, if it does
lets get this sucker in and then nick pick the detail and change it all over
until everyone is happy. If not let just remove it from CVS, forget about it
and someone else can design a different approach from scrath; unless Antoine
wants to keep defending and so on. I do not have the energy for it.

For this example I will put asside the issues of BC which I think we can always
solve (we always have).

1) Let assume we define in core a role used by conditions as part of the 
classes implementing conditions, this means that antlib for the core has
something like:

	<antlib>
		...
		<role name="condition" classname="org.apache.tools.ant.role.Condition"/>
	
	      <!-- and a bunch of declarations of conditions -->
	
		<condition name="not" classname="....."/>
		...
	</antlib>

2) We have the nice ant-contrib library which provides those fabulous tasks we adore:

	<antlib>
		<task name="if" classname="net.sf.ant.If" />
		...
	<antlib>

in this library the If class expresses the fact that it accepts a condition an one of its
elements by just having a method like:

	public addConfigured(org.apache.tools.ant.role.Condition c) {}

the name of the method is irrelevant to this discussion it is just some well known name.
The only thing the ant-contrib library needs to know is that whatever its pass to it
implements the role and therefore it can just call the expected method and that's it.


3) There is now this amaizing.com company that has this beans that you can use to query
about all kinds of things on an operating environment: Was average CPU utilization above
95% within the last 5 min? Was latency on the local area network above some threashold
during some period of time? Is a device more than 98% full? Amazing stuff, all from java.

Of course, they want to provide this as ANT conditions that you can use from their antlib.
Their objects are configure following the Beans pattern and getting the yes/no response
follows an API of their own (their own interface). So what does amizing.com has to do?

	a) Create wrappers for every one of their classes that implement the Condition role.
	   (A maintenance nightmare since every future change on their beans needs to be
	    kept in sync on the wrappers).

	b) Define ONE Adaptor class "com.amazing.ant.ConditionAdaptor" that implements the
	   Condition role and knows how to make the query call on their beans using their API.

Obviously (b) is much better. So they define their antlib as follows:

	<antlib>
		<condition name="cpuusage" classname="com.amazing.queries.CpuUsage"
			adaptor="com.amazing.ant.ConditionAdaptor"/>
		<condition name="latency" classname="com.amazing.queries.NetLatency"
			adaptor="com.amazing.ant.ConditionAdaptor"/>
		<condition name="diskfull" classname="com.amazing.queries.DiskFull"
			adaptor="com.amazing.ant.ConditionAdaptor"/>
	</antlib>

That's it, zero pain for the amizing.com people.

4) What does ANT do when if finds something like:

	<if>
	  <diskfull device="c:" threshold="95"/>
	  <then>
		<fail>There is not enough space for the build</fail>
	  </then>
	</if>

Ant will find <if> is a task and instantiate it, then it will take a look
nd find that there is no prefefined <diskfull> element for the task so it will
look at the role methods, it finds that the <if> task accepts the role 
org.apache.tools.ant.role.Condition, so it looks in the symbol table for things
declared of that role. If finds there <diskfull>, it instantiates it and configures
it. It then notices it does not implement the role interface so it tries to 
find an Adaptor for it, it finds one. It instantiates the adaptor sets the configured
bean into it and calls addConfigured(org.apache.tools.ant.role.Condition) passing
the adaptor.

<if> now is ready to go and has no knowledge of the details of <diskfull>.

5) How about beans executed as tasks? No sweat, the core declaration of the task role
is something like:

	<role name="task" classname="...." adaptor="org....TaskAdaptor"/>

If you define a bean as a task and you do not specify a different adaptor, ANT will use
this default TaskAdaptor which is the code that knows about execute().

But you could define a different Adaptor based on java.lang.Runnable for some other
beans that work that way. 

So this is the end of my example, notice that the ANT code treat everything that same way
there is no special this or that, there is no special magic, we can think of additional
features but they are additional and we can add them as we go.

So let me know what you think and if this would fly or not and lets move on.

Jose Alberto


> -----Original Message-----
> From: Costin Manolache [mailto:cmanolache@yahoo.com]
> Sent: 23 April 2003 18:48
> To: dev@ant.apache.org
> Subject: RE: antlib
> 
> 
> Jose Alberto Fernandez wrote:
> 
> > This is exactly the point, we should try to type things. Roles
> 
> Why ? We have components that can be used in any role. Metadata can 
> be extracted and used in a variety of ways - descriptors, interfaces,
> runtime calls ( like in the 3 kinds of mbeans ). But in the 
> end the user
> of a component decides in what roles he wants to use it and how.
> 
> 
> > are this typed interfaces expected by the set/add method. 
> The component
> > being declared of a particular role, may or may not implement the
> > interface. If it does cool; if not an adaptor will be used 
> to bridge the
> > gap. It is upto the adaptor to decide if the bean is 
> compatible or not.
> 
> +1 on this part
> 
> 
> > The guy writing the container (the thing with the set/add 
> methods) does
> > not have to deal with introspection or anything of that. As s/he
> > shouldn't. But by allowing adaptors someone can take some 
> cool object and
> > bridge it.
> 
> I think the "container" is ant. Not sure who should write the 
> adapters - 
> IMO ant can support this automatically ( by introspection 
> since we can't use
> 1.3 features).
> 
> 
> > So, since now this objects come from somewhere else, if it 
> is not typed
> > somehow, any object expecting an instance of the role need to do
> > introspection by hand. Not good.
> 
> No. It is easy to provide this service in ant - just like it 
> is done in
> JMX. Code using JMX never does introspection - just calls the "invoke"
> method. If JDK1.3 is used, he can get a proxy that implements 
> the desired
> interface. ( I think it can be done for JDK1.2 as well, but a 
> bit harder ).
> 
> 
> Costin
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 
> 

Mime
View raw message