Basically, I want a more elegant way of talking to maven than through I/O streams. A viable solution would be able to start maven in console mode, with a listener assigned to a particular port number. The listener monitors that port for incoming connections.
There would then be a corresponding maven client api, which would connect to that port, and issue commands / receive responses from maven. I understand the issues with GC, and with memory in general, but talking through the console input and output streams is cumbersome at best. -----Original Message----- From: Milos Kleint [mailto:[EMAIL PROTECTED] Sent: Friday, April 22, 2005 2:11 AM To: Maven Developers List Subject: Re: IDE Plugins On 4/21/05, Inger, Matthew <[EMAIL PROTECTED]> wrote: > Is there any plans to implement a sort of Remote API to ease development of > plugins > for IDE's? > > Right now, I think most IDE plugins are starting maven in console mode, > issuing commands > through the processes standard in (process.getOutputStream), and reading the > results back > from the process out (process.getInputStream). > > It would be helpful to have some sort of Java API which could remotely > control a running > maven process (which could present security issues), or at the very least > startup maven > in the current process space, and programatically control it (which could > present problems > if maven classes make any assumptions about only 1 instance of maven running > in > a given jvm) > what exactly do you mean by "control a running maven process"? All that makes sense imho is to feed the initial parameters to maven runner and then watch it process the build, maybe with some funky callbacks into my code in the IDE that would help with visual integration. Currently in Mevenide we do spawn an external process, the reasons are following: 1. memory leaks, in maven 1.0 generating a site for multiproject could eat up to 0.5 GB on my machine. You don't want your ide to be knocked down by the build (and vice versa - IDEs are memory eaters on their own). And we're talking about single run or the build. Running the different builds repeatedly means more GC and more memory usage. The IDEs usually have the heap limit set to 128/256 by default, running maven inside the same jvm would mean instructing users how to increase the heap size, spawned process allows us to run out of the box easily. 2. classpath/classloading issues, IDEs (speaking for netbeans but I suppose this is true for all) that utilize the plugin architecture do need more restricting classloading. Say if there are 2 ide plugins and each uses a different version of a library, both have to work propertly without clashes. Maven has a lot of dependencies itselt, maven plugins add additional. and clasloading is also not cheap memory wise either. 3. possibly static singletons that could mess up things, you already mentioned that. 4. it was way easier to have a command-line wrapper than dive deep into the APIs and deal with issues 1-3. Regards Milos Kleint PS: while numbers 1 and 3 are solved by m2 according to maven developers AFAIK, I would like to learn in more detail how classloading works in m2. > Any thoughts? > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
