----- Original Message ----- From: "Dan Miser" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, August 29, 2001 08:16 Subject: Re: SOAP Task
> We're building a VCS application (it does more, but for this purpose, that's > what it does). The API is exposed via SOAP, so if I had this task, I could > issue a SOAP call to get the latest code before launching the build. > > Of course, there is the pure techno-geek side of me that says something like > this would be cool, too. <g> For it to be really cool, I'm going to need to > do a lot of work to make it generic. I'm testing right now, but I don't like > that it's tied to ApacheSOAP, it should use WSDL, and handling any arbitrary > call (and doing something with the result!) will make the task really > useful. I thought for a while of doing a task which takes WSDL and generates java proxy code, as that is something I could see fitting in to the build process fairly easily and maps to those use cases where the interface being bound to is chosen at compile time, even if the implementation is located in a registry later. But I dont see Apache SOAP handling WSDL right now, though other java SOAP libraries do, so one might have to start with an alternate SOAP implementation and do some refactoring once there is >1 implementation to support. Regarding making SOAP calls, I haven't found a need for that in the build process. I do use Get and Post on occasions though, primarily to send notification messages. But if I had soap services of relevance during the build process, I'd think about it. If you are going to implement a Soap task, I have one request: have the results of the call feed in a property as well as a file if the build file requests it; that way its easier to use the output in some other task. So you could have things like a shared team build counter web service which incremented whenever anyone did a build from any box; that counter would be fetched into an ant property for use in naming files and the the like. -Steve
