from:"Hiram Chirino"

Make the ZooKeeper optional bits seperate jars.
---

 Key: ZOOKEEPER-98
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-98
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Hiram Chirino


Optional bits like the ZooKeeper jmx module and the upcoming protocol and 
spring support stuff should get packaged as separate jars so that they don't 
keep bloating up the main ZooKeeper jar.

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

[jira] Issue Comment Edited: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616954#action_12616954
 ] 

chirino edited comment on ZOOKEEPER-82 at 7/25/08 10:13 AM:
--

Weird the patch did not change QuorumPeer at all.  QuorumPeer did not currently 
have a main method. Seem someone else moved it to ManagedQuorumPeer.  But in my 
next patch I'll move those java docs and update the scripts.

Yes main was moved from ZooKeeperServer to new class which my patch failed to 
include.  Sorry I'll to a attach a new patch asap. Will also add some doco for 
the getters/setters.

 

  was (Author: chirino):
Weird the patch did not change QuorumPeer at all.  QuorumPeer did not 
currently have a main method. Seem someone else moved it to ManagedQuorumPeer.  
But in my next patch I'll move those java docs and update the scripts.

Yes main was moved from ZooKeeperServer to new class which my patch failed to 
include.  Sorry I'll to a attach a new patch asap. Will also add some doco for 
the getters/setters.

BTW 

 
  
 Make the ZooKeeperServer more DI friendly
 -

 Key: ZOOKEEPER-82
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Attachments: ZOOKEEPER-82.patch


 Proposed changes were discussed in [this mailing list 
 thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL
  PROTECTED]:
 Basic goals are: 
 * Decouple the current configuration system from the public API.  I
 see stuff like ZooKeeperServer being coupled to ServerConfig a bit.
 * Allow the use of setter injection in addition to constructor
 injection. This is the most important thing needed to let spring more
 easily configure the objects.
 * Move the main() methods out of the ZooKeeperServer class.

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

[jira] Commented: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616954#action_12616954
 ] 

Hiram Chirino commented on ZOOKEEPER-82:


Weird the patch did not change QuorumPeer at all.  QuorumPeer did not currently 
have a main method. Seem someone else moved it to ManagedQuorumPeer.  But in my 
next patch I'll move those java docs and update the scripts.

Yes main was moved from ZooKeeperServer to new class which my patch failed to 
include.  Sorry I'll to a attach a new patch asap. Will also add some doco for 
the getters/setters.

BTW 

 

 Make the ZooKeeperServer more DI friendly
 -

 Key: ZOOKEEPER-82
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Attachments: ZOOKEEPER-82.patch


 Proposed changes were discussed in [this mailing list 
 thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL
  PROTECTED]:
 Basic goals are: 
 * Decouple the current configuration system from the public API.  I
 see stuff like ZooKeeperServer being coupled to ServerConfig a bit.
 * Allow the use of setter injection in addition to constructor
 injection. This is the most important thing needed to let spring more
 easily configure the objects.
 * Move the main() methods out of the ZooKeeperServer class.

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

[jira] Created: (ZOOKEEPER-100) Avoid extending Thread in the public ZooKeeper API

Avoid extending Thread in the public ZooKeeper API
--

 Key: ZOOKEEPER-100
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-100
 Project: Zookeeper
  Issue Type: Improvement
Reporter: Hiram Chirino


This was discussed in ZOOKEEPER-82
This would allow proper checked exceptions to get thrown when the objects are 
started/stopped.

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

[jira] Updated: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hiram Chirino updated ZOOKEEPER-82:
---

Status: Patch Available  (was: Open)

 Make the ZooKeeperServer more DI friendly
 -

 Key: ZOOKEEPER-82
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Attachments: ZOOKEEPER-82-b.patch


 Proposed changes were discussed in [this mailing list 
 thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL
  PROTECTED]:
 Basic goals are: 
 * Decouple the current configuration system from the public API.  I
 see stuff like ZooKeeperServer being coupled to ServerConfig a bit.
 * Allow the use of setter injection in addition to constructor
 injection. This is the most important thing needed to let spring more
 easily configure the objects.
 * Move the main() methods out of the ZooKeeperServer class.

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

[jira] Updated: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hiram Chirino updated ZOOKEEPER-82:
---

