directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [naming] Thoughts... Was: How are we all progressing
Date Tue, 21 Dec 2004 03:26:41 GMT
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.


Henri Yandell wrote:
> On Sun, 12 Dec 2004 20:48:39 -0500, Phil Steitz <> 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

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, 

Only JavaURLContextFactory
Depends on core

JNDI access to file / stream resources
Depends on core and commons collections

Plus the config stuff separately:
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:

Depressing...will make some progress, but I agree with Alex that release 
should not be held for lack of full coverage.

> Hen

View raw message