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] Next steps
Date Tue, 07 Dec 2004 14:05:17 GMT
On Mon, 06 Dec 2004 23:44:46 -0500, Phil Steitz <phil@steitz.com> wrote:
> Alex Karasulu wrote:
> > Henri Yandell wrote:
> >
> >
> >> * My aim is to switch simple-jndi to using naming-core as its
> >> underlying jndi engine. The only real feature I'll lose is that the
> >> simple-jndi database is live, so I'll probably add some kind of
> >> file-polling later on (Commons-IO needs that anyway if it's not
> >> already there).
> 
> What do you mean "the database is live" - you mean it is backed by a
> persistent store that can be modified?  Seems to me that this use case
> would be better served by Eve (see Alex's earlier post).  [naming] is
> essentially an in-memory JNDI provider that can be bootstrapped from
> config files (or other persistent store).  I don't understand the use
> cases for file polling. Why not use the JNDI APIs?  What kind of thing
> do you have in mind here?

I mean that each Context.lookup lead to a .properties file being read
(unless being accessed via the classpath in which case it would be
cached by the loader). :) It was a nice feature, but less important.

> >> * Build instructions on the site. We need to get better instructions
> >> there on how to check out of svn (all of directory needs this improved
> >> I think, took me a long time to find the svn url).
> 
> Agreed, though what we have here is not that bad:
> http://incubator.apache.org/directory/svn.html

Okay, awards for someone who can explain how I missed this that don't
paint me as a complete idiot :)

> I'd also suggest
> >> that we switch to telling people to build core and factory
> >> individually rather as a big multiproject build.
> 
> Agreed.
> >> All the factory
> >> dependency crap (javamail/jta etc) gets in the way of a nice easy core
> >> build.
> 
> Yes, for maven.  The ant build works fine from /core with just commons
> collections and mx4j as dependencies.  The extra dependencies in the

The maven build does too. Just that our instructions on the site are
multiproject based.

> maven build must be coming from the POM inheritance.  I have not tried
> this, but overriding the combined dependencies in the parent in
> project.xml for core might work.  In any case, I agree that this needs
> to be cleaned up.  May be best to can the multiproject approach.

I'd still keep it for the site, but basically go the way of Commons.
Build locally and do the site in one big go (though later on local
sites should be just as doable).

> A bigger issue is the large number of dependencies in /factory and the
> question of whether or not the two packages are correctly divided.  Any
> thoughts on how this can be improved would be appreciated.

Yeah, am pondering that already.

I noticed that in Tomcat, this code ships as 4 jars. resources,
factory, common and java.
Will ponder further as I dig more into the code again.

Hen

Mime
View raw message