Attachment: (was: ZOOKEEPER-82-b.patch)

 Make the ZooKeeperServer more DI friendly
 -

 Key: ZOOKEEPER-82
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Attachments: ZOOKEEPER-82-b.patch


 Proposed changes were discussed in [this mailing list 
 thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL
  PROTECTED]:
 Basic goals are: 
 * Decouple the current configuration system from the public API.  I
 see stuff like ZooKeeperServer being coupled to ServerConfig a bit.
 * Allow the use of setter injection in addition to constructor
 injection. This is the most important thing needed to let spring more
 easily configure the objects.
 * Move the main() methods out of the ZooKeeperServer class.

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

[jira] Updated: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hiram Chirino updated ZOOKEEPER-82:
---

Attachment: ZOOKEEPER-82-b.patch

Attaching updated patch.

 Make the ZooKeeperServer more DI friendly
 -

 Key: ZOOKEEPER-82
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Attachments: ZOOKEEPER-82-b.patch


 Proposed changes were discussed in [this mailing list 
 thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL
  PROTECTED]:
 Basic goals are: 
 * Decouple the current configuration system from the public API.  I
 see stuff like ZooKeeperServer being coupled to ServerConfig a bit.
 * Allow the use of setter injection in addition to constructor
 injection. This is the most important thing needed to let spring more
 easily configure the objects.
 * Move the main() methods out of the ZooKeeperServer class.

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

Re: ZooKeeper community

2008-07-25 Thread Hiram Chirino

Have you guys setup a zookeeper-private list for the zookeeper ppmc +
hadoop pmc to have private discussions?
If not, I highly recommend it since it would be the only practical
viecel for the ppmc to nominate new commiters or raise sensitive
issues the the pmc.

Regards,
HIram

On Wed, Jul 23, 2008 at 4:30 PM, Hiram Chirino [EMAIL PROTECTED] wrote:
 Ok good...  as long as the PMC folks are participating it should not
 be a problem.

 Regards,
 Hiram

 On Wed, Jul 23, 2008 at 4:12 PM, Doug Cutting [EMAIL PROTECTED] wrote:
 Hiram Chirino wrote:

 looks like you guys are not in the PMC.  Sorry about that.  But it
 bring us a weird governance issue which is very anti Apahe..  usually
 an Apache project is self governed, but from the look of the
 authorization file, it seems like the zookeeper committers cannot
 properly self govern.  It makes things like doing releases, adding new
 committers and pmc members much more complex since the PMC members are
 not actively working on the project.

 PMC members (like me) are expected to monitor the project.  I don't moderate
 this list, but I'd be surprised if a few other PMC members are not also
 following it.  We hope to eventually promote some of Zookeeper's committers
 to the Hadoop PMC.  All seasoned committers should be on the PMC, but the
 Zookeeper folks are still relative newbies at Apache and none have made it
 there yet.

 To some degree the Hadoop PMC is incubating Zookeeper.  Zookeeper's
 committers are like the PPMC.  If things go well, as with all Hadoop
 committers, they'll be nominated to Hadoop's PMC.  There'll be no formal
 graduation, just gradual maturation.  If the community diverges sufficiently
 from Hadoop's, then it may someday make sense to promote Zookeeper to a TLP.

 Doug




 --
 Regards,
 Hiram

 Blog: http://hiramchirino.com

 Open Source SOA
 http://open.iona.com




-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

[jira] Commented: (ZOOKEEPER-103) Reorganize the ZooKeeper source distro to follow maven conventions


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617089#action_12617089
 ] 

Hiram Chirino commented on ZOOKEEPER-103:
-

Hi Patrick yes.  Lots projects just keep it flat like that.  Some project will 
group stuff in a directory if there is a specific grouping to the modules.  
Generally it's more specific than a general 'contrib' grouping though.

Also something to think about is the possibility of having independent release 
cycles for some of the modules.  At this stage of the I don't think we need to 
worry about that complexity.

Benjamin,

Generally the final binary distribution does make that distinction.  Some 
organize as:
/bin : start scripts
/lib : the main zoo keeper jar 
/lib/extras or /lib/contrib: optional libs that are not required to run ZK
/doc : 
/src

etc. etc.

 Reorganize the ZooKeeper source distro to follow maven conventions
 --

 Key: ZOOKEEPER-103
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-103
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Fix For: 3.0.0

 Attachments: ZOOKEEPER-103.patch, ZOOKEEPER-103.sh


 This was sugested as way to bridge the gap in ZOOKEEPER-83

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

[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616020#action_12616020
 ] 

Hiram Chirino commented on ZOOKEEPER-83:


James is right.

