[proposal] eclipse plugin extensibility

[nicolas de loof-3]

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.

[Simone Gianni-2]

Hi Nicolas,
yes, many Maven plugins have an Eclipse counterpart, and having the
eclipse plugin discover this plugins and delegate to them the generation
of eclipse specific configurations is a great idea. I don't know the
internals of the Eclipse plugin well enough to understand the details of
your proposal, but it sounds very interesting. Any comment from the
Maven community?

Just to name a few, these are the technologies that i use extensively
and have both maven and eclipse support that could be harmonized:
- Obviously the java compiler itself :)
- The Maven eclipse plugin
- AspectJ
- Hibernate
- Spring
- Jetty (would it be possible to make some generation of configurations
for Eclipse WST?)
- Emma, Clover
- FindBugs

Which else?

Simone


nicolas de loof 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.
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mihobson]

On 23/04/2008, Simone Gianni <simoneg@...> wrote:

> Hi Nicolas,
>  yes, many Maven plugins have an Eclipse counterpart, and having the
>  eclipse plugin discover this plugins and delegate to them the generation
>  of eclipse specific configurations is a great idea. I don't know the
>  internals of the Eclipse plugin well enough to understand the details of
>  your proposal, but it sounds very interesting. Any comment from the
>  Maven community?
>
>  Just to name a few, these are the technologies that i use extensively
>  and have both maven and eclipse support that could be harmonized:
>  - Obviously the java compiler itself :)
>  - The Maven eclipse plugin
>  - AspectJ
>  - Hibernate
>  - Spring
>  - Jetty (would it be possible to make some generation of configurations
>  for Eclipse WST?)
>  - Emma, Clover
>  - FindBugs
>
>  Which else?

- Apt

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Arnaud HERITIER]

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 <nicolas@...> 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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[nicolas de loof-3]

The main diffiulty to make plugins collaborate is taht they run in isolation
(distinct classloaders), so they can't share structured datas - until
declared in a maven extension.

The eclipse plugin can lookup the MavenProject for plugin, maybe detect some
contributors one, but cannot invoke code as it doesn't live in the same
classloader (it can't instanciate another plugin class).

My idea is to define extensions for the plugin itself, using extensible
plugin classpath (<dependencies> declared in <plugin>). Based on this, the
eclipse plugin can be configured with a set of contributors.

As you suggest, we could write contributors to setup eclipse-plugins based
on the conuterpart maven plugin configuration.

HOW ? This will require :

- to define and extract an maven-eclispe-plugin contributor API into a
dedicated Jar
- to add a @parameter Contributors[] contributors to the plugin
- during the eclipse:eclipse execution, to invoke contributors to create
custom configuration files.

Contributors could :

- define additional projectNatures
- define additional buildCommands
- define additional settings
- define additional config files (.checkstyle, .springBeans, .tomcatPlugin
...)
- define additional dependencies ?
- define additional classpathContainers ?
- any other ?



Nico.


2008/4/23, Simone Gianni <simoneg@...>:

>
> Hi Nicolas,
> yes, many Maven plugins have an Eclipse counterpart, and having the
> eclipse plugin discover this plugins and delegate to them the generation
> of eclipse specific configurations is a great idea. I don't know the
> internals of the Eclipse plugin well enough to understand the details of
> your proposal, but it sounds very interesting. Any comment from the
> Maven community?
>
> Just to name a few, these are the technologies that i use extensively
> and have both maven and eclipse support that could be harmonized:
> - Obviously the java compiler itself :)
> - The Maven eclipse plugin
> - AspectJ
> - Hibernate
> - Spring
> - Jetty (would it be possible to make some generation of configurations
> for Eclipse WST?)
> - Emma, Clover
> - FindBugs
>
> Which else?
>
> Simone
>
>
>
> nicolas de loof 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.
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[nicolas de loof-3]

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 <aheritier@...>:

>
> 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 <nicolas@...>
> 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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Arnaud HERITIER]

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 <nicolas@...> 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 <aheritier@...>:
>
>
> >
>  > 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 <nicolas@...>
>  > 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: dev-unsubscribe@...
>  > For additional commands, e-mail: dev-help@...
>  >
>  >
>

--
..........................................................
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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[nicolas de loof-3]

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 <aheritier@...>:

>
> 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 <nicolas@...>
> 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 <aheritier@...>:
> >
> >
> > >
> >  > 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 <nicolas@...>
> >  > 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: dev-unsubscribe@...
> >  > For additional commands, e-mail: dev-help@...
> >  >
> >  >
> >
>
>
>
>
> --
>
> ..........................................................
> 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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Brian E Fox]

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: nicolas.deloof@... [mailto:nicolas.deloof@...] 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 <aheritier@...>:

>
> 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 <nicolas@...>
> 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 <aheritier@...>:
> >
> >
> > >
> >  > 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

<nicolas@...>
> >  > 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: dev-unsubscribe@...
> >  > For additional commands, e-mail: dev-help@...
> >  >
> >  >
> >
>
>
>
>
> --
>
> ..........................................................
> 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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Arnaud HERITIER]

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 <nicolas@...> 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 <aheritier@...>:
>  >
>  > 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 <nicolas@...>
>  > 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 <aheritier@...>:
>  > >
>  > >
>  > > >
>  > >  > 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.
>  > >  >
>  > > &