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 pattern. 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 Cc: 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 product. 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 granularity. Any ideas on how to acheive this? Jose Alberto --- Cyrille Morvan <[EMAIL PROTECTED]> 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 > http://jakarta.apache.org/ant/manual/OptionalTasks/ejb.html > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
<<winmail.dat>>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
