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]
