If you're willing and able to dual-license the extser package under the current JDBM license, I can easily update the build to download the extser .jar from a Maven2 repo, merge it with JDBM classes and create a unique .jar for JDBM with no external dependencies and a single license. This would avoid a fork and keep JDBM small and simple -- programmatically _and_ legally.
Kevin, how does that sound?
(Re-posting this on behalf of Bryan since he's having problems with the listserv -- alex)
The extser package contributes an optional serialization for jdbm that
provides for tight fast serialization for the btree nodes and leaves and
for application data records.
I am willing to contribute the code to JDBM if that is the best thing.
I am still around and able to support the code if something goes wrong -
and you can always fork it if I disappear.
The best reason not to fork the code is because it is used in other
works (mainly my own) that will lose cross-backend support with a code
I am planning to revisit this code over the few months. I've been
working on a high-concurrency database architecture and I would like to
layer the extser support onto it for high level object model support.
I've also been looking at other options for packed data, in particular
some of the support from mg4j for bit streams, hu-tucker codings, and
various kinds of packed int and long value codings.
Hope you've been well,
-bryanOn 10/17/07, Alex Boisvert < email@example.com> wrote: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.
alexOn 10/17/07, Kevin Day < firstname.lastname@example.org> 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).thanks,- K