james strachan commented on ZOOKEEPER-78:

h3. Moving patches for this issue to subversion for easier tracking


I've already submitted about five patches for this issue so far and I'm sure 
there's gonna be loads more coming. Developing higher level protocols is a much 
bigger job than I previously thought ;-) particularly with having tests for all 
the various failure scenarios and adding support for the various other higher 
level protocols.

Its kinda time consuming creating loads of patches & attaching them to the same 
issue and deleting the old ones so its easy for commmitters to review - but 
more importantly, all the history of the many patches gets totally lost using 
the attach-patch-to-jira model - which also makes it harder for committers to 
watch progress on this issue.

I've never done this before on any other Apache project - and this approach is 
*temporary* and only reserved for the single ZOOKEEPER-78 issue; but I've 
checked in this patch into an svn sandbox area at Apache that I have commit 
karma on and will continue to work on it there; so that all the history is 
preserved. I can then do many more frequent & smaller commits; any ZK committer 
can review and easily apply my patches whenever they feel like - and its gonna 
be much easier for anyone in the ZK community to track progress on this issue 
and see how the implementation has changed over time as some things work or I 
find better ways of solving the issue.

This approach is totally temporary; its not an attempt to move the code outside 
of the ZK community or anything like that. At any point feel free to commit 
(actually just copy in svn which will keep all the history & commit comments 
etc) to the ZK trunk. You could even mirror the code to the ZK tree in 
sandbox/contrib area if you like - just like Hiram did to mirror the ZK code to 
the maven-patch example in the activemq sandbox.

I'm hoping in a few weeks my hacking on this issue will near completion and we 
can permanently move the code back into the ZK tree; but in the meantime its 
trivial to reuse it where it is or mirror it into the ZK tree as folks in the 
ZK community see fit. Also if I ever earn committer karma on ZK I can just move 
it into some ZK contrib area myself :)

h3. Building the code

In terms of sandbox - I ended up reusing Hiram's sandbox area that shows the 
maven build working on ZK; as I prefer to use maven and it was then super easy 
for me to create a new maven module, zookeeper-protocols that just includes the 
source and test cases for the high level protocols.

If you're new to maven and want to build it, I've checked in instructions 

Whenever we move this code back into the ZK trunk am sure we can hack an Ant 
build for it.

> added a high level protocol/feature - for easy Leader Election or exclusive 
> Write Lock creation
> -----------------------------------------------------------------------------------------------
>                 Key: ZOOKEEPER-78
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78
>             Project: Zookeeper
>          Issue Type: New Feature
>          Components: java client
>    Affects Versions: 3.0.0
>            Reporter: james strachan
>         Attachments: patch_with_including_Benjamin's_fix.patch, 
> using_zookeeper_facade.patch
> Here's a patch which adds a little WriteLock helper class for performing 
> leader elections or creating exclusive locks in some directory znode. Note 
> its an early cut; am sure we can improve it over time. The aim is to avoid 
> folks having to use the low level ZK stuff but provide a simpler high level 
> abstraction.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to