[Date Prev][Date Next]
Re: JLDAP README out of date
I think that README was written for packaged releases of JLDAP
(such as those provided by Novell). Just as in the main
'ldap' module, there are 'release' files in the CVS repository
that don't necessary line up with the CVS repository (but
hopefully do line up with releases). I don't believe any
of the "external" software was ever committed to the CVS
At 12:42 PM 5/16/2005, Jon Roberts wrote:
>I went to rebuild JLDAP from CVS source today and got some surprises which are not reflected in the docs. First, ant no longer comes with the distribution. That's fine by me since I'd prefer to use a local version, but it totally invalidates the README build instructions.
>The other concern is more problematic. Apparently the relatively new DsmlConnection class and util.HttpRequestCallback interface require classes from the external libraries org.apache.commons.httpclient and org.apache.commons.httpclient.methods. These are not listed as dependencies, yet without these external libraries JLDAP will not build under given targets.
>I know I should expect documentation to lag development and I could simply remove these classes to get a working build (I did), but I question this direction. Is it desirable for the core JLDAP libraries to accumulate dependencies on external libraries outside those in J2SE?
Well, philosophically, I don't have a problem with such dependencies
if they are essential to providing JLDAP functionality. So,
from my point of view, the question should be more about what
functionality is essential with a secondary question of how to
effectively and efficiently provide that functionality.
>Why can't this extended functionality instead be part of a separate distribution? At the very least, I would appreciate a build target that ignores this vestigial code.
It might be good to split 'core' functionality from other
functionality... but at present, there is no well defined
scope of what's 'core' and what's not.
>I know the right thing to do is to post ITS reports and patches to this effect, which I will do,
>but I wanted to pose the philosophical question here first because I would prefer to see a self-contained JLDAP.
>It is, after all, the fundamental dependency for my current work. On the other hand, if there is no concern for scoping JLDAP I have a boatload of working code to accomplish a number of particular and extraneous tasks that I'd be happy to contribute myself!