ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: JMX and Ant (Re: Extending Ant [was RE: Comparing files in subdirectories])
Date Thu, 31 Oct 2002 18:42:39 GMT
David Jencks wrote:

>> *scratching my head* - so in a normal command-line run of Ant, MBean's
>> would not really come into play.  Only the normal introspection
>> population would apply in this case.  right?

I don't know. Depends on what we want, everything is possible :-)

For normal ant, MBean will help at least by enabling use of any
mbean ( or anything that can be wrapped as a MBean ). I see it as a sort
of super TaskAdapter - a lot of 'tasks' ( and task collections ) we'll
get for free. 

I know JBoss and probably other projects are using JMX as the 'core'
architecture -( and I like a lot this model). Should we use the 
same in ant ? I personally don't think ant will gain too much - the
core is ( IMHO ) reasonably simple and clean, and I doubt JMX will make
it simpler.

The introspection in jmx is not very different from what ant is doing
( as implementation / performance - again from what I've seen in mx4j 
and a bit in jboss ). But ant is more flexible and adapted to our 
use patterns ( the 'text', substitutions, even the hooks we have or could
have ).         

But in general it is good to try and see :-)

>> > There are 2 sides: one allows other applications to view ant ( and
>> > any task ) as an MBean. Using directly the API and calling the methods
>> is
>> > simple enough, but I think there is a lot of value in exposing it
>> > as mbeans. ( this shouldn't be done directly, of course - but using an
>> > add-on layer ).
>> Whats the benefit to Ant users of the MBean architecture?  Or is it only
>> for embedded uses of Ant such as Tomcat's compilation and such?
> from my biased POV
> -better classloading architecture

+1 ( however I would say the classloading architecture in ant is very nice -
except that nobody knows or uses its power :-) 

> -ability to "keep ant running" in between build invocations (keep the
> mbean server running)

That's already possible, but I agree - it would make it much simpler and
would provide one or several nice GUIs for free.

> -Web interface to tasks, targets, etc. (this can be quite sophisticated if
> you use modelmbeans instead of dynamic mbeans)

+1 ( but I think we disagree on the difference between model and mbeans - 
from JMX point of view there is no difference )

> I think a lot of the plumbing inside ant can be done using jmx invocations
> with great simplification of the ant codebase.

That's where I disagree ( I don't think it'll be much simpler ).
( JMX would and will simplify a lot tomcat for example ).

The 2 models are very similar - very low coupling, small core, magic.
JMX has some complexity of its own ( to support 'weird' management 
requirements ), and ant has a lot of specific tunning ( the patterns, etc ).


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

View raw message