geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: ApacheDS - LDAP - Geronimo Plugins
Date Tue, 16 Jan 2007 17:50:59 GMT
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 <paulmcmahan@gmail.com> 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 <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