|
»
»
»
« Return to Thread: [proposal] eclipse plugin extensibility
RE: [proposal] eclipse plugin extensibility
by Brian E Fox
::
Rate this Message:
Now that there are two real eclipse plugins for maven, I have to wonder
how much use this plugin will continue to get and if it's worth such a
major overhaul?
-----Original Message-----
From: nicolas.deloof@... [mailto:nicolas.deloof@...] On
Behalf Of nicolas de loof
Sent: Wednesday, April 23, 2008 9:42 AM
To: Maven Developers List
Subject: Re: [proposal] eclipse plugin extensibility
Right
This will work on a "per file to generate" basis, isn't it ?
What if a contributor want's to add a buildcommand (for example
checkstyle)
?
I don't think we just need a eclipse-writers-api, but a larger
eclipse-plugin-contributor-api that includes
- eclipse feature detection (to allow my Foo contributor to detect the
Foo
feature is enabled on eclipse)
- eclipseConfig customizer to add projectNatures, builders,
dependencies,
classpathcontainers ... used by other writers
- and the writer-api
Nico.
2008/4/23, Arnaud HERITIER <aheritier@...>:
>
> No it's impossible in maven 2.0.x to load those writers from another
> plugin.
> In my mind we have to add all writers as plugin's dependency. By
> default we'll propose a large set of existing writers, but users will
> also be able to add their own.
> By default we'll have something like :
> eclipse-plugin
> |- eclipse-core
> |- eclipse-writers-api
> |- eclipse-writers
> |- eclipse-wtp-0.7-writer
> |- eclipse-wtp-1.0-writer
> |- eclipse-wtp-2.0-writer
> |- eclipse-rad-6.0-writer
> |- eclipse-myeclipse-5.0-writer
> By default we'll propose all our writers and perhaps in the future
> some others defined in others projects.
> We have a writer for each version of configuration files. Users we'll
> be able to set the version of each version or they'll inform about
> their workspace location to let the plugin find the version for
> version.
>
>
> Arnaud
>
>
>
>
> On Wed, Apr 23, 2008 at 3:13 PM, nicolas de loof <nicolas@...>
> wrote:
> > Your idea is complementary to mine :
> >
> > You want to discover what the target eclipse installation can doand
> 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 checkstylereport
> plugin)
> > for a "contributor", expose the eclipse workspace capabilities and
let
> the
> > contributor create additional files or register additional
> configuration
> > elements ?
> > AFAIK this requires a maven extension to share a plugin
"contributor"
> API,
> > but maybe I'm wrong.
> >
> > Nico.
> >
> >
> > 2008/4/23, Arnaud HERITIER <aheritier@...>:
> >
> >
> > >
> > > It's exactly why I want to do for a 3.0 release of the plugin.
> > > What we could have is to try to discover features of eclipsereading
> > > its workspace.
> > > For each feature/plugin we try to find in the writers list
(loaded by
> > > default or through the plugin config) the most recent version of
the
> > > writer compatible for this feature/plugin.
> > > Today we have writers for rad 6, wtp (0.7 to 2.0), ...
> > > Each writer registers which files it creates to be able to remove
> them
> > > with eclipse:clean
> > > This feature could allow us to remove a lot of settings and extra
> > > goals (:myeclipse, :rad, ..) that we have to maintain to support
> those
> > > plugins.
> > >
> > > You'll have my support to implement it.
> > >
> > > Arnaud
> > >
> > >
> > >
> > >
> > > On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof<nicolas@...>
> > > wrote:
> > > > Hello,
> > > >
> > > > I'd like to propose an extension mecanism for the Eclipse
plugin
> (and
> > > > potentially for other plugins).
> > > >
> > > > The sysdeo-tomcat-maven-plugin (mojo project) for example has
> > > copie/pasted
> > > > the dependency resolution code from eclipse plugin. This was
> required
> > > to
> > > > create the .tomcatPlugin configuration file.
> > > > If this plugin code could execute *inside* the eclipse pluginas
> 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 someMETA-INF
> > > > metadatas in sysdeo-tomcat-maven-plugin.jar -->
> > > > <configuration>
> > > > <!-- extension dependent configuration
-->
> > > > </configuration>
> > > > <extension>
> > > > <extensions>
> > > > </configuration>
> > > >
> > > > <dependencies>
> > > > <dependency>
> > > > <groupId>org.codehaus.mojo</groupId>
> > > >
<artifactId>sysdeo-tomcat-maven-plugin</artifactId>
> > > > <version>x</version>
> > > > </dependency>
> > > > </dependencies>
> > > >
> > > > </plugin>
> > > >
> > > >
> > > > Beeing added to the plugin classpath, the "plugin-extension"
could
> add
> > > it's
> > > > EclipseWriters, and maybe other optional components (to setup
> > > ProjectNatures
> > > > ?).
> > > >
> > > > Many other extensions could be added this way to the eclipse
> plugin :
> > > > generate SpringIDE configuration, setup Checkstyle in sync
with
> the
> > > > maven-checkstyle configuration, etc.
> > > >
> > > > Another benefict is that the "extension" could benefict from
the
> forked
> > > > generate-source execution that the eclipse-plugin runs, to
access
> the
> > > list
> > > > of multi-project modules.
> > > >
> > > >
> > > > Any suggestion is welcome.
> > > >
> > > > Nicolas.
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > ..........................................................
> > >
> > > Arnaud HERITIER
> > > ..........................................................
> > > OCTO Technology - aheritier AT octo DOT com
> > > www.octo.com | blog.octo.com
> > > ..........................................................
> > > ASF - aheritier AT apache DOT org
> > > www.apache.org | maven.apache.org
> > > ...........................................................
> > >
> > >
> >
> >
> > >---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> >
>
>
>
>
> --
>
> ..........................................................
> Arnaud HERITIER
> ..........................................................
> OCTO Technology - aheritier AT octo DOT com
> www.octo.com | blog.octo.com
> ..........................................................
> ASF - aheritier AT apache DOT org
> www.apache.org | maven.apache.org
> ...........................................................
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
how much use this plugin will continue to get and if it's worth such a
major overhaul?
-----Original Message-----
From: nicolas.deloof@... [mailto:nicolas.deloof@...] On
Behalf Of nicolas de loof
Sent: Wednesday, April 23, 2008 9:42 AM
To: Maven Developers List
Subject: Re: [proposal] eclipse plugin extensibility
Right
This will work on a "per file to generate" basis, isn't it ?
What if a contributor want's to add a buildcommand (for example
checkstyle)
?
I don't think we just need a eclipse-writers-api, but a larger
eclipse-plugin-contributor-api that includes
- eclipse feature detection (to allow my Foo contributor to detect the
Foo
feature is enabled on eclipse)
- eclipseConfig customizer to add projectNatures, builders,
dependencies,
classpathcontainers ... used by other writers
- and the writer-api
Nico.
2008/4/23, Arnaud HERITIER <aheritier@...>:
>
> No it's impossible in maven 2.0.x to load those writers from another
> plugin.
> In my mind we have to add all writers as plugin's dependency. By
> default we'll propose a large set of existing writers, but users will
> also be able to add their own.
> By default we'll have something like :
> eclipse-plugin
> |- eclipse-core
> |- eclipse-writers-api
> |- eclipse-writers
> |- eclipse-wtp-0.7-writer
> |- eclipse-wtp-1.0-writer
> |- eclipse-wtp-2.0-writer
> |- eclipse-rad-6.0-writer
> |- eclipse-myeclipse-5.0-writer
> By default we'll propose all our writers and perhaps in the future
> some others defined in others projects.
> We have a writer for each version of configuration files. Users we'll
> be able to set the version of each version or they'll inform about
> their workspace location to let the plugin find the version for
> version.
>
>
> Arnaud
>
>
>
>
> On Wed, Apr 23, 2008 at 3:13 PM, nicolas de loof <nicolas@...>
> wrote:
> > Your idea is complementary to mine :
> >
> > You want to discover what the target eclipse installation can do
> 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
> plugin)
> > for a "contributor", expose the eclipse workspace capabilities and
let
> the
> > contributor create additional files or register additional
> configuration
> > elements ?
> > AFAIK this requires a maven extension to share a plugin
"contributor"
> API,
> > but maybe I'm wrong.
> >
> > Nico.
> >
> >
> > 2008/4/23, Arnaud HERITIER <aheritier@...>:
> >
> >
> > >
> > > It's exactly why I want to do for a 3.0 release of the plugin.
> > > What we could have is to try to discover features of eclipse
> > > 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
> > > 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
> 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
> > > > metadatas in sysdeo-tomcat-maven-plugin.jar -->
> > > > <configuration>
> > > > <!-- extension dependent configuration
-->
> > > > </configuration>
> > > > <extension>
> > > > <extensions>
> > > > </configuration>
> > > >
> > > > <dependencies>
> > > > <dependency>
> > > > <groupId>org.codehaus.mojo</groupId>
> > > >
<artifactId>sysdeo-tomcat-maven-plugin</artifactId>
> > > > <version>x</version>
> > > > </dependency>
> > > > </dependencies>
> > > >
> > > > </plugin>
> > > >
> > > >
> > > > Beeing added to the plugin classpath, the "plugin-extension"
could
> add
> > > it's
> > > > EclipseWriters, and maybe other optional components (to setup
> > > ProjectNatures
> > > > ?).
> > > >
> > > > Many other extensions could be added this way to the eclipse
> plugin :
> > > > generate SpringIDE configuration, setup Checkstyle in sync
with
> the
> > > > maven-checkstyle configuration, etc.
> > > >
> > > > Another benefict is that the "extension" could benefict from
the
> forked
> > > > generate-source execution that the eclipse-plugin runs, to
access
> the
> > > list
> > > > of multi-project modules.
> > > >
> > > >
> > > > Any suggestion is welcome.
> > > >
> > > > Nicolas.
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > ..........................................................
> > >
> > > Arnaud HERITIER
> > > ..........................................................
> > > OCTO Technology - aheritier AT octo DOT com
> > > www.octo.com | blog.octo.com
> > > ..........................................................
> > > ASF - aheritier AT apache DOT org
> > > www.apache.org | maven.apache.org
> > > ...........................................................
> > >
> > >
> >
> >
> > >
> > > To unsubscribe, e-mail: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> >
>
>
>
>
> --
>
> ..........................................................
> Arnaud HERITIER
> ..........................................................
> OCTO Technology - aheritier AT octo DOT com
> www.octo.com | blog.octo.com
> ..........................................................
> ASF - aheritier AT apache DOT org
> www.apache.org | maven.apache.org
> ...........................................................
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: [proposal] eclipse plugin extensibility
| Free Forum Powered by Nabble | Forum Help |