Just thinking out loud but what about importing all the classes from the extser package into JDBM's repository?   (We could optionally rename the packages so it looks more coherent).

Separately, there's the issue of having a dependency on code with a different license, which does not make it any easier to "consume" JDBM.


On 10/17/07, Kevin Day <kevin@trumpetinc.com> wrote:
Hi all-
I just got connected up with SourceForge again and grabbed the latest jdbm HEAD.  I'm seeing a dependency injected into a lot of the jdbm classes (BTree, BPage, etc...) for another jar than the basic jdbm jar.
I would like to open up a discussion about this, as I'm a bit concerned about maintainability and keeping the jdbm deployment simple and cohesive.  I know that when we were looking at native hashmap implementations, I actually went so far as to approach the developer of the library to ask that we be able to pull his source into the jdbm package tree.
Is there an alternative approach that we can use that will achieve the result of this external dependency without actually having the dependency?
Even if this was a sub-project of jdbm (as opposed to a completely external project as it is now), I think it would be a good idea to make sure that it was pluggable (i.e. not a requirement for the use of jdbm unless a developer actually wanted the enhanced functionality).
- K

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Jdbm-developer mailing list