An ant build could easily co-exist with the maven one if folks feel that 
adverse to maven.

 Switch to using maven to build ZooKeeper
 

 Key: ZOOKEEPER-83
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Attachments: zookeeper-mavened.tgz


 Maven is a great too for building java projects at the ASF.  It helps 
 standardize the build a bit since it's a convention oriented.
 It's dependency auto downloading would remove the need to store the 
 dependencies in svn, and it will handle many of the suggested ASF policies 
 like gpg signing of the releases and such.
 The ZooKeeper build is almost vanilla except for the jute compiler bits.  
 Things that would need to change are:
  * re-organize the source tree a little so that it uses the maven directory 
 conventions
  * seperate the jute bits out into seperate modules so that a maven plugin 
 can be with it
  

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

[jira] Commented: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616025#action_12616025
 ] 

Hiram Chirino commented on ZOOKEEPER-82:


Anybody have a chance to review the patch?

 Make the ZooKeeperServer more DI friendly
 -

 Key: ZOOKEEPER-82
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Attachments: ZOOKEEPER-82.patch


 Proposed changes were discussed in [this mailing list 
 thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL
  PROTECTED]:
 Basic goals are: 
 * Decouple the current configuration system from the public API.  I
 see stuff like ZooKeeperServer being coupled to ServerConfig a bit.
 * Allow the use of setter injection in addition to constructor
 injection. This is the most important thing needed to let spring more
 easily configure the objects.
 * Move the main() methods out of the ZooKeeperServer class.

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

ZooKeeper community

2008-07-23 Thread Hiram Chirino

How big is the ZooKeeper developer community and what commercial
associations do they have?

-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper

[
https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616200#action_12616200
]

Hiram Chirino commented on ZOOKEEPER-83:

Hi folks..

To make the maven re-org super simple to apply I created a temp private branch
so that the changes can easily be merged into trunk.
This branch also has an updated ant build which works with the new maven
directory structure.

To merge the changes back into trunk, just run the follow in a clean trunk
checkout:

[code}
svn merge -r 679094:679134
https://svn.apache.org/repos/asf/activemq/sandbox/zookeeper
{code}

Switch to using maven to build ZooKeeper

Key: ZOOKEEPER-83
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83
Project: Zookeeper
Issue Type: Improvement
Components: build
Reporter: Hiram Chirino
Assignee: Hiram Chirino
Attachments: zookeeper-mavened.tgz

Maven is a great too for building java projects at the ASF. It helps
standardize the build a bit since it's a convention oriented.
It's dependency auto downloading would remove the need to store the
dependencies in svn, and it will handle many of the suggested ASF policies
like gpg signing of the releases and such.
The ZooKeeper build is almost vanilla except for the jute compiler bits.
Things that would need to change are:
* re-organize the source tree a little so that it uses the maven directory
conventions
* seperate the jute bits out into seperate modules so that a maven plugin
can be with it

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

[jira] Updated: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hiram Chirino updated ZOOKEEPER-83:
---

Assignee: (was: Hiram Chirino)
  Status: Patch Available  (was: Open)

 Switch to using maven to build ZooKeeper
 

 Key: ZOOKEEPER-83
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Hiram Chirino
 Attachments: zookeeper-mavened.tgz


 Maven is a great too for building java projects at the ASF.  It helps 
 standardize the build a bit since it's a convention oriented.
 It's dependency auto downloading would remove the need to store the 
 dependencies in svn, and it will handle many of the suggested ASF policies 
 like gpg signing of the releases and such.
 The ZooKeeper build is almost vanilla except for the jute compiler bits.  
 Things that would need to change are:
  * re-organize the source tree a little so that it uses the maven directory 
 conventions
  * seperate the jute bits out into seperate modules so that a maven plugin 
 can be with it
  

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

Re: ZooKeeper community

2008-07-23 Thread Hiram Chirino

So all the commiters are Yahoo folks?

On Wed, Jul 23, 2008 at 12:24 PM, Patrick Hunt [EMAIL PROTECTED] wrote:
 Good question, according to the PoweredBy wiki not too much ;-)
 http://wiki.apache.org/hadoop/ZooKeeper/PoweredBy
 (please update this if your company is using...)

 So far we have 5 committers (Ben, Andrew, Flavio, Mahadev and myself) and
 just a few contributors.

 There are a number of teams using ZK inside Yahoo, Veoh is using ZK (Ted
 Dunning gave a talk with Ben at the last Hadoop social), spinn3r, and it
 looks like IONA might have some interest. :-)
 http://hiramchirino.com/blog/index.html

 A number of people attending the last Hadoop social indicated that they are
 using or looking at ZK.

 Patrick

 Hiram Chirino wrote:

 How big is the ZooKeeper developer community and what commercial
 associations do they have?





