You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by nicolas de loof <ni...@apache.org> on 2008/04/18 13:02:50 UTC
[proposal] eclipse plugin extensibility
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.
Re: [proposal] eclipse plugin extensibility
Posted by Arnaud HERITIER <ah...@gmail.com>.
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 <ni...@apache.org> 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 <ah...@gmail.com>:
> >
> > 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 <ni...@apache.org>
> > 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 <ah...@gmail.com>:
> > >
> > >
> > > >
> > > > 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 <ni...@apache.org>
> > > > 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@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> >
> > --
> >
> > ..........................................................
> > 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
..........................................................
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] eclipse plugin extensibility
Posted by Siarhei Dudzin <si...@gmail.com>.
Exactly. What's the chance that Q4E and/or m2eclipse will support RAD-6 and
MyEclipse?
On Wed, Apr 23, 2008 at 4:01 PM, Arnaud HERITIER <ah...@gmail.com>
wrote:
> 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 <br...@reply.infinity.nu>
> 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: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] 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 <ah...@gmail.com>:
> > >
> > > 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 <ni...@apache.org>
> > > 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 <ah...@gmail.com>:
> > > >
> > > >
> > > > >
> > > > > 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
> > <ni...@apache.org>
> > > > > 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@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > >
> > > ..........................................................
> > > 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@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
>
> --
> ..........................................................
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] eclipse plugin extensibility
Posted by Arnaud HERITIER <ah...@gmail.com>.
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 <br...@reply.infinity.nu> 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: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] 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 <ah...@gmail.com>:
> >
> > 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 <ni...@apache.org>
> > 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 <ah...@gmail.com>:
> > >
> > >
> > > >
> > > > 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
> <ni...@apache.org>
> > > > 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@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
> >
> >
> > --
> >
> > ..........................................................
> > 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
..........................................................
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] eclipse plugin extensibility
Posted by Arnaud HERITIER <ah...@gmail.com>.
On Wed, Apr 23, 2008 at 4:49 PM, Brian E. Fox <br...@reply.infinity.nu> wrote:
> Both are still early and I'm sure there will be support for these
> things, especially if they are filed as requests. I'm not saying that
> the current eclipse plugin isn't still useful now, I just personally see
> it being less popular over time. I know that I used to live or die by
> the m-e-p, but once the new m2e came out, I haven't used it once.
Personnally I also don't want to be the Last of the Mohicans one more
time. I already made the effort to maintain and finalize maven 1.1 and
I don't want to begin another time.
I'm sure that these plugins will add all our features but I don't know
when. It's always the same problem with OSS projects. If it is in 6
month I can wait. If it is in 1 or 2 years :-(
Another possibility is that I join the team of one of these plugins to
try to have these features but I have to learn everything about
eclipse plugins developments :-(
Actually I like Q4E (I find the integration in eclipse better) but I
can't propose it for complex projects at works which are using
myeclipse, rad6.
>
> Either way, I might suggest embarking on this rewrite on a separate
> branch from the current m-e-p code so that you can still maintain the
> old one for a bit.
yes, I planned to create a 3.X branch.
I have some issues to fix on 2.5.1 ...
Arnaud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] eclipse plugin extensibility
Posted by nicolas de loof <ni...@apache.org>.
That's exactly what I'm looking for.
But this requires some knoledge about eclipse plugins development and
packaging.
A sample "bridge" would help a lot ;-)
2008/4/23, Igor Fedorenko <ig...@ifedorenko.com>:
>
> Yes, this is it and you'd need to write an Eclipse plugin to use this.
> Taking Checkstyle as an example, you probably want to use one of existing
> Eclipse/Checkstyle plugins, so m2e project configurator would work as a sort
> of configuration bridge, i.e it would take checkstyle settings from pom.xml
> and apply them to Eclipse Checkstyle plugin.
>
> nicolas de loof wrote:
>
> > This one ?
> >
> > http://docs.codehaus.org/display/M2ECLIPSE/Extensible+project+import+and+configuration+framework
> >
> > I've installed m2eclipse for evaluation, but don't know where I can
> > setup
> > those extensions.
> > Does a new configurator require to include some new eclipse plugins, or
> > can
> > it be set as "free" jar outside eclipse ... for example in the local
> > repository ?
> >
> >
> > 2008/4/23, Igor Fedorenko <ig...@ifedorenko.com>:
> >
> > > This is probably offtopic, but m2e does support custom project
> > > configurators so it is possible to plugin support for checkstyle or
> > > whatever
> > > happens to be your favourite plugin.
> > >
> > > Brian E. Fox wrote:
> > >
> > > Both are still early and I'm sure there will be support for these
> > > > things, especially if they are filed as requests. I'm not saying
> > > > that
> > > > the current eclipse plugin isn't still useful now, I just personally
> > > > see
> > > > it being less popular over time. I know that I used to live or die
> > > > by
> > > > the m-e-p, but once the new m2e came out, I haven't used it once.
> > > >
> > > > Either way, I might suggest embarking on this rewrite on a separate
> > > > branch from the current m-e-p code so that you can still maintain
> > > > the
> > > > old one for a bit.
> > > >
> > > > -----Original Message-----
> > > > From: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] On
> > > > Behalf Of nicolas de loof
> > > > Sent: Wednesday, April 23, 2008 10:46 AM
> > > > To: Maven Developers List
> > > > Subject: Re: [proposal] eclipse plugin extensibility
> > > >
> > > > Because those plugins doesn't support custom setup :
> > > >
> > > > I'm using the sysdeo-tomcat plugin to setup tomcat plugin for
> > > > eclipse.
> > > > It
> > > > makes my life simplier but is ignored by q4e / m2eclipse.
> > > >
> > > > And AFAIK neither m2eclipse nor q4e support to read the maven
> > > > checkstyle(*)
> > > > configuration to setup checkstyle(*) plugin,
> > > > (*) : replace with your favorite plugin.
> > > >
> > > > Nico.
> > > >
> > > >
> > > > 2008/4/23, Benjamin Bentmann <be...@udo.edu>:
> > > >
> > > > 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?
> > > > >
> > > > > > A possible reason to use the maven-eclipse-plugin:
> > > > > >
> > > > > It's not as invasive as Q4E or M2Eclipse. You can invoke it once
> > > > > on
> > > > >
> > > > > your
> > > >
> > > > own
> > > > > discretion and it won't invoke "mvn generate-resources" during
> > > > > every
> > > > > Eclipse
> > > > > startup, saving one from waiting.
> > > > >
> > > > >
> > > > > Benjamin
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] eclipse plugin extensibility
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
Yes, this is it and you'd need to write an Eclipse plugin to use this.
Taking Checkstyle as an example, you probably want to use one of
existing Eclipse/Checkstyle plugins, so m2e project configurator would
work as a sort of configuration bridge, i.e it would take checkstyle
settings from pom.xml and apply them to Eclipse Checkstyle plugin.
nicolas de loof wrote:
> This one ?
> http://docs.codehaus.org/display/M2ECLIPSE/Extensible+project+import+and+configuration+framework
>
> I've installed m2eclipse for evaluation, but don't know where I can setup
> those extensions.
> Does a new configurator require to include some new eclipse plugins, or can
> it be set as "free" jar outside eclipse ... for example in the local
> repository ?
>
>
> 2008/4/23, Igor Fedorenko <ig...@ifedorenko.com>:
>> This is probably offtopic, but m2e does support custom project
>> configurators so it is possible to plugin support for checkstyle or whatever
>> happens to be your favourite plugin.
>>
>> Brian E. Fox wrote:
>>
>>> Both are still early and I'm sure there will be support for these
>>> things, especially if they are filed as requests. I'm not saying that
>>> the current eclipse plugin isn't still useful now, I just personally see
>>> it being less popular over time. I know that I used to live or die by
>>> the m-e-p, but once the new m2e came out, I haven't used it once.
>>>
>>> Either way, I might suggest embarking on this rewrite on a separate
>>> branch from the current m-e-p code so that you can still maintain the
>>> old one for a bit.
>>>
>>> -----Original Message-----
>>> From: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] On
>>> Behalf Of nicolas de loof
>>> Sent: Wednesday, April 23, 2008 10:46 AM
>>> To: Maven Developers List
>>> Subject: Re: [proposal] eclipse plugin extensibility
>>>
>>> Because those plugins doesn't support custom setup :
>>>
>>> I'm using the sysdeo-tomcat plugin to setup tomcat plugin for eclipse.
>>> It
>>> makes my life simplier but is ignored by q4e / m2eclipse.
>>>
>>> And AFAIK neither m2eclipse nor q4e support to read the maven
>>> checkstyle(*)
>>> configuration to setup checkstyle(*) plugin,
>>> (*) : replace with your favorite plugin.
>>>
>>> Nico.
>>>
>>>
>>> 2008/4/23, Benjamin Bentmann <be...@udo.edu>:
>>>
>>>> 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?
>>>>> A possible reason to use the maven-eclipse-plugin:
>>>> It's not as invasive as Q4E or M2Eclipse. You can invoke it once on
>>>>
>>> your
>>>
>>>> own
>>>> discretion and it won't invoke "mvn generate-resources" during every
>>>> Eclipse
>>>> startup, saving one from waiting.
>>>>
>>>>
>>>> Benjamin
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] eclipse plugin extensibility
Posted by nicolas de loof <ni...@apache.org>.
This one ?
http://docs.codehaus.org/display/M2ECLIPSE/Extensible+project+import+and+configuration+framework
I've installed m2eclipse for evaluation, but don't know where I can setup
those extensions.
Does a new configurator require to include some new eclipse plugins, or can
it be set as "free" jar outside eclipse ... for example in the local
repository ?
2008/4/23, Igor Fedorenko <ig...@ifedorenko.com>:
>
> This is probably offtopic, but m2e does support custom project
> configurators so it is possible to plugin support for checkstyle or whatever
> happens to be your favourite plugin.
>
> Brian E. Fox wrote:
>
> > Both are still early and I'm sure there will be support for these
> > things, especially if they are filed as requests. I'm not saying that
> > the current eclipse plugin isn't still useful now, I just personally see
> > it being less popular over time. I know that I used to live or die by
> > the m-e-p, but once the new m2e came out, I haven't used it once.
> >
> > Either way, I might suggest embarking on this rewrite on a separate
> > branch from the current m-e-p code so that you can still maintain the
> > old one for a bit.
> >
> > -----Original Message-----
> > From: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] On
> > Behalf Of nicolas de loof
> > Sent: Wednesday, April 23, 2008 10:46 AM
> > To: Maven Developers List
> > Subject: Re: [proposal] eclipse plugin extensibility
> >
> > Because those plugins doesn't support custom setup :
> >
> > I'm using the sysdeo-tomcat plugin to setup tomcat plugin for eclipse.
> > It
> > makes my life simplier but is ignored by q4e / m2eclipse.
> >
> > And AFAIK neither m2eclipse nor q4e support to read the maven
> > checkstyle(*)
> > configuration to setup checkstyle(*) plugin,
> > (*) : replace with your favorite plugin.
> >
> > Nico.
> >
> >
> > 2008/4/23, Benjamin Bentmann <be...@udo.edu>:
> >
> > > 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?
> > > >
> > > > A possible reason to use the maven-eclipse-plugin:
> > > It's not as invasive as Q4E or M2Eclipse. You can invoke it once on
> > >
> > your
> >
> > > own
> > > discretion and it won't invoke "mvn generate-resources" during every
> > > Eclipse
> > > startup, saving one from waiting.
> > >
> > >
> > > Benjamin
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] eclipse plugin extensibility
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
This is probably offtopic, but m2e does support custom project
configurators so it is possible to plugin support for checkstyle or
whatever happens to be your favourite plugin.
Brian E. Fox wrote:
> Both are still early and I'm sure there will be support for these
> things, especially if they are filed as requests. I'm not saying that
> the current eclipse plugin isn't still useful now, I just personally see
> it being less popular over time. I know that I used to live or die by
> the m-e-p, but once the new m2e came out, I haven't used it once.
>
> Either way, I might suggest embarking on this rewrite on a separate
> branch from the current m-e-p code so that you can still maintain the
> old one for a bit.
>
> -----Original Message-----
> From: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] On
> Behalf Of nicolas de loof
> Sent: Wednesday, April 23, 2008 10:46 AM
> To: Maven Developers List
> Subject: Re: [proposal] eclipse plugin extensibility
>
> Because those plugins doesn't support custom setup :
>
> I'm using the sysdeo-tomcat plugin to setup tomcat plugin for eclipse.
> It
> makes my life simplier but is ignored by q4e / m2eclipse.
>
> And AFAIK neither m2eclipse nor q4e support to read the maven
> checkstyle(*)
> configuration to setup checkstyle(*) plugin,
> (*) : replace with your favorite plugin.
>
> Nico.
>
>
> 2008/4/23, Benjamin Bentmann <be...@udo.edu>:
>> 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?
>>>
>> A possible reason to use the maven-eclipse-plugin:
>> It's not as invasive as Q4E or M2Eclipse. You can invoke it once on
> your
>> own
>> discretion and it won't invoke "mvn generate-resources" during every
>> Eclipse
>> startup, saving one from waiting.
>>
>>
>> Benjamin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [proposal] eclipse plugin extensibility
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Both are still early and I'm sure there will be support for these
things, especially if they are filed as requests. I'm not saying that
the current eclipse plugin isn't still useful now, I just personally see
it being less popular over time. I know that I used to live or die by
the m-e-p, but once the new m2e came out, I haven't used it once.
Either way, I might suggest embarking on this rewrite on a separate
branch from the current m-e-p code so that you can still maintain the
old one for a bit.
-----Original Message-----
From: nicolas.deloof@gmail.com [mailto:nicolas.deloof@gmail.com] On
Behalf Of nicolas de loof
Sent: Wednesday, April 23, 2008 10:46 AM
To: Maven Developers List
Subject: Re: [proposal] eclipse plugin extensibility
Because those plugins doesn't support custom setup :
I'm using the sysdeo-tomcat plugin to setup tomcat plugin for eclipse.
It
makes my life simplier but is ignored by q4e / m2eclipse.
And AFAIK neither m2eclipse nor q4e support to read the maven
checkstyle(*)
configuration to setup checkstyle(*) plugin,
(*) : replace with your favorite plugin.
Nico.
2008/4/23, Benjamin Bentmann <be...@udo.edu>:
>
> 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?
> >
>
> A possible reason to use the maven-eclipse-plugin:
> It's not as invasive as Q4E or M2Eclipse. You can invoke it once on
your
> own
> discretion and it won't invoke "mvn generate-resources" during every
> Eclipse
> startup, saving one from waiting.
>
>
> Benjamin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] eclipse plugin extensibility
Posted by nicolas de loof <ni...@apache.org>.
Because those plugins doesn't support custom setup :
I'm using the sysdeo-tomcat plugin to setup tomcat plugin for eclipse. It
makes my life simplier but is ignored by q4e / m2eclipse.
And AFAIK neither m2eclipse nor q4e support to read the maven checkstyle(*)
configuration to setup checkstyle(*) plugin,
(*) : replace with your favorite plugin.
Nico.
2008/4/23, Benjamin Bentmann <be...@udo.edu>:
>
> 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?
> >
>
> A possible reason to use the maven-eclipse-plugin:
> It's not as invasive as Q4E or M2Eclipse. You can invoke it once on your
> own
> discretion and it won't invoke "mvn generate-resources" during every
> Eclipse
> startup, saving one from waiting.
>
>
> Benjamin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] eclipse plugin extensibility
Posted by Benjamin Bentmann <be...@udo.edu>.
> 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?
A possible reason to use the maven-eclipse-plugin:
It's not as invasive as Q4E or M2Eclipse. You can invoke it once on your own
discretion and it won't invoke "mvn generate-resources" during every Eclipse
startup, saving one from waiting.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [proposal] eclipse plugin extensibility
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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@gmail.com [mailto:nicolas.deloof@gmail.com] 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 <ah...@gmail.com>:
>
> 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 <ni...@apache.org>
> 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 <ah...@gmail.com>:
> >
> >
> > >
> > > 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
<ni...@apache.org>
> > > 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@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
>
>
> --
>
> ..........................................................
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] eclipse plugin extensibility
Posted by nicolas de loof <ni...@apache.org>.
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 <ah...@gmail.com>:
>
> 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 <ni...@apache.org>
> 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 <ah...@gmail.com>:
> >
> >
> > >
> > > 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 <ni...@apache.org>
> > > 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@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
>
>
> --
>
> ..........................................................
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] eclipse plugin extensibility
Posted by Arnaud HERITIER <ah...@gmail.com>.
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 <ni...@apache.org> 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 <ah...@gmail.com>:
>
>
> >
> > 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 <ni...@apache.org>
> > 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
..........................................................
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] eclipse plugin extensibility
Posted by nicolas de loof <ni...@apache.org>.
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 <ah...@gmail.com>:
>
> 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 <ni...@apache.org>
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] eclipse plugin extensibility
Posted by Arnaud HERITIER <ah...@gmail.com>.
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 <ni...@apache.org> 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] eclipse plugin extensibility
Posted by nicolas de loof <ni...@apache.org>.
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 <si...@apache.org>:
>
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] eclipse plugin extensibility
Posted by VELO <ve...@gmail.com>.
Great,
Count on me for flexbuilder support.
VELO
On Wed, Apr 30, 2008 at 10:58 AM, Arnaud HERITIER <ah...@gmail.com>
wrote:
> both of them.
> If you specify your workspace location, the plugin will try to auto-detect
> your features plugins and if it find contributors compatible with them it
> will generate appropriate settings.
> If not, you'll have to specify them (like is actually with properties like
> wtpversion or custom goals like rad6, myeclipse, ...)
>
> Arnaud
>
>
> On Wed, Apr 30, 2008 at 3:52 PM, VELO <ve...@gmail.com> wrote:
>
> > Question:
> > The extensions, will auto-actived according with installed eclipse
> > (don't
> > like this idea) or I will declared on pom.xml my extensions?
> >
> >
> > VELO
> >
> > On Wed, Apr 30, 2008 at 10:45 AM, nicolas de loof <ni...@apache.org>
> > wrote:
> >
> > > I've created an inital proposal for this on wiki :
> > >
> > >
> > >
> > http://docs.codehaus.org/display/MAVEN/Eclipse+plugin+refactored+for+extensibility
> > >
> > >
> > >
> > > 2008/4/24 VELO <ve...@gmail.com>:
> > >
> > > Flex / Flex builder
> > > >
> > > > I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin
> > > >
> > > > If this goes on, I can create flexbuilder extension.
> > > >
> > > > VELO
> > > >
> > > > On Wed, Apr 23, 2008 at 9:39 AM, Simone Gianni <si...@apache.org>
> > > > 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?
> > > > >
> > > > > 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@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
Re: [proposal] eclipse plugin extensibility
Posted by Arnaud HERITIER <ah...@gmail.com>.
both of them.
If you specify your workspace location, the plugin will try to auto-detect
your features plugins and if it find contributors compatible with them it
will generate appropriate settings.
If not, you'll have to specify them (like is actually with properties like
wtpversion or custom goals like rad6, myeclipse, ...)
Arnaud
On Wed, Apr 30, 2008 at 3:52 PM, VELO <ve...@gmail.com> wrote:
> Question:
> The extensions, will auto-actived according with installed eclipse (don't
> like this idea) or I will declared on pom.xml my extensions?
>
>
> VELO
>
> On Wed, Apr 30, 2008 at 10:45 AM, nicolas de loof <ni...@apache.org>
> wrote:
>
> > I've created an inital proposal for this on wiki :
> >
> >
> >
> http://docs.codehaus.org/display/MAVEN/Eclipse+plugin+refactored+for+extensibility
> >
> >
> >
> > 2008/4/24 VELO <ve...@gmail.com>:
> >
> > Flex / Flex builder
> > >
> > > I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin
> > >
> > > If this goes on, I can create flexbuilder extension.
> > >
> > > VELO
> > >
> > > On Wed, Apr 23, 2008 at 9:39 AM, Simone Gianni <si...@apache.org>
> > > 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?
> > > >
> > > > 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@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> >
>
Re: [proposal] eclipse plugin extensibility
Posted by VELO <ve...@gmail.com>.
Question:
The extensions, will auto-actived according with installed eclipse (don't
like this idea) or I will declared on pom.xml my extensions?
VELO
On Wed, Apr 30, 2008 at 10:45 AM, nicolas de loof <ni...@apache.org>
wrote:
> I've created an inital proposal for this on wiki :
>
>
> http://docs.codehaus.org/display/MAVEN/Eclipse+plugin+refactored+for+extensibility
>
>
>
> 2008/4/24 VELO <ve...@gmail.com>:
>
> Flex / Flex builder
> >
> > I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin
> >
> > If this goes on, I can create flexbuilder extension.
> >
> > VELO
> >
> > On Wed, Apr 23, 2008 at 9:39 AM, Simone Gianni <si...@apache.org>
> > 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?
> > >
> > > 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@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
Re: [proposal] eclipse plugin extensibility
Posted by nicolas de loof <ni...@apache.org>.
I've created an inital proposal for this on wiki :
http://docs.codehaus.org/display/MAVEN/Eclipse+plugin+refactored+for+extensibility
2008/4/24 VELO <ve...@gmail.com>:
> Flex / Flex builder
>
> I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin
>
> If this goes on, I can create flexbuilder extension.
>
> VELO
>
> On Wed, Apr 23, 2008 at 9:39 AM, Simone Gianni <si...@apache.org> 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?
> >
> > 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@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [proposal] eclipse plugin extensibility
Posted by VELO <ve...@gmail.com>.
Flex / Flex builder
I created a flexbuilder-mojo, who inherit from maven-eclipse-plugin
If this goes on, I can create flexbuilder extension.
VELO
On Wed, Apr 23, 2008 at 9:39 AM, Simone Gianni <si...@apache.org> 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?
>
> 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@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [proposal] eclipse plugin extensibility
Posted by Mark Hobson <ma...@gmail.com>.
On 23/04/2008, Simone Gianni <si...@apache.org> 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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [proposal] eclipse plugin extensibility
Posted by Simone Gianni <si...@apache.org>.
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@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org