Re: [transaction] Brainstorming for 2.0
I have now created a Wiki page for the 2.0 discussion: http://wiki.apache.org/jakarta-commons/Brainstorm_2%2e0 2007/3/9, Oliver Zeigermann [EMAIL PROTECTED]: Packae naming: As discussed here http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL PROTECTED] it might be a good idea to have a new package name for the 2.x version. I'd be +1 for that Oliver 2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]: Folks! As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) 2.) Library requirement (1.5 concurrent package?) 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) 4.) Scope (all restricted as possible) 5.) What else? Cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Brainstorming for 2.0
On 3/12/07, Oliver Zeigermann [EMAIL PROTECTED] wrote: I have now created a Wiki page for the 2.0 discussion: http://wiki.apache.org/jakarta-commons/Brainstorm_2%2e0 Not a particularly good page name, given that it's not scoped to Transaction in a any way. It could apply equally well to any Commons component heading for 2.0. -- Martin Cooper 2007/3/9, Oliver Zeigermann [EMAIL PROTECTED]: Packae naming: As discussed here http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL PROTECTED] it might be a good idea to have a new package name for the 2.x version. I'd be +1 for that Oliver 2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]: Folks! As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) 2.) Library requirement (1.5 concurrent package?) 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) 4.) Scope (all restricted as possible) 5.) What else? Cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Brainstorming for 2.0
On 3/12/07, Martin Cooper [EMAIL PROTECTED] wrote: On 3/12/07, Oliver Zeigermann [EMAIL PROTECTED] wrote: I have now created a Wiki page for the 2.0 discussion: http://wiki.apache.org/jakarta-commons/Brainstorm_2%2e0 Not a particularly good page name, given that it's not scoped to Transaction in a any way. It could apply equally well to any Commons component heading for 2.0. snip/ Had the same reaction, felt like adding a couple of pointers -- for help, see: http://wiki.apache.org/jakarta-commons/HelpContents For example, see: http://wiki.apache.org/jakarta-commons/SCXML/Tutorials/History You can rename by choosing Rename Page from the More Actions: dropdown from the menu towards the top of the page. -Rahul -- Martin Cooper 2007/3/9, Oliver Zeigermann [EMAIL PROTECTED]: Packae naming: As discussed here http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL PROTECTED] it might be a good idea to have a new package name for the 2.x version. I'd be +1 for that Oliver 2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]: Folks! As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) 2.) Library requirement (1.5 concurrent package?) 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) 4.) Scope (all restricted as possible) 5.) What else? Cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Brainstorming for 2.0
Right. Thanks for reporting, Martin! Changed to http://wiki.apache.org/jakarta-commons/Brainstorm_Transaction_2%2e0 Oliver 2007/3/12, Martin Cooper [EMAIL PROTECTED]: On 3/12/07, Oliver Zeigermann [EMAIL PROTECTED] wrote: I have now created a Wiki page for the 2.0 discussion: http://wiki.apache.org/jakarta-commons/Brainstorm_2%2e0 Not a particularly good page name, given that it's not scoped to Transaction in a any way. It could apply equally well to any Commons component heading for 2.0. -- Martin Cooper 2007/3/9, Oliver Zeigermann [EMAIL PROTECTED]: Packae naming: As discussed here http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL PROTECTED] it might be a good idea to have a new package name for the 2.x version. I'd be +1 for that Oliver 2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]: Folks! As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) 2.) Library requirement (1.5 concurrent package?) 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) 4.) Scope (all restricted as possible) 5.) What else? Cheers 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]
Re: [transaction] Brainstorming for 2.0
Packae naming: As discussed here http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200611.mbox/[EMAIL PROTECTED] it might be a good idea to have a new package name for the 2.x version. I'd be +1 for that Oliver 2007/3/4, Oliver Zeigermann [EMAIL PROTECTED]: Folks! As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) 2.) Library requirement (1.5 concurrent package?) 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) 4.) Scope (all restricted as possible) 5.) What else? Cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Brainstorming for 2.0
2007/3/4, Joerg Heinicke [EMAIL PROTECTED]: Oliver Zeigermann oliver.zeigermann at gmail.com writes: As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) Why not this list? Do you expect so much discussion? OK 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) Hmm, why require more than necessary? Java 5 brings the concurrent package, but Java 6? Higher requirements always limit the number of users. OK 4.) Scope (all restricted as possible) Scope of what? Access scope of interfaces, classes, methods? Normally I tend to limit it as less as possible to allow easy extending and sub classing. But if changes to the API are always related with such circumstances ... Scope of the implementation. Means only implement core, leave the rest to optional modules and custom implementation. My idea (and what I have learned from 1.x) is to only impement a core that does the transactional part. The rest can in done through calling implementation of interfaces - How does a transaction map to temporary data - Where is temporary data and final data stored (maybe use VFS?) - Id generator - what else? There should be a default implementation for interfaces, but it should be slim and rudimentary. This may result in having a transactional file store out of the box. Open Questions: - Is Jakarta Commons the right place for such a project? - Should we introduce threading in order to - Allow remote access / administration to a file store - Allow for deadlock detection in its own thread - what else? Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[transaction] Brainstorming for 2.0
Folks! As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) 2.) Library requirement (1.5 concurrent package?) 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) 4.) Scope (all restricted as possible) 5.) What else? Cheers Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Brainstorming for 2.0
Oliver Zeigermann oliver.zeigermann at gmail.com writes: As explaining in my previous post, I have created a new TRANSACTION2 branch to contain initial code, docs, etc. for a future 2.0 version of Commons Transaction. If you have ideas, suggestions, etc. please follow up to this post until we find a more suitable place for such a discussion. Open Questions (my suggestions in brackets): 1.) Medium for discussion (Wiki? SVN?) Why not this list? Do you expect so much discussion? 2.) Library requirement (1.5 concurrent package?) +1 In general there shouldn't be too many dependencies. Maybe a newer JCA spec later on. 3.) Minimum JDK Requirement (always the latest, i.e. 1.6) Hmm, why require more than necessary? Java 5 brings the concurrent package, but Java 6? Higher requirements always limit the number of users. 4.) Scope (all restricted as possible) Scope of what? Access scope of interfaces, classes, methods? Normally I tend to limit it as less as possible to allow easy extending and sub classing. But if changes to the API are always related with such circumstances ... Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
