I think the decision should depend to some degree on whether the
module is tightly integrated such that it needs to be re-released for
every Geronimo release. I'm not sure about the directory plugin, but
I think a lot of plugins that involve third-party software probably
don't need to be re-released for every Geronimo maintenance release --
and may be more dependent on new revisions of the third-party software
than on new revisions of Geronimo. That would suggest they should be
maintained outside the Geronimo trunk to me.
Thanks,
Aaron
On 1/16/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
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
> >
> >
>
>
>
