Now that there are two real eclipse plugins for maven, I have to wonder how much use this plugin will continue to get and if it's worth such a major overhaul?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nicolas de loof Sent: Wednesday, April 23, 2008 9:42 AM To: Maven Developers List Subject: Re: [proposal] eclipse plugin extensibility Right This will work on a "per file to generate" basis, isn't it ? What if a contributor want's to add a buildcommand (for example checkstyle) ? I don't think we just need a eclipse-writers-api, but a larger eclipse-plugin-contributor-api that includes - eclipse feature detection (to allow my Foo contributor to detect the Foo feature is enabled on eclipse) - eclipseConfig customizer to add projectNatures, builders, dependencies, classpathcontainers ... used by other writers - and the writer-api Nico. 2008/4/23, Arnaud HERITIER <[EMAIL PROTECTED]>: > > No it's impossible in maven 2.0.x to load those writers from another > plugin. > In my mind we have to add all writers as plugin's dependency. By > default we'll propose a large set of existing writers, but users will > also be able to add their own. > By default we'll have something like : > eclipse-plugin > |- eclipse-core > |- eclipse-writers-api > |- eclipse-writers > |- eclipse-wtp-0.7-writer > |- eclipse-wtp-1.0-writer > |- eclipse-wtp-2.0-writer > |- eclipse-rad-6.0-writer > |- eclipse-myeclipse-5.0-writer > By default we'll propose all our writers and perhaps in the future > some others defined in others projects. > We have a writer for each version of configuration files. Users we'll > be able to set the version of each version or they'll inform about > their workspace location to let the plugin find the version for > version. > > > Arnaud > > > > > On Wed, Apr 23, 2008 at 3:13 PM, nicolas de loof <[EMAIL PROTECTED]> > wrote: > > Your idea is complementary to mine : > > > > You want to discover what the target eclipse installation can do and > extract > > any usefull configuration from maven to setup the workspace. > > > > My idea was to "plug" into the eclipse plugin the dedicated > contributors - > > but they could themself rely on what eclipse supports to create > dedicated > > setup. > > > > Do you have any idea of a maven way to bypass plugins isolation, so > that the > > eclipse plugin can lookup other plugins (let's say checkstyle report > plugin) > > for a "contributor", expose the eclipse workspace capabilities and let > the > > contributor create additional files or register additional > configuration > > elements ? > > AFAIK this requires a maven extension to share a plugin "contributor" > API, > > but maybe I'm wrong. > > > > Nico. > > > > > > 2008/4/23, Arnaud HERITIER <[EMAIL PROTECTED]>: > > > > > > > > > > It's exactly why I want to do for a 3.0 release of the plugin. > > > What we could have is to try to discover features of eclipse reading > > > its workspace. > > > For each feature/plugin we try to find in the writers list (loaded by > > > default or through the plugin config) the most recent version of the > > > writer compatible for this feature/plugin. > > > Today we have writers for rad 6, wtp (0.7 to 2.0), ... > > > Each writer registers which files it creates to be able to remove > them > > > with eclipse:clean > > > This feature could allow us to remove a lot of settings and extra > > > goals (:myeclipse, :rad, ..) that we have to maintain to support > those > > > plugins. > > > > > > You'll have my support to implement it. > > > > > > Arnaud > > > > > > > > > > > > > > > On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof <[EMAIL PROTECTED]> > > > wrote: > > > > Hello, > > > > > > > > I'd like to propose an extension mecanism for the Eclipse plugin > (and > > > > potentially for other plugins). > > > > > > > > The sysdeo-tomcat-maven-plugin (mojo project) for example has > > > copie/pasted > > > > the dependency resolution code from eclipse plugin. This was > required > > > to > > > > create the .tomcatPlugin configuration file. > > > > If this plugin code could execute *inside* the eclipse plugin as > an > > > > EclipseWriter it could benefict from the original code, and also > from > > > plugin > > > > updates. > > > > > > > > I propose to add a new extensibility feature in the eclipse > plugin. > > > Using a > > > > new parameter, or maybe by searching some "extension" file in the > > > plugin > > > > classpath, the eclipse plugin could setup a list of external > > > EclipseWriters > > > > to run. > > > > > > > > sample configuration : > > > > > > > > <plugin> > > > > <artifactId>maven-eclipse-plugin</artifactId> > > > > <configuration> > > > > ... > > > > <extensions> > > > > <extension> > > > > <id>sysdeo-tomcat</id> <!-- matches some META-INF > > > > metadatas in sysdeo-tomcat-maven-plugin.jar --> > > > > <configuration> > > > > <!-- extension dependent configuration --> > > > > </configuration> > > > > <extension> > > > > <extensions> > > > > </configuration> > > > > > > > > <dependencies> > > > > <dependency> > > > > <groupId>org.codehaus.mojo</groupId> > > > > <artifactId>sysdeo-tomcat-maven-plugin</artifactId> > > > > <version>x</version> > > > > </dependency> > > > > </dependencies> > > > > > > > > </plugin> > > > > > > > > > > > > Beeing added to the plugin classpath, the "plugin-extension" could > add > > > it's > > > > EclipseWriters, and maybe other optional components (to setup > > > ProjectNatures > > > > ?). > > > > > > > > Many other extensions could be added this way to the eclipse > plugin : > > > > generate SpringIDE configuration, setup Checkstyle in sync with > the > > > > maven-checkstyle configuration, etc. > > > > > > > > Another benefict is that the "extension" could benefict from the > forked > > > > generate-source execution that the eclipse-plugin runs, to access > the > > > list > > > > of multi-project modules. > > > > > > > > > > > > Any suggestion is welcome. > > > > > > > > Nicolas. > > > > > > > > > > > > > > > > > > > -- > > > .......................................................... > > > > > > Arnaud HERITIER > > > .......................................................... > > > OCTO Technology - aheritier AT octo DOT com > > > www.octo.com | blog.octo.com > > > .......................................................... > > > ASF - aheritier AT apache DOT org > > > www.apache.org | maven.apache.org > > > ........................................................... > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > > .......................................................... > Arnaud HERITIER > .......................................................... > OCTO Technology - aheritier AT octo DOT com > www.octo.com | blog.octo.com > .......................................................... > ASF - aheritier AT apache DOT org > www.apache.org | maven.apache.org > ........................................................... > > --------------------------------------------------------------------- > 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]
