directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <flame...@gmail.com>
Subject Re: [naming] Thoughts... Was: How are we all progressing
Date Tue, 21 Dec 2004 15:28:56 GMT
All sounds good to me too.

I started work on splitting config out, so can go ahead and check that
in. Keeping in line with the Tomcat version for a lot of this makes a
lot of sense as the hope is that they'll be happy relying on naming in
the future.

Hen


On Tue, 21 Dec 2004 13:44:58 +0800, Brett Porter <brett@apache.org> wrote:
> Hi Phil,
> 
> Have read it all and +1 to everything including packaging and collections
> update. Nice job.
> 
> As always, I'm happy to help out with anything regarding the Maven build. I'd
> suggest laying these all out as subprojects of naming, and not going into
> multiple levels of subprojects.
> 
> You should be able to run maven multiproject:install or multiproject:site from
> naming/trunk and have it all work.
> 
> Cheers,
> Brett
> 
> Quoting Phil Steitz <phil@steitz.com>:
> 
> > See comments below.  I am off this week and would really like to crank
> > through the work necessary to get [naming] releasable by the end of the
> > week (incl weekend ;-).  I have proposed some things below on packaging
> > which will lead to restructuring maven subprojects or at least changing
> > jar targets.  Right now I am focussing on cleaning up the javadoc and
> > tests -- just hitting the big things.  Next I will work on better setup,
> > using and overview docs.  If others agree with the jar stuff, any help
> > getting all of this to work in maven would be appreciated.
> >
> > Phil
> >
> >
> > Henri Yandell wrote:
> > > On Sun, 12 Dec 2004 20:48:39 -0500, Phil Steitz <phil@steitz.com> wrote:
> > >
> > >>I would like to get a [naming] release out as well.  The core existing
> > >>code is certainly stable and well-tested from use in tomcat. To get a
> > >
> > >
> > > I assume you mean we'd prioritise a release of naming-core?
> > >
> > >
> > >>0.8-ish release out, I think we need to do the following:
> > >>
> > >>1) Settle the jar division issue. Probably end up with 3 or more jars.
> > >>This is not a huge issue, but we need to get it right so users have good
> > >>flexibility and both building and integrating are easy. I will keep
> > >>pestering Hen until he figures it out ;-)
> > >
> > >
> > > I'd definitely like to split it into more jars.
> > >
> > > Immediate thoughts:
> > >
> > > naming-core (keeping jmx bits in here for the moment)
> > > naming-config (Brett's XmlConfigurator bits)
> > > naming-factory (Most of the factories; EjbRef, TransactionRef)
> > > naming-factory-mail (Couple of factories that add a dep)
> > > naming-resource (core.resource package; resource factories; resource refs)
> > >
> > > I don't fully grokk resources though, so I might be missing a lot.
> > >
> > > What do you think? Too much?
> >
> > I am starting to favor the tomcat-5 split:
> >
> > naming-core (tc calls this naming-common)
> > Everything in o.a.naming
> > Includes basic naming service and context impl
> > Depends on JMX for NamingService
> >
> > naming-factory
> > Object factories
> > Everything in o.a.naming.factory
> > Depends on core and the mail API spec to compile; if used, mail session
> > and database connection pool builtins require javamail and commons-dbcp,
> > resp.
> >
> > naming-java
> > Only JavaURLContextFactory
> > Depends on core
> >
> > naming-resources
> > JNDI access to file / stream resources
> > o.a.c.naming.resources
> > Depends on core and commons collections
> >
> > Plus the config stuff separately:
> > naming-config
> > Contents of o.a.c.naming.config
> > Depends on core, and commons beanutils, digester, lang, and logging
> >
> > For some reason, tomcat puts o.a.naming.factory.ResourceLinkFactory and
> > o.a.naming.factory.ResourceLinkFactory.Contants into common (core).  I
> > suspect that this is so that just core and naming-resources are required
> > to set up file and war resources. I recommend that we also do this --
> > i.e., follow the tc setup.
> >
> > I know this is a lot of jars, but the division is logical and limits
> > dependencies for the core stuff.
> >
> > Commons collections is used only in naming-resources and only one class
> > is used.  Unfortunately, the one class used -- LRUMap is both essential
> > and has additional dependencies in [collections] that would be hard to
> > pull out sensibly.  The version used is the 3.0-deprecated 2.1-version,
> > referenced from the top level as o.a.c.c.LRUMap.  I propose that we
> > update the dependency (for the resources package) to collections 3.0 and
> > reference the new version in the Map subpackage.  Any objections?
> >
> > >
> > >
> > >>2) Improve the web site and docs -- need better explanation of how the
> > >>whole setup works.  Not a huge effort.  I should be able to get this
> > >>done in the next couple of weeks.
> > >
> > >
> > > Immediate thoughts:
> > >
> > > Remove apachecon logo
> > > Javadoc
> > > Clover
> > >
> > > Do we put javadoc, clover, source-html'd into svn for deploys?
> > >
> > > Run maven then cp by hand onto svn? rsync --delete locally?
> >
> > I don't see why we need to store the generated html in svn -- just xdocs.
> > >
> > >
> > >>3) Improve package and source javadocs.  Lots of time could be spent
> > >>here; but I can combine this with 2) and get us into decent shape in a
> > >>couple of weeks.
> > >
> > >
> > > First step, fix the bits that mention server.xml and any other Tomcat
> > > specific stuff.
> >
> > Working on this.
> > >
> > >
> > >>4) Clean up the tests and increase coverage to the point where we have
> > >>at least some coverage of all key classes / functions.  This is where I
> > >>may not be able to get it all done in time for a 2004 release; but I
> > >>will do my best.  Once I improve the docs, others may be able to step in
> > >>and help here more.
> > >
> > >
> > > Clover:
> > >
> > > http://www.apache.org/~bayard/naming-clover/
> >
> > Depressing...will make some progress, but I agree with Alex that release
> > should not be held for lack of full coverage.
> >
> > Phil
> > >
> > > Hen
> >
> 
>

Mime
View raw message