Hi Brett,
Jetty will start automatically when the IDE first starts up. There will, of
course, be a command line option for starting as well.
I guess on the second issue you raised below, you may have concerns about
latency and memory of using Jetty/xFire. There are clearly lighter
solutions: a simple java process with an input socket, say TCP, (from the
IDE) and an output socket (to the IDE console output). This would require
some additional work: the creation of a simple control language and some
queue management with worker threads - since the input socket is for control
commands handled asynchronously. I'm not opposed to lighter processes, but:
1) I have had good success with Jetty's small memory usage in the past;
2) using Jetty/xFire cuts my dev time. If the latency is too high, then I'll
be the first one to dump it; but from past experience with Axis1, simple
SOAP requests over the internal network came in between 100-200 ms
under small load (10/TPS).
The last issue I want to address (which is independent of either of the
technical solutions outlined above) is that since we are decoupling the IDE
and the MavenEmbedder through the network layer, builds need not "only" be
local; rather we have a solution where the build "may" exist on a different
physical node than the IDE. This would allow me to set up test machines with
different OS, .NET vendors (Microsoft/Novell), patch levels etc in a dev
environment. Then after I develop locally, I could test my work - on say a
remote Linux machine using Mono - using my Visual Studio IDE. I know Jason
raised the issue that watching the build on the remote machine is not all
that interesting - I often feel this is the case on my local machine - but
this misses the point because its not just a matter of kicking off a build
on some continuous integration server after development. This is part of
testing and debugging before checking the code in centrally. It allows
targeted builds of specific modules and the running of specific
integration-tests to address platform issues, all without having to log into
the remote machines. In a very large way, I am anticipating the needs of
NMaven itself, since we have to support so many platforms.
Shane
On 3/16/07, Brett Porter <
[hidden email]> wrote:
>
> Cool.
>
> I'd like to understand:
> - how do we make this easy for people to start?
> - is jetty/servlet container needed, or is there a lighter way to
> embed this in something since we don't really need to use a http
> transport since it will always be local?
>
> On 17/03/2007, at 9:26 AM, Shane Isbell wrote:
>
> > Local.
> >
> > On 3/16/07, Brett Porter <
[hidden email]> wrote:
> >>
> >> Where? On the local machine, a remote machine, ?
> >>
> >> On 17/03/2007, at 3:02 AM, Shane Isbell wrote:
> >>
> >> > MavenEmbedder would run within the same Plexus/Servlet container as
> >> > xFire.
> >> > The Servlet container would almost certainly be Jetty.
> >> >
> >> > Shane
> >> >
> >> > On 3/16/07, Brett Porter <
[hidden email]> wrote:
> >> >>
> >> >>
> >> >> On 15/03/2007, at 11:16 AM, Shane Isbell wrote:
> >> >>
> >> >> > 2) .NET Client Calling Maven Embedder through SOAP:
> >> >> >
http://jira.codehaus.org/browse/NMAVEN-12> >> >> > I have gotten a basic xFire SOAP server communicating with
> >> a .NET
> >> >> > client.
> >> >> > The plan is to use SOAP as the control language with a Socket
> >> >> > logger writing
> >> >> > to the IDE console. We will need to wait for the 2.1-alpha
> >> release
> >> >> > of the
> >> >> > MavenEmbedder to do the final hook up.
> >> >>
> >> >>
> >> >> Where does the actual Maven instance run?
> >> >>
> >> >> - Brett
> >> >>
> >>
>
Locked
