geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <paulmcma...@gmail.com>
Subject Re: ApacheDS - LDAP - Geronimo Plugins
Date Tue, 16 Jan 2007 17:34:54 GMT
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 <drw_web@yahoo.com> 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 <hcunico@gmail.com> 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
> >
> >
>
>
>

Mime
View raw message