Hi, > > 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.
Sure, also IDE extensions will have lots of code to share... till now there was no common code neither for IDE extension than for IDE mojos so my proposal was just to start from mojos, since I was working on the eclipse plugin. > > 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. Yes, but I still think that a base class to be utilized by IDE mojos can be really helpful. First of all this could handle common parameters (like the download sources flag) and common messages (how to enable common features, reporting the list of missing sources): this could really improve user experience for user switching from different IDEs. Another point is that actually most of the code is just a mix of features available in existing plexus component: short but tricky ;) Having a base mojo that takes care of declaring the bunch of required components, do the magic and require the final mojo to just write down configuration files using a list of ready to use and specific objects makes the final plugin a lot simpler to write. This code is probably something that is not useful to IDE extensions. > 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. Yes, the point for maven mojos is that: - you need to handle a flag to turn it on/off - based on the flag, you have to download artifacts or resolve them to the local repo - you have to give a report of missing sources - same thing for javadocs, OR handle javadocs only as a backup for missing sources - downloaded javadocs and sources should be associated to artifacts in a way that it's easy to handle by the mojo (e.g. for the eclipse plugin download and resolution is done in a first step, and resolved artifacts are then passed to specific "writers" that take cares of writing different configuration files) > 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.. for mojos: I had to remove the automatic dependency resolution and to do it manually expecially to remove the requirement for reactor projects to be installed. If the user want to create links between projects (another common flag) reactor artifacts don't need to be resolved at all. If this flag is set to false, they need to be resolved just like "normal" dependencies. > 3. I want the project to be loaded gracefully, even with possible > validation errors. Throwing error and not loading anything is bad for > me. Another thing handled in manual artifact resolution: don't fail if a dependency is not found (so at least you can open the project in eclipse and fix the dependencyif that's the case) but only report an error. fabrizio --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