-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

Re: Website

2008-07-23 Thread Hiram Chirino

Personally, I think forest is the right thing to do regarding product
documentation (manuals, api docs, user docs).  It very version
specific and needs to stay with the source code.

That said, project information is NOT product or version specific.
The general website could get generated from the WIKI.  And I think
it's a better medium to use since editing a wiki page is easier to do
than updating svn and then generating a site.

I too would be willing to help. And I think we can take it in stages.
We could easily migrate what you have today in MoinMoin to confluence.
 Then we could provide the value add of skining those wiki pages so
that have the same look and feel that the main site uses that way the
main site and wiki look more integrated.

Once that is setup, I'm sure you guys will be more comfortable with
the process and more information from the main site could get migrated
over to the wiki.


On Wed, Jul 23, 2008 at 2:15 PM, James Strachan
[EMAIL PROTECTED] wrote:
 2008/7/23 Doug Cutting [EMAIL PROTECTED]:
 James Strachan wrote:

 Tools like wikis are personal things; and folks tend to prefer to use
 the tool they know.

 That's a key point.

 To make a switch you'd need:
  1. Someone familiar with Confluence to lead the transition, convert the
 existing website and wiki content, set up static export etc.  Are you
 volunteering?

 I would yes, but only if 2) gets approval.

  2. Buy in from Zookeeper's primary contributors, who will end up writing
 and maintaining the documentation (Pat, Ben, etc.).  I don't really count,
 since I'm mostly a kibitzer here.

 Also, with Confluence export, how does one deal with versioning?  A
 convenience of keeping documentation in subversion is that it gets versioned
 with releases.  By maintaining the trunk documentation to match the trunk
 implementation, we automatically get documentation that matches each
 version, but we can still maintain the documentation in release branches.  I
 don't see how this would not add overhead with Confluence exports.  If
 Confluence always represented trunk, and we exported at release branch
 points, then it would be hard to patch branched documentation.  Maintaining
 multiple branches in Confluence would add management overhead, since these
 would need to be synchronized with subversion branching, tagging, etc.  How
 have other projects dealt with this issue?

 BTW MoinMoin has the same issue; when documentation is in the wiki you
 need to grab a snapshot of it to include in releases (or add it to
 svn) to support versioned documentation.

 What we've done in the past is copy the static HTML from the wiki with
 releases; or in some projects we turn the HTML from Confluence into a
 proper manual in PDF or HTML format. e.g.

 if you download 1.4.0 of Camel..
 http://activemq.apache.org/camel/camel-140-release.html

 and look in the docs directory; you'll see a manual in PDF and HTML
 format. Thats generated from the wiki whenever there is a release from
 these pages
 http://activemq.apache.org/camel/book.html
 which include various wiki pages together to form a user manual.

 which are then included together in this page
 http://activemq.apache.org/camel/book-in-one-page.html


 Maybe moving away from Forrest is a step too far right now; but its
 certainly worth thinking whether for the wiki content its gonna be
 MoinMoin or Confluence. Only if you choose Confluence then you can
 consider generating a user manual or the static website from it
 (neither AFAIK are possible with MoinMoin).


 Incidentally a totally different thought; whats gonna be the split
 between whats the static website (e.g. Forrest) versus stuff thats in
 the wiki versus documentation that goes inside each release? Its often
 a kinda slippery slope figuring out which bit does what and its a PITA
 moving content into different formats to move between them; so while
 no tool is perfect, I kinda like that with confluence there's just one
 place to put docs and you can then slice and dice as you see fit (and
 make multiple spaces if you want  share content across spaces) to
 deal with different version issues etc.

 --
 James
 ---
 http://macstrac.blogspot.com/

 Open Source Integration
 http://open.iona.com




-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper

[
https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615619#action_12615619
]

Hiram Chirino commented on ZOOKEEPER-83:

Besides the re-organization of the directory structures, I added a couple
Mojo.java files for to create the maven plugins for the source code generation
bits. And I modified the jute and version gen stuff so that you can specify an
output directory.

Also several files got deleted like all the jar files in the lib dir, and the
checked in javacc generated files since maven is now running javacc to generate
them from the .jj file.

Switch to using maven to build ZooKeeper

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

[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615620#action_12615620
 ] 

Hiram Chirino commented on ZOOKEEPER-83:


