ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Release Plans
Date Tue, 07 Jan 2003 19:07:39 GMT
Nicola Ken Barozzi wrote:

>> IntrospectionHelper - there are already plently of libraries for doing
>> introspection, some using advanced features we can't include because of
>> dependencies ( JDK1.3, other libs ). There is also JMX who defines a
>> special mechanism for setting attributes ( if someone would want to
>> transparently support JMX components as tasks - in commons-modeler for
>> example :-).
> Hmmm, seems like FlexibilitySyndrome, where anything can be a Task...
> but on the other hand it's really quite cool, 'cause anything can become
> a task without implementing Task... cool, very nice. It could be used
> for example to use JSP taglibs as tasks, no?


Well - anything can be a Task already ( if it has an execute() method ).
That's "flexibility syndrome" from before ant1.0 I think.

The "core" of ant consist of loosly coupled components - combined with some 
simple and flexible beans patterns.

There are 2 benefits of a pluggable IH: ability to use a more efficient 
implementation ( if anyone cares - maybe testing or other non-build uses 
of ant ). And ability to extend or adapt the patterns. Long ago I proposed
a "do" attribute that would allow "adapted" tasks ( i.e. not extending Task)
to use a different method ( start, stop, action, etc - execute is the 
default ).
JMX is very interesting because it works on almost the same principle 
as ant: you have simple mbeans, no need to implement any JMX-specific 
interface, you have dynamic mbeans that implement an interface, and you
have model mbeans that are similar with the TaskAdapter-based tasks.

And given the potential adoption of JMX ( tomcat is using it heavily
already, and tomcat5 will be fully JMX-based - j2ee requires it, most app 
servers, many other apps ) - it makes a lot of sense to have a good ( and 
simple ) way to use it in ant ( for testing, control, automation - probably 
less for actual compiling ).

Currently I'm trying an mlet-like syntax:

  <mbean name="tomcat:type=Server" code="o.a...." />
  <jmx-attribute objectName="tomcat:type=Server" 
                 value="8080" />

I think an ant syntax may be more intuitive:
  <mbean id="tomcat" name="" code="" />
  <tomcat port="8080" />
Or even have the <mbean> declaration implemented in an antlib plugin.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message