On 4/4/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: > Hi Fabrizio, > > I think collecting all the code used for IDE work is a good idea. But I > think we should try not only to collect common code for the Maven 2 > plugins but also for the IDE extensions as much of the same code could > be shared. For example I know that Milos and Eugene have separately > added source code downloading for the Netbeans and Eclipse extensions > respectively. > > I think it's crucial that all the Maven 2 plugins work in a similar way > and that the IDE extensions also work in a similar way. > > I think the best approach here is create discrete plexus components for > the functionality to be shared. Plexus components can easily be utilized > from Mojos or from the embedder. So I think that's the technical > approach in that we should make components not an abstract Mojo. > > As for the organizational aspects I think we need to collect all the IDE > code in one place so that would mean asking the Mevenide folks if they > would like to come here, or we move the plugins we have here to > Mevenide. That is up for discussion but I think we need to collect code > in one place if we are going to be effective with our IDE strategy.
what are the actual usecases? I can imagine that the IDE integrations all do the same things in the same/similar way, but I have no clue about the maven plugins.. My guess is that these have different set of usecase. 1.javadoc/source downloading.. generally quite simple and straightforward I believe. create artifact,pass it to wagon and handle the UI. 2. custom artifact resolution - what are the actual requirements here? for IDE support a critical requirement for me is to have project loaded and resolved without any network traffic => needs to be fast, rather then completely correct.. 3. I want the project to be loaded gracefully, even with possible validation errors. Throwing error and not loading anything is bad for me. 4. inter-project linking is done dynamically and is quite netbeans dependent. Milos > > Any thoughts? > > > Fabrizio Giustina wrote: > > Hi, > > I recently noticed a lot of duplicated effort in order to implement > > similar things in the eclipse and idea plugins. Downloading of source > > artifacts and javadocs has been reimplemented in the idea one, and I > > recently took off some bits of the custom artifact resolution used in > > the idea plugin and integrated it into the eclipse one. > > > > It will probably be possible to share most of this stuff to reduce > > duplicate code and to improve consistency between plugins (use similar > > flags for common features and so on... reducing the numbers of "why > > the eclipse plugins does that and the idea one doesn't - or does that > > differently" questions from users). > > > > I've just committed some major changes to the eclipse plugin to change > > the artifact resolution behaviour (in order to avoid the need for > > installed reactor projects) and in the meanwhile I deeply refactored > > the plugin in order to extract a base mojo that could be useful for > > other similar plugins. > > The base mojo take care of artifact resolution, source and javadocs > > downloading, plus some basic messages and handling of common flags > > (download sources, directly link referenced projects...). The result > > is a list of dependencies in a "friendly format" for IDE mojos that > > can direcly be used to create configuration files. Probably also the > > source directories processing could be handled here (but not done > > yet). > > > > I would like to go on adding a few more fixes to the eclipse plugin > > and release a new version (probably the artifact resolution change > > worths a release on its own), but after that I would like to split all > > the generic stuff (currently in the org.apache.maven.plugins.ide > > package) in a shared library. > > Could this be interesting for idea plugins developers? (Brett?, > > Edwin?) Anybody likes this? > > > > fabrizio > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > -- > jvz. > > Jason van Zyl > jason at maven.org > http://maven.apache.org > > Simplex sigillum veri. (Simplicity is the seal of truth.) > > --------------------------------------------------------------------- > 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]