James, I think you missed it but, the build dues include a module to create a 
uber-jar, look at the zookeeper-all module.  This creates a jar with all the 
runtime dependencies needed to run a zookeeper server (yes this includes log4j).


 Switch to using maven to build ZooKeeper
 

 Key: ZOOKEEPER-83
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Attachments: zookeeper-mavened.tgz


 Maven is a great too for building java projects at the ASF.  It helps 
 standardize the build a bit since it's a convention oriented.
 It's dependency auto downloading would remove the need to store the 
 dependencies in svn, and it will handle many of the suggested ASF policies 
 like gpg signing of the releases and such.
 The ZooKeeper build is almost vanilla except for the jute compiler bits.  
 Things that would need to change are:
  * re-organize the source tree a little so that it uses the maven directory 
 conventions
  * seperate the jute bits out into seperate modules so that a maven plugin 
 can be with it
  

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

[jira] Commented: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615623#action_12615623
 ] 

Hiram Chirino commented on ZOOKEEPER-81:


Java 1.5 can compile this for sure with the given patch. 

 JMX module is using 1 java 6 method that has a java 5 equivalent
 

 Key: ZOOKEEPER-81
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-81
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Andrew Kornev
 Attachments: ZOOKEEPER-81.patch


 It would be nice if the jmx module compiled and ran on java 5 too.

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

Website

2008-07-22 Thread Hiram Chirino

Is the ZooKeeper website getting moved over to Apache?  I think a good
website is critical for building a community around the project.

Do you guys want to generate it from wiki content?  For example, the
http://activemq.apache.org/ site is generated from the wiki content at
http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index

If so I think I can create the confluence space for you guys so that
we can get started with that.

-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615628#action_12615628
 ] 

Hiram Chirino commented on ZOOKEEPER-78:


If possible, it might be nice if the WriteLock implemented the 
[Lock|http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html]
 interface.

 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
Assignee: james strachan
 Attachments: writeLock_protocol_version3.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.

Re: Website

2008-07-22 Thread Hiram Chirino

On Tue, Jul 22, 2008 at 1:24 PM, Patrick Hunt [EMAIL PROTECTED] wrote:
 Hi Hiram, see ZOOKEEPER-70  72. We'll be following Hadoop core/hbase wrt
 the docs/site/wiki. Specifically using Apache Forrest for the documentation,
 which also generates the site. We're in the process of moving the
 sourceforge wiki content over from SF to apache.

 I'm been working with a couple of the hadoop core team members getting their
 input re the site, I had actually planned to push something live today.

 Additional complexity is due to the fact that on SF we had all docs on the
 wiki and were not including the api docs in the release. Apache requires us
 to version our documentation proper along with the code (so has to be in SVN
 and not on the wiki) and we also have to include the api docs (as well as
 regular docs) along with each release which we are not doing on SF.

Yep.  BTW you can still take a hybrid approach where the general site
information (stuff like how to contirbute, mailing lists, news, etc.
etc.) is wiki driven which then links to release documentation
directories which are generated from svn sources during a release.
But either way is good.  Good to know the site is coming soon!


 Patrick

 Hiram Chirino wrote:

 Is the ZooKeeper website getting moved over to Apache?  I think a good
 website is critical for building a community around the project.

 Do you guys want to generate it from wiki content?  For example, the
 http://activemq.apache.org/ site is generated from the wiki content at
 http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index

 If so I think I can create the confluence space for you guys so that
 we can get started with that.





-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

[jira] Commented: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615711#action_12615711
 ] 

Hiram Chirino commented on ZOOKEEPER-81:


lol.. I don't understand the aversion to the patch. it changes NOTHING 
significant and lets the module compile under java 1.5

have you seen that it just changes ONE line? it changes s.isEmpty() to 
s.length()==0

please commit.

 JMX module is using 1 java 6 method that has a java 5 equivalent
 

 Key: ZOOKEEPER-81
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-81
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Andrew Kornev
 Attachments: ZOOKEEPER-81.patch


 It would be nice if the jmx module compiled and ran on java 5 too.

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

[jira] Commented: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615719#action_12615719
 ] 

Hiram Chirino commented on ZOOKEEPER-81:


Furthermore, I've been looking at your the MXBean interfaces and I don't see 
them being actual MXBeans.. they are just standard MBeans.  They would only be 
MXBeans if the methods they defined used complex object types as parameters or 
return values.

Are you sure that you even have a Java 6 runtime dependency?  

 JMX module is using 1 java 6 method that has a java 5 equivalent
 

 Key: ZOOKEEPER-81
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-81
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Andrew Kornev
 Attachments: ZOOKEEPER-81.patch


 It would be nice if the jmx module compiled and ran on java 5 too.

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

