ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <>
Subject RE: [PATCH] ejb-jar/jonas element again
Date Fri, 28 Dec 2001 02:40:31 GMT
Consider this just thinking out loud.  But it piques my interest.

For this to work, I think the lead must come from ant.  Ant could define
plug-in interfaces that could be implemented on a level beneath that of
a task based on patterns found in similar products and their tasks.  

Take for example the only part of the system I'm intimately familiar
with, the StarTeam tasks I've been working on.  I'm implementing many of
the tasks in terms of an abstract class that I call TreeBasedTask.  The
point is simply to navigate through two trees (one of which is in some
sense a mirror of the other).  This is implemented through a visitor

Although I confess that I have not even looked at the other version
control tasks, I am fairly sure that this or something like it would be
generalizable to the point that an Interface could be designed for it
that could be implemented not only for Star Team but for other version
control systems as well.  

If that idea could win general acceptance, then all the version control
ant packages could conceivably be refactored to use it.  Once that had
been done, ant might be in a position to say, "If you want to be
supported under ant, here's a way for YOU to do it."  

Of course that presumes that these vendors would want to be supported by
ant enough to take that on.  Or maybe not.  Suppose ant had had this
interface together before I came knocking on the door last month.  Then
ant would be in a position to provide not only the vendor, but any
willing developer, with a better roadmap for how to implement such a
task.  I would have been starting my work from a much more solid base.

Anyway, food for thought.

-----Original Message-----
From:	Jose Alberto Fernandez
Sent:	Thu 12/27/2001 5:53 PM
To:	Ant Developers List
Subject:	RE: [PATCH] ejb-jar/jonas element again
I think there are two separate problems here:

1) I do not think that we can ask ANT to support every
tool ever created in the face of the earth that deals
with a manufacturer specific part of some generic
process. Some examples of it are: Java compilers, EJB
deployment, Source control systems, etc. It is
becomming more and more a nightmare as each product
has its own life cycle and ANT needs to keep things
backwards compatible (even when the products do not).
It would be much more simple to maintain if each one
of the tools maintainied its own tools ans ship the
correct version with the correct version of the

2) In order for this to work ANT has to provide a
generic API and a way to dynamically call their
plug-ins from within our generic tasks: <javac>,
<ejb-jar>, etc. We need a way to define a generic way
to specify which specific plug-in to use (either by
magic property, or somehing else) and a way to
indicate that certain <elements> of the generic task
must be delegated to the specific implementation
supplied with the product. Today, the only thing we
have is <task> which is too coarse. We need a finer

Any ideas on how to acheive this?

Jose Alberto

 --- Cyrille Morvan <>
wrote: > At 14:53 27/12/2001 +1100, you wrote:
> > > I agree that a jonas task would be a worthy
> > > addition to Ant -or
> > > the JOnAS codebase.
> >
> >Despite the fact that Ant has jBoss support, the
> >latter seems more reasonable to me.
> >
> >Why should Jonas support their own ant tasks?
> Because Ant support JBoss, IPlanet, WebSphere,
> WebLogic and Borland 
> Application Server.
> And the ejb-jar documentation says
> " Over time we expect further optional tasks to
> support additional EJB 
> Servers. "
> See more on
> --
> To unsubscribe, e-mail:  
> <>
> For additional commands, e-mail:
> <>

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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

View raw message