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, http://aft.sourceforge.net/, 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="http://services.xmethods.net:80/soap"; content="test/requests/get-quote"> <match> <responseCode value="200"/> <xpath select="/soap:Envelope/soap:Body/n:getQuoteResponse/Result"/> </match> </soapRequest> </http> </target> 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: <http> <soapRequest .../> <logger refid="mylogger"/> </http> where http is a TaskContainer, soapRequest is a Task and logger is a Type. - Namespace support, so I could say: <xpath xmlns:soap="..." select="/soap:Envelope/soap/Body"/> 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 pursue: - 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 http://marc.theaimsgroup.com/?t=102665208500004&r=1&w=2 - 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. --Jeff > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
