That is THE question and why I didn't yet start this dev.
In fact it depends a lot of those IDE plugins. I don't know how many
time they will need to support all our features even if they are
working fast. We have a lot of features now (which is also a problem
now) but they are used a lot in corporate environments.

Arnaud

On Wed, Apr 23, 2008 at 3:52 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> 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]
>
>



-- 
..........................................................
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]

Reply via email to