directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: [naming] Thoughts... Was: How are we all progressing
Date Tue, 21 Dec 2004 05:44:58 GMT
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