Hi Jason, I am thinking more of an out-of-band concept, where we have a SOAP interface for issuing of build commands and a dedicated socket connection that is hooked up - through a MavenEmbedderLogger implementation - between the IDE and the build machine. The socket logger will pipe into the IDE's console screen. This cuts down on the chattiness of the SOAP interface, which is more expensive, and also allows the user to see the build results as they occur.
I could see some JMS or messaging coming into play for multi-point delivery of the results, but I don't have a case for it yet. Shane On 3/9/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 9 Mar 07, at 8:43 AM 9 Mar 07, Shane Isbell wrote: > Just to give everybody a heads up, I'm working a MavenEmbedder Web > Service component for the Apache NMaven project (under incubation). > The > component will enable: 1) IDEs to build maven projects on local > and remote > build machines; 2) IDE interoperability between non-java languages and > maven. Any ideas on whether this may have general usability within > Maven > itself? > That's cool provided this is something that is not actually in the embedder. You may also want to look at the framework that the Geronimo folks did for Continuum which is essentially a message based build distribution which makes more sense then a web service because you need to get the information back and JMS is a better model for this if you're actually trying to send build information to a remote machine, and have the results be returned. There are many clients for ActiveMQ for example and I'm sure there is a .net implementation but using the STOMP wire format it would be pretty easy to create. A web service for invoking builds, IMO, would be a poor choice. David Blevins already pondered this while doing GBuild and I would suggest you pursue that road for actually building. If you are trying to collect information and parse POMs and get information about projects then a web service would be appropriate but certainly not for build information. You do not want to re-invent the reliability aspect of sending and receiving the build information and JMS is obviously perfect for this. Jason. > Regards, > Shane --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