[jira] Commented: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615749#action_12615749
 ] 

Hiram Chirino commented on ZOOKEEPER-81:


Sure.. could we get this patch committed first?  I really do fail to see what 
harm could come from it being committed. 

 JMX module is using 1 java 6 method that has a java 5 equivalent
 

 Key: ZOOKEEPER-81
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-81
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
Assignee: Andrew Kornev
 Attachments: ZOOKEEPER-81.patch


 It would be nice if the jmx module compiled and ran on java 5 too.

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

[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper

[
https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615764#action_12615764
]

Hiram Chirino commented on ZOOKEEPER-83:

Flavio,

maven provides a much more standardize build process than ant. Any maven java
project has the same directory structure and build/release procedure.
Therefore new contributors who are familiar with maven will be more comfortable
contributing to ZooKeeper because of it.

It handles lots of the wonky ASF relase rules like:
* GPG sighing
* staging release artifacts to get voted on.
* building binary distros with api docs
* building source distros
* including and verifying LICENSE and NOTICE files are in all jars
* It can run the rat tool for you to verify that all source files have the
right headers on them

It encourages folks to use your project
* It deploys your jar artifacts to a centralized maven repository where other
projects can automatically pull your libs into their builds.
* the maven repo is a sort of eco system, where if your artifacts are available
in it, folks are more willing to use your stuff, and they in turn pubish
artifacts the depend on ZooKeeper which in turn might get used by someone else
who transitively gets ZooKeeper
* It encourages good release patterns like including the version number in the
jar. Nice to have so that when folks use your jars it is obvious what version
they are using.

It encourages good modularization/decoupling:
* It's easy to add additional jars to the project and then add dependencies
between them. This encourage folks to decouple their code properly.
* Once you have a nicely modular project, it easy for folks to add additional
optional modules for new features. For example I could see folks wanting a
zookeeper-spring module.

Plus it does lots of useful things like:
* generate IDE project files so that they don't need to be manually maintained.
* it can enforce checkstyle rules if desired
* Runs findbugs and cobertura
* It can creates great set of cross indexed html docs about the build
including

Plus since it's declarative in a nature, folks can use other maven plugins
against the build (without changing the build files) to access additional
interesting features.

Maven in general is more higher level concept than ANT. It brings power and
flexibility to the table. Plus it's the direction most new java projects are
taking these days.

So I think the question really is why keep ANT?

Switch to using maven to build ZooKeeper

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

Re: Website

2008-07-22 Thread Hiram Chirino

On Tue, Jul 22, 2008 at 2:54 PM, Patrick Hunt [EMAIL PROTECTED] wrote:
 I cloned core/hbase subprojects, so we do what's currently done by other
 hadoop subs. The issue has come up in the past, might be a good idea at some
 point but might also add even more complexity to already pretty complex
 process (see howtorelease page). I think we should get things setup similar
 to existing subs (still alot of work to be done converting the wiki over to
 apache wiki/docs) and review at some point in the future.

 Howtocontrib/howtorelease/faq is already on the wiki:
 http://wiki.apache.org/hadoop/ZooKeeper

 mailinglists/news/etc... are part of the docs (not wiki), probably more
 convention than anything. mailinglist never changes and I believe news (and
 prolly some others) is part of docs in order to be versioned, but also to
 enable users who have checked out the code to have direct access .


That's cool too.. If you are going to use a Wiki it might be better to
use the confluence one just cause it can easily be skinned to have the
main site's look and feel.  Plus it has a bunch of cool macros
available to import code examples from svn or bring in a table of
issues from JIRA (for example
http://openejb.apache.org/ejb-3-roadmap.html ) etc.

Regards,
Hiram

 Patrick

 Hiram Chirino wrote:

 On Tue, Jul 22, 2008 at 1:24 PM, Patrick Hunt [EMAIL PROTECTED] wrote:

 Hi Hiram, see ZOOKEEPER-70  72. We'll be following Hadoop core/hbase wrt
 the docs/site/wiki. Specifically using Apache Forrest for the
 documentation,
 which also generates the site. We're in the process of moving the
 sourceforge wiki content over from SF to apache.

 I'm been working with a couple of the hadoop core team members getting
 their
 input re the site, I had actually planned to push something live today.

 Additional complexity is due to the fact that on SF we had all docs on
 the
 wiki and were not including the api docs in the release. Apache requires
 us
 to version our documentation proper along with the code (so has to be in
 SVN
 and not on the wiki) and we also have to include the api docs (as well as
 regular docs) along with each release which we are not doing on SF.

 Yep.  BTW you can still take a hybrid approach where the general site
 information (stuff like how to contirbute, mailing lists, news, etc.
 etc.) is wiki driven which then links to release documentation
 directories which are generated from svn sources during a release.
 But either way is good.  Good to know the site is coming soon!

 Patrick

 Hiram Chirino wrote:

 Is the ZooKeeper website getting moved over to Apache?  I think a good
 website is critical for building a community around the project.

 Do you guys want to generate it from wiki content?  For example, the
 http://activemq.apache.org/ site is generated from the wiki content at
 http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index

 If so I think I can create the confluence space for you guys so that
 we can get started with that.








-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

Re: Website

2008-07-22 Thread Hiram Chirino

Lol.. Apache infrastructure supports multiple wiki backends.  It's up
to the project to pick which one you want to you.  You currently have
picked MoinMoin, but you could have easily picked Confluence, just
like these other Apache projects did:

http://cwiki.apache.org/confluence/dashboard.action

Regards,
Hiram

On Tue, Jul 22, 2008 at 4:25 PM, Patrick Hunt [EMAIL PROTECTED] wrote:
 The Hadoop project, including ZooKeeper, is currently using the Apache wiki.
 There are no plans at this time to use confluence:

 http://wiki.apache.org/hadoop/ZooKeeper

 Patrick


 Hiram Chirino wrote:

 On Tue, Jul 22, 2008 at 2:54 PM, Patrick Hunt [EMAIL PROTECTED] wrote:

 I cloned core/hbase subprojects, so we do what's currently done by other
 hadoop subs. The issue has come up in the past, might be a good idea at
 some
 point but might also add even more complexity to already pretty complex
 process (see howtorelease page). I think we should get things setup
 similar
 to existing subs (still alot of work to be done converting the wiki over
 to
 apache wiki/docs) and review at some point in the future.

 Howtocontrib/howtorelease/faq is already on the wiki:
 http://wiki.apache.org/hadoop/ZooKeeper

 mailinglists/news/etc... are part of the docs (not wiki), probably more
 convention than anything. mailinglist never changes and I believe news
 (and
 prolly some others) is part of docs in order to be versioned, but also to
 enable users who have checked out the code to have direct access .


 That's cool too.. If you are going to use a Wiki it might be better to
 use the confluence one just cause it can easily be skinned to have the
 main site's look and feel.  Plus it has a bunch of cool macros
 available to import code examples from svn or bring in a table of
 issues from JIRA (for example
 http://openejb.apache.org/ejb-3-roadmap.html ) etc.

 Regards,
 Hiram

 Patrick

 Hiram Chirino wrote:

 On Tue, Jul 22, 2008 at 1:24 PM, Patrick Hunt [EMAIL PROTECTED] wrote:

 Hi Hiram, see ZOOKEEPER-70  72. We'll be following Hadoop core/hbase
 wrt
 the docs/site/wiki. Specifically using Apache Forrest for the
 documentation,
 which also generates the site. We're in the process of moving the
 sourceforge wiki content over from SF to apache.

 I'm been working with a couple of the hadoop core team members getting
 their
 input re the site, I had actually planned to push something live today.

 Additional complexity is due to the fact that on SF we had all docs on
 the
 wiki and were not including the api docs in the release. Apache
 requires
 us
 to version our documentation proper along with the code (so has to be
 in
 SVN
 and not on the wiki) and we also have to include the api docs (as well
 as
 regular docs) along with each release which we are not doing on SF.

 Yep.  BTW you can still take a hybrid approach where the general site
 information (stuff like how to contirbute, mailing lists, news, etc.
 etc.) is wiki driven which then links to release documentation
 directories which are generated from svn sources during a release.
 But either way is good.  Good to know the site is coming soon!

 Patrick

 Hiram Chirino wrote:

 Is the ZooKeeper website getting moved over to Apache?  I think a good
 website is critical for building a community around the project.

 Do you guys want to generate it from wiki content?  For example, the
 http://activemq.apache.org/ site is generated from the wiki content at
 http://cwiki.apache.org/confluence/display/ACTIVEMQ/Index

 If so I think I can create the confluence space for you guys so that
 we can get started with that.










-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

Re: An interest in increasing the DI'ness of ZooKeeper?

2008-07-21 Thread Hiram Chirino

Will Do.

On Fri, Jul 18, 2008 at 1:40 PM, Benjamin Reed [EMAIL PROTECTED] wrote:
 This sounds great. I would suggest opening a Jira to work out the
 proposal and track the patch.

 ben

 Hiram Chirino wrote:
 Yep, I've looked that the test cases. In short to make that public API
 more DI friendly, we should:

 * Decouple the current configuration system from the public API.  I
 see stuff like ZooKeeperServer being coupled to ServerConfig a bit.
 * Allow the use of setter injection in addition to constructor
 injection. This is the most important thing needed to let spring more
 easily configure the objects.

 Regards,
 Hiram


 On Fri, Jul 18, 2008 at 12:53 PM, Mahadev Konar [EMAIL PROTECTED] wrote:

 Hi Hiram,

  Thanks for your feedback. Its great to hear from our users.

 About your question regarding injecting zookeeper servers in
 applications, we do have public api' that support creating zookeeper
 servers in an embedding application. Take a look at our test cases where
 we create zookeeper servers via the public api. Is this what you were
 looking for or I misunderstood the reference?

 Mahadev


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram
 Chirino
 Sent: Friday, July 18, 2008 9:07 AM
 To: zookeeper-dev@hadoop.apache.org
 Subject: An interest in increasing the DI'ness of ZooKeeper?

 Hi Guys,

 First off, great project!  I think ZooKeeper is a fabulous idea.  I
 can see folks wanting to embedd ZK servers in their products too.  I
 could see the ActiveMQ project embedding it for several reasons.  And
 with that in mind,  I think it would be awesome of ZK tried to use
 more dependency injection (DI) to configure it's objects.  That way
 and embedding project could directly configure it with java code, or
 use Spring or Guice etc. etc.

 If you guys are interested in supporting this use case, I'd be happy
 to start contributing patches to make that happen.

 --
 Regards,
 Hiram

 Blog: http://hiramchirino.com

 Open Source SOA
 http://open.iona.com










-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

[jira] Commented: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615370#action_12615370
 ] 

Hiram Chirino commented on ZOOKEEPER-81:


The build lets me build under 1.5 and if I apply that patch it compiles and 
tests fine.  Perhaps that mxbean feature is only needed at runtime?

 JMX module is using 1 java 6 method that has a java 5 equivalent
 

 Key: ZOOKEEPER-81
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-81
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
 Attachments: ZOOKEEPER-81.patch


 It would be nice if the jmx module compiled and ran on java 5 too.

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

[jira] Created: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly

Make the ZooKeeperServer more DI friendly
-

 Key: ZOOKEEPER-82
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino


Proposed changes were discussed in [this mailing list 
thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL
 PROTECTED]:

Basic goals are: 
* Decouple the current configuration system from the public API.  I
see stuff like ZooKeeperServer being coupled to ServerConfig a bit.
* Allow the use of setter injection in addition to constructor
injection. This is the most important thing needed to let spring more
easily configure the objects.
* Move the main() methods out of the ZooKeeperServer class.




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

[jira] Updated: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hiram Chirino updated ZOOKEEPER-82:
---

Attachment: ZOOKEEPER-82.patch

Attaching patch that implements most of what was proposed.

 Make the ZooKeeperServer more DI friendly
 -

 Key: ZOOKEEPER-82
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82
 Project: Zookeeper
  Issue Type: Improvement
  Components: server
Reporter: Hiram Chirino
 Attachments: ZOOKEEPER-82.patch


 Proposed changes were discussed in [this mailing list 
 thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL
  PROTECTED]:
 Basic goals are: 
 * Decouple the current configuration system from the public API.  I
 see stuff like ZooKeeperServer being coupled to ServerConfig a bit.
 * Allow the use of setter injection in addition to constructor
 injection. This is the most important thing needed to let spring more
 easily configure the objects.
 * Move the main() methods out of the ZooKeeperServer class.

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

[jira] Created: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper

Switch to using maven to build ZooKeeper


 Key: ZOOKEEPER-83
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: Hiram Chirino
Assignee: Hiram Chirino
 Attachments: zookeeper-mavened.tgz

Maven is a great too for building java projects at the ASF.  It helps 
standardize the build a bit since it's a convention oriented.
It's dependency auto downloading would remove the need to store the 
dependencies in svn, and it will handle many of the suggested ASF policies like 
gpg signing of the releases and such.

The ZooKeeper build is almost vanilla except for the jute compiler bits.  
Things that would need to change are:
 * re-organize the source tree a little so that it uses the maven directory 
conventions
 * seperate the jute bits out into seperate modules so that a maven plugin can 
be with it
 


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

[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper