what about creating several new eclipse features like ... * org.apache.openejb.branding ** org.apache.openejb.branding
* org.apache.openejb.help ** org.apache.openejb.help ** org.apache.openejb.help.nl1 ** org.apache.openejb.help.nl2 ** org.apache.openejb.help.nl2a ** org.apache.openejb.help.nlBidi * org.apache.openejb.annotation ** org.apache.openejb.helper.annotation ** org.apache.openejb.helper.annotation.test ** org.apache.openejb.builder * org.apache.openejb.server ** org.eclipse.jst.server.generic.openejb Most times it helps if you try to structure your plugins into fine granular features for example Geronimo could re-use OpenEJB features that way or vice versa. Factoring out common code into a commons/foundations/core plugin sounds reasonable as well. On Sun, Sep 21, 2008 at 3:08 PM, Jonathan Gallimore <[EMAIL PROTECTED]> wrote: > Hi All, > > I've been thinking a bit about the structure of our Eclipse plugin, and > wondered whether anyone else has any thoughts about it. I recently committed > some code to check dependencies between singleton beans (OPENEJB-910), and > added this functionality as a separate plugin within our feature in order to > separate it from the rest of our code. > > So currently we have the following plugins, all of which get bundled into a > single feature: > > org.apache.openejb.branding > org.apache.openejb.help > org.apache.openejb.help.nl1 > org.apache.openejb.help.nl2 > org.apache.openejb.help.nl2a > org.apache.openejb.help.nlBidi > org.apache.openejb.helper.annotation > org.apache.openejb.helper.annotation.test > org.apache.openejb.builder > org.eclipse.jst.server.generic.openejb > > We also have a plugins-common module which provides the common annotation > generation code, and has no Eclipse specific code (so it could be used for > outputting changes to the command line for example). > > The org.apache.openejb.builder plugin is the new plugin I added for the > singleton dependency checker. org.apache.openejb.helper.annotation is the > plugin which uses the JDT API to add annotations to source code, and > org.eclipse.jst.server.generic.openejb provides the WTP extensions to run a > standalone server in Eclipse. > > Does anyone have any thoughts on the plugin structure? Do you think its best > to continue down the route of separating each different piece of > functionality into different plugins, or would some consolidation be useful? > There is some common code in the annotation and builder plugins, so I was > thinking it might be worth either merging them together, or creating a > 'core' plugin that they both depend on. > > Secondly, what does everybody think of the plugin names? We already have a > Jira logged for the namespace of the org.eclipse.jst.server.generic.openejb > (OPENEJB-867). > > I was thinking along the lines of merging the > org.apache.openejb.helper.annotation and the org.apache.openejb.builder > plugins together, and renaming it to org.apache.openejb.tools (and renaming > the test plugin to match), and renaming the > org.eclipse.jst.server.generic.openejb plugin to org.apache.openejb.server. > > > Any thoughts / ideas anyone has would be most welcome :) > > Jon >
