ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject HTTP/SOAP tasks (Re: what I want to see in the next version of ant)
Date Mon, 22 Jul 2002 23:53:31 GMT
On Mon, Jul 22, 2002 at 01:08:42PM -0700, Steve Loughran wrote:
> Here's my list what I'd like to see in the next version of ant.
> What do I want to see in terms of task evolution:
> 2. try and get the http tasks to work with httpclient, and so work properly
> 3. I also want to be able to make soap calls from inside ant; that would be
> slick for some deployment actions

For these two, see the Anteater project,,
which is a functional testing (poke a URL, test the result) framework.

The SOAP example being:

<target name="simple">
  <http description="Post a simple SOAP request">
    <soapRequest href=""
        <responseCode value="200"/>

There's also a task to deploy an embedded Tomcat instance, which makes
possible testing of interactive SOAP services, as well as mundane things
like cron-driven webapp testing. There are regex, xpath, Relax NG and
'contentEquals' validators, and an XML/HTML reporting framework stolen
straight from <junitreport> :)

And while I'm here, here's my wishlist for Ant..

 - Less distinction between Tasks and Types. Anteater makes extensive
   use of Types, for tags like <group>, <session> and <logger>. My
   primary difficulty is that TaskContainer doesn't accept nested Types,
   so I can't have:

     <soapRequest .../>
     <logger refid="mylogger"/>

   where http is a TaskContainer, soapRequest is a Task and logger is a

 - Namespace support, so I could say:
   <xpath xmlns:soap="..."

   Instead of the hacky <xmlns prefix=".." uri=".."/> type I'll have to
   add soon.

I'm very much looking forward to Ant2 concepts being adopted, in
particular a stronger Container API that caters for tasks that contain
other tasks. TaskContainer is pretty primitive; I'd really like the full
Avalon Container/Component API, with ComponentManagers that I could use
to configure and manage subtasks.

As for future Ant-related development, here are some things I'd like to

 - Use a VFS abstraction of HTTP resources. The idea is that, rather
   than have an explicit <http> task based on HttpClient, write a HTTP
   backend to a VFS API, like Myrmidon has. Then we can use normal tasks
   to manipulate and test HTTP resources, instead of HTTP-specific
   tasks. See
 - Use the Condition API (o.a.t.a.taskdefs.condition.*) as a basis for
   the process of testing a HTTP resource.
 - Generalise the callback-based reporting system found in JUnit and
   Anteater, and make it an extensible event-driven system which any
   task can use to log.


> 4. <latex> and <pdflatex> tasks in some optional-latex package
> 5. get the .NET stuff up to snuff for better wsdl import testing of axis
> services; better handling of references, multiple source files, support for
> J#, all in the optional-dotnet package
> 6. pull in the <CC> tasks from ant-contrib. Even if the tasks are in an
> optional package, I'd like to reuse the library and defines stuff in the
> .NET compilers, so the datatypes need to be common.
> 7. Java1.4 support more broadly, perhaps with an <assertionset> type to
> describe assertions to enable/disable
> 8. a better sub build task than current <ant>. We cant change that for
> compatibility reasons but <subbuild> with forking, better defaults, filesets
> and the like would be cool.
> 9. xml schema support. Which means some way of adding local schema URLs to
> catalogs/dtd mappings
> 10. Easier to contain ant inside guis. I hate getting optional tasks to work
> in any GUI ant container, it is always so hard.
> Underneath all that, I want so say that maybe it is time to move to java1.2
> and clean up all our classpath stuff, so that we can move to a good packaged
> world, get rid of so much classpath confusion, etc. Which means that we move
> to something called ant2.0
> If we spend all our life firefighting 1.x issues, then we will never be able
> to move to the 2.0 codebase. And so Conor's action, deleting mutant from
> cvs, has made it clear that there have been multiple protos for 2.0, and yet
> the main ant branch has been too busy evolving to make any revolutionary
> jumps.
> Yet the permanent '2.0' is coming pressure has stopped us evolving ant1.x in
> ways we'd like, because there is pushback on the 'this wont be 2.0
> compatible' theme. Example: Jose-Alberto's antlib proposal.
> So we are doubly stuck: we arent moving ant to a 2.0 codebase, but the fact
> that such a migration is planned stops is fixing some things in the 1.x
> platform.
> We need to move forward, one way or the other.
> I'm think we ought to give priority at this early post-1.5 point to decide
> what the focus of development should be for the next round, simple evolution
> of ant1.5 or whether this is a good time to sit down and move up to starting
> on ant2.0 in earnest, maybe using mutant or myrmidion as foundations, or (as
> Costin suggests), to evolve what we have today, but either way to rework
> enough of ant to make it better than it currently is. Better in terms of
> scalability, flexibility and usability, yet still being very backwards
> compatible with the existing build files.
> Compatibility is always the issue. With a 2.0 number we can get away with
> incompatilbities that are obvious and easy to fix, but we should still avoid
> any subtle incompatibilties that only take time to show up, as users wont
> catch them.
> Comments?
> -Steve

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

View raw message