Offering a module as a plugin does not necessarily mean that its optional. The Tomcat and Jetty modules, for example, are offered as plugins. So if server/trunk needs to be streamlined for JEE5 then I think it would make more sense to create an "opt" or "extras" bucket for modules that aren't required for JEE5 like geronimo-directory, geronimo-clustering, etc.
I like the idea of speeding up the build and making it easier to manage optional components. But I'm concerned that factoring modules out of trunk could make the release manager's job more difficult since this new tree would also have to be taken into consideration when branching a release of the server. This has proven to be a challenge with geronimo/specs, for example. It would also be more difficult to create assemblies that contain these optional modules using maven since they are built in different src trees. Best wishes, Paul On 1/16/07, Donald Woods <[EMAIL PROTECTED]> wrote:
Right, but why leave it in the normal modules build, which slows down the builds for everyone and introduces more churn to the server when newer levels of ApacheDS comes out (like 1.0)? I would rather see the directory module moved to the plugins directory and only built and published by gbuild when a change occurs. If we want to start using plugins for more "options" outside of the required JEE 5 features, then why not start by cleaning up the server/trunk and remove all samples and add-ons? I'd be glad to create a patch to remove ApacheDS from trunk and recreate it under geronimo/plugins for both the 0.92 and 1.0 levels. -Donald Paul McMahan wrote: > On 1/12/07, Hernan Cunico <[EMAIL PROTECTED]> wrote: >> Paul McMahan wrote: >> > OK now that I'm looking deeper into this things are becoming clearer. >> > First of all, as you pointed out the directory module is already >> > included in the jee5 assembly, which I wasn't aware of. Apparently >> > the commit that was supposed to have removed it from the dist only >> > updated the config.xml and not the pom, which seems to have left it in >> > the repo even though it's not listed in the server configuration. Or >> > maybe just removing it from the config.xml was sufficient to prune it >> > from the dist before we started building with m2(?). So at any rate, >> > its in the assembly now just not listed in config.xml or started by >> > default. >> >> right, so we should decide whether we ship it as a plugin or in the >> assembly (properly configured and enabled). If we go with the plugin >> idea then we should remove the mod and conf and any other traces from >> the branch (not just the assembly). If we go the other way around >> maybe we should remove the plugin for 1.2 and 2.0 as an alternative >> trying to avoid confusion. > > It's not necessary (or IMO desirable) to remove a component from the > branch when its offered as a plugin instead of enabled in the default > assembly. IMO. the decision about whether or not a component is part > of some particular assembly shouldn't necessarily dictate where the > source for that component resides. As long as the component remains > in the branch we retain the option of enabling it in an assembly or > offering it as a plugin, or both. > > In this case we're talking about the directory component. If we > include it in the default assembly then we should still offer it as a > plugin since someone might uninstall it and then later decide to > reinstall it as a plugin. > >> Either way, although important, I think now that is less critical as >> the plugin configuration (Geronimo side) is working. > > agreed > > Best wishes, > Paul > >
