I'm using my maven-ui plugin which is a standalone UI and very lightweight Try it out folks....
http://olofsson.homeip.net/maven-ui-plugin-site/index.html Mvh Mattias Olofsson Software Developer, M. Sc. Physics XDIN AB Gustaf Werners gata 12 SE-421 32 V�stra Fr�lunda Office: +46 (0)31 725 10 92 mail: [EMAIL PROTECTED] This e-mail is confidential and may also be legally privileged. If you are not the intended recipient, please notify us immediately; you should not copy it or use it for any purpose, nor disclose its contents to any other person. -----Original Message----- From: Milos Kleint [mailto:[EMAIL PROTECTED] Sent: den 22 april 2005 08:11 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]
