You're right. It's not only writers but all configuration files. Arnaud On Wed, Apr 23, 2008 at 3:41 PM, nicolas de loof <[EMAIL PROTECTED]> wrote: > 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] > > > > >
-- .......................................................... 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]
