I think your request is very reasonable. However, this really is an integrated component. Both the file system and the maps rely on the locks. Compare this to e.g.
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html where you have a similar structure for more general concurrent Java programming. You have locks that are used by the channels and the collections and some more general purpuse helpers. You would not split this to more than one package, would you? Now, the transaction component aims at the same thing as the concurrent package, but is specific to transactions. You are very right and this really should be made explicite, thus I will add this as a scope to the index page of the transaction component ASAP. May a presume that this changes your vote to +1? Oliver On Tue, 16 Nov 2004 21:13:11 +0000, robert burrell donkin <[EMAIL PROTECTED]> wrote: > i like what i see but at the moment i'm +0... > > i'm a little uncertain whether the scope of the component has been > given the thought it deserves. the description describes what's in > transaction rather than the proposed scope for the component. in some > ways, at the moment transaction feels like four good components rather > than one. > > (this might seem a little pedantic but component scopes have proved > useful in the past) > > with a good scope added to the proposal, i'd be willing to alter my > vote to +1. > > - robert > > > > On 15 Nov 2004, at 17:43, Oliver Zeigermann wrote: > > > Folks, > > > > as described in previous posts and inspired by the fine proposal for > > email promotion I would like to see the transaction component > > > > http://jakarta.apache.org/commons/sandbox/transaction/ > > > > promoted to commons proper. > > > > The initial committers would be Stefan L�tzkendorf, James Mason, > > Daniel Florey and me. AFAIK none of us is a committer in commons > > proper so the promotion would include making as committers there. > > > > We all are Jakarta Slide committers and this is where the component > > came from. We factored out code for a transactional file system, > > transactional maps (implementing Map interface) with different ACID > > strategies, general purpose locks and a few more helper classes. > > > > Junit tests exist for all parts and succeed: > > http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html > > > > Javadoc is pretty complete > > > > http://jakarta.apache.org/commons/sandbox/transaction/apidocs/ > > index.html > > > > and general documentation and even a short tutorial for locks exist: > > > > http://jakarta.apache.org/commons/sandbox/transaction/locks/ > > tutorial.html > > > > The transaction component is stable enough to be released as a 1.0 > > soon after promotion and would initially be maintained by the > > committers of the Slide community. Once promoted growth is anticipated > > as even in the sandbox it attracted some attention. > > > > As I am not a commons committer, I have no binding vote, but my > > non-binding vote of course is +1. > > > > Oliver > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
