Re: [proposal] eclipse plugin extensibility
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
Great, Count on me for flexbuilder support. VELO On Wed, Apr 30, 2008 at 10:58 AM, Arnaud HERITIER [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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 [EMAIL PROTECTED] 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 artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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 artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
On 23/04/2008, Simone Gianni [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
It's exactly why I want to do for a 3.0 release of the plugin. What we could have is to try to discover features of eclipse reading its workspace. For each feature/plugin we try to find in the writers list (loaded by default or through the plugin config) the most recent version of the writer compatible for this feature/plugin. Today we have writers for rad 6, wtp (0.7 to 2.0), ... Each writer registers which files it creates to be able to remove them with eclipse:clean This feature could allow us to remove a lot of settings and extra goals (:myeclipse, :rad, ..) that we have to maintain to support those plugins. You'll have my support to implement it. Arnaud On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : plugin artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/version /dependency /dependencies /plugin Beeing added to the plugin classpath, the plugin-extension could add it's EclipseWriters, and maybe other optional components (to setup ProjectNatures ?). Many other extensions could be added this way to the eclipse plugin : generate SpringIDE configuration, setup Checkstyle in sync with the maven-checkstyle configuration, etc. Another benefict is that the extension could benefict from the forked generate-source execution that the eclipse-plugin runs, to access the list of multi-project modules. Any suggestion is welcome. Nicolas. -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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 [EMAIL PROTECTED]: 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 artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
Your idea is complementary to mine : You want to discover what the target eclipse installation can do and extract any usefull configuration from maven to setup the workspace. My idea was to plug into the eclipse plugin the dedicated contributors - but they could themself rely on what eclipse supports to create dedicated setup. Do you have any idea of a maven way to bypass plugins isolation, so that the eclipse plugin can lookup other plugins (let's say checkstyle report plugin) for a contributor, expose the eclipse workspace capabilities and let the contributor create additional files or register additional configuration elements ? AFAIK this requires a maven extension to share a plugin contributor API, but maybe I'm wrong. Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: It's exactly why I want to do for a 3.0 release of the plugin. What we could have is to try to discover features of eclipse reading its workspace. For each feature/plugin we try to find in the writers list (loaded by default or through the plugin config) the most recent version of the writer compatible for this feature/plugin. Today we have writers for rad 6, wtp (0.7 to 2.0), ... Each writer registers which files it creates to be able to remove them with eclipse:clean This feature could allow us to remove a lot of settings and extra goals (:myeclipse, :rad, ..) that we have to maintain to support those plugins. You'll have my support to implement it. Arnaud On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : plugin artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/version /dependency /dependencies /plugin Beeing added to the plugin classpath, the plugin-extension could add it's EclipseWriters, and maybe other optional components (to setup ProjectNatures ?). Many other extensions could be added this way to the eclipse plugin : generate SpringIDE configuration, setup Checkstyle in sync with the maven-checkstyle configuration, etc. Another benefict is that the extension could benefict from the forked generate-source execution that the eclipse-plugin runs, to access the list of multi-project modules. Any suggestion is welcome. Nicolas. -- .. Arnaud HERITIER .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
No it's impossible in maven 2.0.x to load those writers from another plugin. In my mind we have to add all writers as plugin's dependency. By default we'll propose a large set of existing writers, but users will also be able to add their own. By default we'll have something like : eclipse-plugin |- eclipse-core |- eclipse-writers-api |- eclipse-writers |- eclipse-wtp-0.7-writer |- eclipse-wtp-1.0-writer |- eclipse-wtp-2.0-writer |- eclipse-rad-6.0-writer |- eclipse-myeclipse-5.0-writer By default we'll propose all our writers and perhaps in the future some others defined in others projects. We have a writer for each version of configuration files. Users we'll be able to set the version of each version or they'll inform about their workspace location to let the plugin find the version for version. Arnaud On Wed, Apr 23, 2008 at 3:13 PM, nicolas de loof [EMAIL PROTECTED] wrote: Your idea is complementary to mine : You want to discover what the target eclipse installation can do and extract any usefull configuration from maven to setup the workspace. My idea was to plug into the eclipse plugin the dedicated contributors - but they could themself rely on what eclipse supports to create dedicated setup. Do you have any idea of a maven way to bypass plugins isolation, so that the eclipse plugin can lookup other plugins (let's say checkstyle report plugin) for a contributor, expose the eclipse workspace capabilities and let the contributor create additional files or register additional configuration elements ? AFAIK this requires a maven extension to share a plugin contributor API, but maybe I'm wrong. Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: It's exactly why I want to do for a 3.0 release of the plugin. What we could have is to try to discover features of eclipse reading its workspace. For each feature/plugin we try to find in the writers list (loaded by default or through the plugin config) the most recent version of the writer compatible for this feature/plugin. Today we have writers for rad 6, wtp (0.7 to 2.0), ... Each writer registers which files it creates to be able to remove them with eclipse:clean This feature could allow us to remove a lot of settings and extra goals (:myeclipse, :rad, ..) that we have to maintain to support those plugins. You'll have my support to implement it. Arnaud On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : plugin artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/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
Re: [proposal] eclipse plugin extensibility
Right This will work on a per file to generate basis, isn't it ? What if a contributor want's to add a buildcommand (for example checkstyle) ? I don't think we just need a eclipse-writers-api, but a larger eclipse-plugin-contributor-api that includes - eclipse feature detection (to allow my Foo contributor to detect the Foo feature is enabled on eclipse) - eclipseConfig customizer to add projectNatures, builders, dependencies, classpathcontainers ... used by other writers - and the writer-api Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: No it's impossible in maven 2.0.x to load those writers from another plugin. In my mind we have to add all writers as plugin's dependency. By default we'll propose a large set of existing writers, but users will also be able to add their own. By default we'll have something like : eclipse-plugin |- eclipse-core |- eclipse-writers-api |- eclipse-writers |- eclipse-wtp-0.7-writer |- eclipse-wtp-1.0-writer |- eclipse-wtp-2.0-writer |- eclipse-rad-6.0-writer |- eclipse-myeclipse-5.0-writer By default we'll propose all our writers and perhaps in the future some others defined in others projects. We have a writer for each version of configuration files. Users we'll be able to set the version of each version or they'll inform about their workspace location to let the plugin find the version for version. Arnaud On Wed, Apr 23, 2008 at 3:13 PM, nicolas de loof [EMAIL PROTECTED] wrote: Your idea is complementary to mine : You want to discover what the target eclipse installation can do and extract any usefull configuration from maven to setup the workspace. My idea was to plug into the eclipse plugin the dedicated contributors - but they could themself rely on what eclipse supports to create dedicated setup. Do you have any idea of a maven way to bypass plugins isolation, so that the eclipse plugin can lookup other plugins (let's say checkstyle report plugin) for a contributor, expose the eclipse workspace capabilities and let the contributor create additional files or register additional configuration elements ? AFAIK this requires a maven extension to share a plugin contributor API, but maybe I'm wrong. Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: It's exactly why I want to do for a 3.0 release of the plugin. What we could have is to try to discover features of eclipse reading its workspace. For each feature/plugin we try to find in the writers list (loaded by default or through the plugin config) the most recent version of the writer compatible for this feature/plugin. Today we have writers for rad 6, wtp (0.7 to 2.0), ... Each writer registers which files it creates to be able to remove them with eclipse:clean This feature could allow us to remove a lot of settings and extra goals (:myeclipse, :rad, ..) that we have to maintain to support those plugins. You'll have my support to implement it. Arnaud On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : plugin artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdsysdeo-tomcat-maven-plugin/artifactId versionx/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
RE: [proposal] eclipse plugin extensibility
Now that there are two real eclipse plugins for maven, I have to wonder how much use this plugin will continue to get and if it's worth such a major overhaul? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nicolas de loof Sent: Wednesday, April 23, 2008 9:42 AM To: Maven Developers List Subject: Re: [proposal] eclipse plugin extensibility Right This will work on a per file to generate basis, isn't it ? What if a contributor want's to add a buildcommand (for example checkstyle) ? I don't think we just need a eclipse-writers-api, but a larger eclipse-plugin-contributor-api that includes - eclipse feature detection (to allow my Foo contributor to detect the Foo feature is enabled on eclipse) - eclipseConfig customizer to add projectNatures, builders, dependencies, classpathcontainers ... used by other writers - and the writer-api Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: No it's impossible in maven 2.0.x to load those writers from another plugin. In my mind we have to add all writers as plugin's dependency. By default we'll propose a large set of existing writers, but users will also be able to add their own. By default we'll have something like : eclipse-plugin |- eclipse-core |- eclipse-writers-api |- eclipse-writers |- eclipse-wtp-0.7-writer |- eclipse-wtp-1.0-writer |- eclipse-wtp-2.0-writer |- eclipse-rad-6.0-writer |- eclipse-myeclipse-5.0-writer By default we'll propose all our writers and perhaps in the future some others defined in others projects. We have a writer for each version of configuration files. Users we'll be able to set the version of each version or they'll inform about their workspace location to let the plugin find the version for version. Arnaud On Wed, Apr 23, 2008 at 3:13 PM, nicolas de loof [EMAIL PROTECTED] wrote: Your idea is complementary to mine : You want to discover what the target eclipse installation can do and extract any usefull configuration from maven to setup the workspace. My idea was to plug into the eclipse plugin the dedicated contributors - but they could themself rely on what eclipse supports to create dedicated setup. Do you have any idea of a maven way to bypass plugins isolation, so that the eclipse plugin can lookup other plugins (let's say checkstyle report plugin) for a contributor, expose the eclipse workspace capabilities and let the contributor create additional files or register additional configuration elements ? AFAIK this requires a maven extension to share a plugin contributor API, but maybe I'm wrong. Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: It's exactly why I want to do for a 3.0 release of the plugin. What we could have is to try to discover features of eclipse reading its workspace. For each feature/plugin we try to find in the writers list (loaded by default or through the plugin config) the most recent version of the writer compatible for this feature/plugin. Today we have writers for rad 6, wtp (0.7 to 2.0), ... Each writer registers which files it creates to be able to remove them with eclipse:clean This feature could allow us to remove a lot of settings and extra goals (:myeclipse, :rad, ..) that we have to maintain to support those plugins. You'll have my support to implement it. Arnaud On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : plugin artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies dependency groupIdorg.codehaus.mojo
Re: [proposal] eclipse plugin extensibility
You're right. It's not only writers but all configuration files. Arnaud On Wed, Apr 23, 2008 at 3:41 PM, nicolas de loof [EMAIL PROTECTED] wrote: Right This will work on a per file to generate basis, isn't it ? What if a contributor want's to add a buildcommand (for example checkstyle) ? I don't think we just need a eclipse-writers-api, but a larger eclipse-plugin-contributor-api that includes - eclipse feature detection (to allow my Foo contributor to detect the Foo feature is enabled on eclipse) - eclipseConfig customizer to add projectNatures, builders, dependencies, classpathcontainers ... used by other writers - and the writer-api Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: No it's impossible in maven 2.0.x to load those writers from another plugin. In my mind we have to add all writers as plugin's dependency. By default we'll propose a large set of existing writers, but users will also be able to add their own. By default we'll have something like : eclipse-plugin |- eclipse-core |- eclipse-writers-api |- eclipse-writers |- eclipse-wtp-0.7-writer |- eclipse-wtp-1.0-writer |- eclipse-wtp-2.0-writer |- eclipse-rad-6.0-writer |- eclipse-myeclipse-5.0-writer By default we'll propose all our writers and perhaps in the future some others defined in others projects. We have a writer for each version of configuration files. Users we'll be able to set the version of each version or they'll inform about their workspace location to let the plugin find the version for version. Arnaud On Wed, Apr 23, 2008 at 3:13 PM, nicolas de loof [EMAIL PROTECTED] wrote: Your idea is complementary to mine : You want to discover what the target eclipse installation can do and extract any usefull configuration from maven to setup the workspace. My idea was to plug into the eclipse plugin the dedicated contributors - but they could themself rely on what eclipse supports to create dedicated setup. Do you have any idea of a maven way to bypass plugins isolation, so that the eclipse plugin can lookup other plugins (let's say checkstyle report plugin) for a contributor, expose the eclipse workspace capabilities and let the contributor create additional files or register additional configuration elements ? AFAIK this requires a maven extension to share a plugin contributor API, but maybe I'm wrong. Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: It's exactly why I want to do for a 3.0 release of the plugin. What we could have is to try to discover features of eclipse reading its workspace. For each feature/plugin we try to find in the writers list (loaded by default or through the plugin config) the most recent version of the writer compatible for this feature/plugin. Today we have writers for rad 6, wtp (0.7 to 2.0), ... Each writer registers which files it creates to be able to remove them with eclipse:clean This feature could allow us to remove a lot of settings and extra goals (:myeclipse, :rad, ..) that we have to maintain to support those plugins. You'll have my support to implement it. Arnaud On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin could setup a list of external EclipseWriters to run. sample configuration : plugin artifactIdmaven-eclipse-plugin/artifactId configuration ... extensions extension idsysdeo-tomcat/id !-- matches some META-INF metadatas in sysdeo-tomcat-maven-plugin.jar -- configuration !-- extension dependent configuration -- /configuration extension extensions /configuration dependencies
Re: [proposal] eclipse plugin extensibility
That is THE question and why I didn't yet start this dev. In fact it depends a lot of those IDE plugins. I don't know how many time they will need to support all our features even if they are working fast. We have a lot of features now (which is also a problem now) but they are used a lot in corporate environments. Arnaud On Wed, Apr 23, 2008 at 3:52 PM, Brian E. Fox [EMAIL PROTECTED] wrote: Now that there are two real eclipse plugins for maven, I have to wonder how much use this plugin will continue to get and if it's worth such a major overhaul? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nicolas de loof Sent: Wednesday, April 23, 2008 9:42 AM To: Maven Developers List Subject: Re: [proposal] eclipse plugin extensibility Right This will work on a per file to generate basis, isn't it ? What if a contributor want's to add a buildcommand (for example checkstyle) ? I don't think we just need a eclipse-writers-api, but a larger eclipse-plugin-contributor-api that includes - eclipse feature detection (to allow my Foo contributor to detect the Foo feature is enabled on eclipse) - eclipseConfig customizer to add projectNatures, builders, dependencies, classpathcontainers ... used by other writers - and the writer-api Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: No it's impossible in maven 2.0.x to load those writers from another plugin. In my mind we have to add all writers as plugin's dependency. By default we'll propose a large set of existing writers, but users will also be able to add their own. By default we'll have something like : eclipse-plugin |- eclipse-core |- eclipse-writers-api |- eclipse-writers |- eclipse-wtp-0.7-writer |- eclipse-wtp-1.0-writer |- eclipse-wtp-2.0-writer |- eclipse-rad-6.0-writer |- eclipse-myeclipse-5.0-writer By default we'll propose all our writers and perhaps in the future some others defined in others projects. We have a writer for each version of configuration files. Users we'll be able to set the version of each version or they'll inform about their workspace location to let the plugin find the version for version. Arnaud On Wed, Apr 23, 2008 at 3:13 PM, nicolas de loof [EMAIL PROTECTED] wrote: Your idea is complementary to mine : You want to discover what the target eclipse installation can do and extract any usefull configuration from maven to setup the workspace. My idea was to plug into the eclipse plugin the dedicated contributors - but they could themself rely on what eclipse supports to create dedicated setup. Do you have any idea of a maven way to bypass plugins isolation, so that the eclipse plugin can lookup other plugins (let's say checkstyle report plugin) for a contributor, expose the eclipse workspace capabilities and let the contributor create additional files or register additional configuration elements ? AFAIK this requires a maven extension to share a plugin contributor API, but maybe I'm wrong. Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: It's exactly why I want to do for a 3.0 release of the plugin. What we could have is to try to discover features of eclipse reading its workspace. For each feature/plugin we try to find in the writers list (loaded by default or through the plugin config) the most recent version of the writer compatible for this feature/plugin. Today we have writers for rad 6, wtp (0.7 to 2.0), ... Each writer registers which files it creates to be able to remove them with eclipse:clean This feature could allow us to remove a lot of settings and extra goals (:myeclipse, :rad, ..) that we have to maintain to support those plugins. You'll have my support to implement it. Arnaud On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin as an EclipseWriter it could benefict from the original code, and also from plugin updates. I propose to add a new extensibility feature in the eclipse plugin. Using a new parameter, or maybe by searching some extension file in the plugin classpath, the eclipse plugin
Re: [proposal] eclipse plugin extensibility
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: Now that there are two real eclipse plugins for maven, I have to wonder how much use this plugin will continue to get and if it's worth such a major overhaul? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nicolas de loof Sent: Wednesday, April 23, 2008 9:42 AM To: Maven Developers List Subject: Re: [proposal] eclipse plugin extensibility Right This will work on a per file to generate basis, isn't it ? What if a contributor want's to add a buildcommand (for example checkstyle) ? I don't think we just need a eclipse-writers-api, but a larger eclipse-plugin-contributor-api that includes - eclipse feature detection (to allow my Foo contributor to detect the Foo feature is enabled on eclipse) - eclipseConfig customizer to add projectNatures, builders, dependencies, classpathcontainers ... used by other writers - and the writer-api Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: No it's impossible in maven 2.0.x to load those writers from another plugin. In my mind we have to add all writers as plugin's dependency. By default we'll propose a large set of existing writers, but users will also be able to add their own. By default we'll have something like : eclipse-plugin |- eclipse-core |- eclipse-writers-api |- eclipse-writers |- eclipse-wtp-0.7-writer |- eclipse-wtp-1.0-writer |- eclipse-wtp-2.0-writer |- eclipse-rad-6.0-writer |- eclipse-myeclipse-5.0-writer By default we'll propose all our writers and perhaps in the future some others defined in others projects. We have a writer for each version of configuration files. Users we'll be able to set the version of each version or they'll inform about their workspace location to let the plugin find the version for version. Arnaud On Wed, Apr 23, 2008 at 3:13 PM, nicolas de loof [EMAIL PROTECTED] wrote: Your idea is complementary to mine : You want to discover what the target eclipse installation can do and extract any usefull configuration from maven to setup the workspace. My idea was to plug into the eclipse plugin the dedicated contributors - but they could themself rely on what eclipse supports to create dedicated setup. Do you have any idea of a maven way to bypass plugins isolation, so that the eclipse plugin can lookup other plugins (let's say checkstyle report plugin) for a contributor, expose the eclipse workspace capabilities and let the contributor create additional files or register additional configuration elements ? AFAIK this requires a maven extension to share a plugin contributor API, but maybe I'm wrong. Nico. 2008/4/23, Arnaud HERITIER [EMAIL PROTECTED]: It's exactly why I want to do for a 3.0 release of the plugin. What we could have is to try to discover features of eclipse reading its workspace. For each feature/plugin we try to find in the writers list (loaded by default or through the plugin config) the most recent version of the writer compatible for this feature/plugin. Today we have writers for rad 6, wtp (0.7 to 2.0), ... Each writer registers which files it creates to be able to remove them with eclipse:clean This feature could allow us to remove a lot of settings and extra goals (:myeclipse, :rad, ..) that we have to maintain to support those plugins. You'll have my support to implement it. Arnaud On Fri, Apr 18, 2008 at 1:02 PM, nicolas de loof [EMAIL PROTECTED] wrote: Hello, I'd like to propose an extension mecanism for the Eclipse plugin (and potentially for other plugins). The sysdeo-tomcat-maven-plugin (mojo project) for example has copie/pasted the dependency resolution code from eclipse plugin. This was required to create the .tomcatPlugin configuration file. If this plugin code could execute *inside* the eclipse plugin
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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [proposal] eclipse plugin extensibility
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
On Wed, Apr 23, 2008 at 4:49 PM, Brian E. Fox [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] eclipse plugin extensibility
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
