[jira] Commented: (ZOOKEEPER-99) All MXBeans interfaces that don't use complex paramters need to be renamed as MBean interaces.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781376#action_12781376 ] Hiram Chirino commented on ZOOKEEPER-99: Hi Patrick, if it runs fine on java 1.5, then it should run fine in JBoss. > All MXBeans interfaces that don't use complex paramters need to be renamed as > MBean interaces. > --- > > Key: ZOOKEEPER-99 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-99 > Project: Zookeeper > Issue Type: Bug > Components: jmx >Reporter: Hiram Chirino > Attachments: ZOOKEEPER-99.patch > > > All the MXBean interfaces that I've looked at are standard MBean interfaces. > The interface names should get renamed to MBean instaead of MXBean. That way > the server can also run on a the Java 1.5 Platform. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-532) java compiler should be target Java 1.5
[ https://issues.apache.org/jira/browse/ZOOKEEPER-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767941#action_12767941 ] Hiram Chirino commented on ZOOKEEPER-532: - Naturally all the features are not going to work on 1.5, for example JMX. So tests will fail. I'm not sure why you expected otherwise. But the fact remains the the core server and client work just fine on 1.5. I've been running them on 1.5 for a long time now. If you want folks to rebuild your jars, you basically saying you want forks of the project floating around out there. If that's the official position that's cool, but it just adds more work onto your downstream users since they now need to re-compile and redistribute. > java compiler should be target Java 1.5 > --- > > Key: ZOOKEEPER-532 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-532 > Project: Zookeeper > Issue Type: Bug > Affects Versions: 3.2.1 >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-532.patch > > > The jars released in 3.2.1 will not run on Java 1.5. With a small build > change, it is possible to generate jars that will run on Java 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-224) Deploy ZooKeeper jars/artifacts to a Maven Repository
[ https://issues.apache.org/jira/browse/ZOOKEEPER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767937#action_12767937 ] Hiram Chirino commented on ZOOKEEPER-224: - If you need to GPG sign the artifacts the by hand you can script it with something like this: echo "$PASSWORD" | gpg --default-key "$DEFAULT_KEY" --detach-sign --armor --no-tty --yes --passphrase-fd 0 "$FILE" > Deploy ZooKeeper jars/artifacts to a Maven Repository > - > > Key: ZOOKEEPER-224 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-224 > Project: Zookeeper > Issue Type: Task > Components: build > Affects Versions: 3.0.0 >Reporter: Hiram Chirino >Assignee: Benjamin Reed >Priority: Critical > Fix For: 3.3.0 > > > I've created the maven poms needed for the 3.0.0 release. > The directory structure and artifacts located at: > http://people.apache.org/~chirino/zk-repo/ > aka > people.apache.org:/x1/users/chirino/public_html/zk-repo > Just need sto get GPG signed by the project KEY and deployed to: > people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository > Who's the current ZooKeeper release manager? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-537) The zookeeper jar includes the java source files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767931#action_12767931 ] Hiram Chirino commented on ZOOKEEPER-537: - I think the reported issue is invalid. There are many cases where maven jars contain source code. For example all GWT builds include the source in jars. There has never been a report of this problem. I would close this issue out until the reporter can demonstrate the problem with a test case. > The zookeeper jar includes the java source files > > > Key: ZOOKEEPER-537 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-537 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.2.1 >Reporter: Thomas Dudziak > Fix For: 3.3.0 > > > This is a problem if you use zookeeper as a dependency in maven because for > whatever reason the maven compiler plugin will pick up the java files in the > jar and compile them to the output directory. From there they will land in > the generated jar file for whatever project happens to depend on zookeeper > thus introducing duplicate classes (once in zookeeper.jar, once in the > project's artifact). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Releases missing source tar balls?
Hi It looks like the zookeeper releases as missing the source tar balls which are used to create the binary releases. Remember that the Apache policy is to release source distributions. The binary distos are only there as a convenience to our users. -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://fusesource.com/
Re: [jira] Commented: (ZOOKEEPER-532) java compiler should be target Java 1.5
Not much. See: http://java.sun.com/javase/6/webnotes/compatibility.html Class file version bump seems mostly related to a new verification scheme. On Tue, Sep 22, 2009 at 4:58 PM, Patrick Hunt (JIRA) wrote: > >[ > https://issues.apache.org/jira/browse/ZOOKEEPER-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758433#action_12758433] > > Patrick Hunt commented on ZOOKEEPER-532: > > > FYI we dropped official 1.5 support in 3.1 with ZOOKEEPER-210 > > Also, IIRC there were issues running the ZK JMX code with a 1.5 vm. > > I'm not adverse to targeting 1.5, but what's the impact of this change for > everyone using java 6? (I realize it works, but what's the impact of > targeting 1.5 vs 1.6 on 1.6). > > > > java compiler should be target Java 1.5 > > --- > > > > Key: ZOOKEEPER-532 > > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-532 > > Project: Zookeeper > > Issue Type: Bug > >Affects Versions: 3.2.1 > >Reporter: Hiram Chirino > > Fix For: 3.3.0 > > > > Attachments: ZOOKEEPER-532.patch > > > > > > The jars released in 3.2.1 will not run on Java 1.5. With a small build > change, it is possible to generate jars that will run on Java 1.5. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://fusesource.com/
[jira] Updated: (ZOOKEEPER-532) java compiler should be target Java 1.5
[ https://issues.apache.org/jira/browse/ZOOKEEPER-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-532: Status: Patch Available (was: Open) > java compiler should be target Java 1.5 > --- > > Key: ZOOKEEPER-532 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-532 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.2.1 > Reporter: Hiram Chirino > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-532.patch > > > The jars released in 3.2.1 will not run on Java 1.5. With a small build > change, it is possible to generate jars that will run on Java 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-532) java compiler should be target Java 1.5
java compiler should be target Java 1.5 --- Key: ZOOKEEPER-532 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-532 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Hiram Chirino Fix For: 3.3.0 The jars released in 3.2.1 will not run on Java 1.5. With a small build change, it is possible to generate jars that will run on Java 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-532) java compiler should be target Java 1.5
[ https://issues.apache.org/jira/browse/ZOOKEEPER-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-532: Attachment: ZOOKEEPER-532.patch Attaching patch which updates the build so that javac targets 1.5. > java compiler should be target Java 1.5 > --- > > Key: ZOOKEEPER-532 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-532 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.2.1 > Reporter: Hiram Chirino > Fix For: 3.3.0 > > Attachments: ZOOKEEPER-532.patch > > > The jars released in 3.2.1 will not run on Java 1.5. With a small build > change, it is possible to generate jars that will run on Java 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Maven deployment
FYI: I've deployed your 3.2.1 release to my maven repo. It would be ideal if you guys could GPG sign these guys and then push them out to maven central. http://people.apache.org/~chirino/zk-repo/org/apache/hadoop/zookeeper/zookeeper/3.2.1/ Regards, Hiram -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://fusesource.com/
Re: Maven artifacts for 3.0.0 release
sry.. must be my eyes getting weak :) So he just want's folks to review the poms? On Fri, Dec 5, 2008 at 12:39 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > I'm missing the reference to double trouble, where does he say that? > > Hiram Chirino wrote: >> >> Double trouble? What's he mean by that? >> >> On Wed, Dec 3, 2008 at 6:04 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: >>> >>> Not sure if you noticed this discussion on hadoop core-dev: >>> http://www.nabble.com/Maven-vs-Ivy-td20786184.html >>> >>> In particular: >>> "it would help if someone wishing to use Maven had a look at >>> the poms and warned of trouble before they actually went up into the >>> central repository" >>> >>> As I mentioned previously we will most likely follow core's lead on this >>> (both in terms of build as well as release process). >>> >>> Regards, >>> >>> Patrick >>> >>> Hiram Chirino wrote: >>>> >>>> commented. Basically deploying the the maven repo is the same as >>>> deploying the final release artifact (it's just at a different >>>> directory on the same machine and has a different directory >>>> structure). >>>> >>>> On Wed, Nov 19, 2008 at 1:02 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: >>>>> >>>>> Hi Hiram, I updated 224 with a few questions, if you could provide some >>>>> insight that would be helpful. >>>>> >>>>> Patrick >>>>> >>>>> Hiram Chirino wrote: >>>>>> >>>>>> I created issue: https://issues.apache.org/jira/browse/ZOOKEEPER-224 >>>>>> to track the request. >>>>>> >>>>>> Who's the current ZooKeeper release manager? >>>>>> >>>>>> On Fri, Nov 14, 2008 at 11:07 AM, Hiram Chirino >>>>>> <[EMAIL PROTECTED]> >>>>>> wrote: >>>>>>> >>>>>>> Hi Guys, >>>>>>> >>>>>>> I've create a small maven 2 repository for the ZooKeeper 3.0.0 >>>>>>> release >>>>>>> at: >>>>>>> http://people.apache.org/~chirino/zk-repo/ >>>>>>> >>>>>>> Ideally the ZooKeeper PMC can review the artifacts validate that they >>>>>>> match the release, GPG sign all the poms and jars and push them out >>>>>>> to >>>>>>> the main apache m2 maven repository so it can get synchronized into >>>>>>> the maven central repo. That's at >>>>>>> >>>>>>> >>>>>>> people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository >>>>>>> BTW. >>>>>>> >>>>>>> But For now maven users of ZooKeeper can add the following to their >>>>>>> build to automatically download the release: >>>>>>> >>>>>>> >>>>>>> >>>>>>> chirino-zk-repo >>>>>>> Private ZooKeeper Repo >>>>>>> http://people.apache.org/~chirino/zk-repo/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> org.apache.hadoop.zookeeper >>>>>>> zookeeper >>>>>>> 3.0.0 >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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
Re: Maven artifacts for 3.0.0 release
Double trouble? What's he mean by that? On Wed, Dec 3, 2008 at 6:04 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > Not sure if you noticed this discussion on hadoop core-dev: > http://www.nabble.com/Maven-vs-Ivy-td20786184.html > > In particular: > "it would help if someone wishing to use Maven had a look at > the poms and warned of trouble before they actually went up into the > central repository" > > As I mentioned previously we will most likely follow core's lead on this > (both in terms of build as well as release process). > > Regards, > > Patrick > > Hiram Chirino wrote: >> >> commented. Basically deploying the the maven repo is the same as >> deploying the final release artifact (it's just at a different >> directory on the same machine and has a different directory >> structure). >> >> On Wed, Nov 19, 2008 at 1:02 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: >>> >>> Hi Hiram, I updated 224 with a few questions, if you could provide some >>> insight that would be helpful. >>> >>> Patrick >>> >>> Hiram Chirino wrote: >>>> >>>> I created issue: https://issues.apache.org/jira/browse/ZOOKEEPER-224 >>>> to track the request. >>>> >>>> Who's the current ZooKeeper release manager? >>>> >>>> On Fri, Nov 14, 2008 at 11:07 AM, Hiram Chirino <[EMAIL PROTECTED]> >>>> wrote: >>>>> >>>>> Hi Guys, >>>>> >>>>> I've create a small maven 2 repository for the ZooKeeper 3.0.0 release >>>>> at: >>>>> http://people.apache.org/~chirino/zk-repo/ >>>>> >>>>> Ideally the ZooKeeper PMC can review the artifacts validate that they >>>>> match the release, GPG sign all the poms and jars and push them out to >>>>> the main apache m2 maven repository so it can get synchronized into >>>>> the maven central repo. That's at >>>>> >>>>> people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository >>>>> BTW. >>>>> >>>>> But For now maven users of ZooKeeper can add the following to their >>>>> build to automatically download the release: >>>>> >>>>> >>>>> >>>>>chirino-zk-repo >>>>>Private ZooKeeper Repo >>>>>http://people.apache.org/~chirino/zk-repo/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>org.apache.hadoop.zookeeper >>>>>zookeeper >>>>>3.0.0 >>>>> >>>>> >>>>> >>>>> -- >>>>> 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-69) ZooKeeper logo
[ https://issues.apache.org/jira/browse/ZOOKEEPER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650576#action_12650576 ] Hiram Chirino commented on ZOOKEEPER-69: I think it's important that you get a vector format for whatever logo you accept as the official version. It comes in really handy when you want to print a large poster sized logo for a conference or something. > ZooKeeper logo > -- > > Key: ZOOKEEPER-69 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-69 > Project: Zookeeper > Issue Type: Wish > Components: documentation >Reporter: Flavio Paiva Junqueira >Assignee: Benjamin Reed >Priority: Minor > Fix For: 3.1.0 > > Attachments: pbzk.gif, zk_logo_use.png, zk_logo_use2.png, > zookeeper-sketch.jpg > > > I think we need a cool logo for the project. The ones I've seen so far are a > little lame, and that includes the one I've created for SourceForge. If > anyone on this list has an idea or knows of anyone with some art skills, > plese add a commento to this Jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ActiveMQ is now using ZooKeeper
done. On Mon, Nov 24, 2008 at 2:46 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > That's great, very cool! > > Can you create ZOOKEEPER JIRAs for these items that you've identified? First > look it seems like we should be able to include these in 3.1.0, perhaps even > 3.0.2. > > Regards, > > Patrick > > Hiram Chirino wrote: >> >> FYI: >> >> ActiveMQ has now started using ZooKeeper to do master election of it's >> HA clusters. So zookeeper is now going to get included in every new >> ActiveMQ distro we cut. Which in turn this should mean that it will >> get included in every ServiceMix and Geronimo distro since they >> repackage ActiveMQ. >> >> More details at: >> http://cwiki.apache.org/confluence/display/ACTIVEMQ/KahaDB+Master+Slave >> >> So this might start bringing more folks/requirements to your project. >> For example it would be nice if: >> - You had a slim client only jar which we package with ActiveMQ to >> reduce our footprint, since we only use the client aspect of ZooKeeper >> - Make the sever more embeddable (for example eliminate using static >> vars to initialize the sever) so that it can be wrapped up in an OSGi >> bundle and deployed in ServiceMix. >> > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
[jira] Created: (ZOOKEEPER-234) Eliminate using statics to initialize the sever. Should allow server to be more embeddable in OSGi enviorments.
Eliminate using statics to initialize the sever. Should allow server to be
more embeddable in OSGi enviorments.
Key: ZOOKEEPER-234
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-234
Project: Zookeeper
Issue Type: Improvement
Reporter: Hiram Chirino
Assignee: Patrick Hunt
Patrick request I open up this in issue in this [email
thread|http://n2.nabble.com/ActiveMQ-is-now-using-ZooKeeper-td1573272.html]
The main culprit I've noticed is:
{code}
ServerStats.registerAsConcrete();
{code}
But there may be others.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-233) Create a slimer jar for clients to reduce thier disk footprint.
Create a slimer jar for clients to reduce thier disk footprint. --- Key: ZOOKEEPER-233 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-233 Project: Zookeeper Issue Type: New Feature Reporter: Hiram Chirino Assignee: Patrick Hunt Priority: Trivial Patrick request I open up this in issue in this [email thread|http://n2.nabble.com/ActiveMQ-is-now-using-ZooKeeper-td1573272.html] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ActiveMQ is now using ZooKeeper
FYI: ActiveMQ has now started using ZooKeeper to do master election of it's HA clusters. So zookeeper is now going to get included in every new ActiveMQ distro we cut. Which in turn this should mean that it will get included in every ServiceMix and Geronimo distro since they repackage ActiveMQ. More details at: http://cwiki.apache.org/confluence/display/ACTIVEMQ/KahaDB+Master+Slave So this might start bringing more folks/requirements to your project. For example it would be nice if: - You had a slim client only jar which we package with ActiveMQ to reduce our footprint, since we only use the client aspect of ZooKeeper - Make the sever more embeddable (for example eliminate using static vars to initialize the sever) so that it can be wrapped up in an OSGi bundle and deployed in ServiceMix. -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
[jira] Commented: (ZOOKEEPER-224) Deploy ZooKeeper 3.0.0 to a Maven Repository
[
https://issues.apache.org/jira/browse/ZOOKEEPER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650272#action_12650272
]
Hiram Chirino commented on ZOOKEEPER-224:
-
Q: How are the .sha1 files generated? What's the command?
A:
{code}
prompt> openssl dgst -md5 < inputfile
prompt> openssl dgst -sha1 < inputfile
{code}
Q: I update maven-metadata.xml and regenerate the md5/sha1?
A: yes. maven-metadata.xml is mainly used by the plugin download system maven
has. it will consult this file to see what the latest version of the artifact
is. So while it's not critical that the metadata is maintained, it is done for
all maven deployed artifacts so ideally it should be done.
Q: And also create a new 3.0.1 subdir at the same level as the 3.0.0 subdir?
A: Yes
Q: Should I include 3.0.0 as well or just 3.0.1?
A: Yes please. That way all your releases are available via Maven.
> Deploy ZooKeeper 3.0.0 to a Maven Repository
>
>
> Key: ZOOKEEPER-224
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-224
> Project: Zookeeper
> Issue Type: Task
> Components: build
> Affects Versions: 3.0.0
>Reporter: Hiram Chirino
>Assignee: Patrick Hunt
>Priority: Critical
>
> I've created the maven poms needed for the 3.0.0 release.
> The directory structure and artifacts located at:
> http://people.apache.org/~chirino/zk-repo/
> aka
> people.apache.org:/x1/users/chirino/public_html/zk-repo
> Just need sto get GPG signed by the project KEY and deployed to:
> people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository
> Who's the current ZooKeeper release manager?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Maven artifacts for 3.0.0 release
commented. Basically deploying the the maven repo is the same as deploying the final release artifact (it's just at a different directory on the same machine and has a different directory structure). On Wed, Nov 19, 2008 at 1:02 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > Hi Hiram, I updated 224 with a few questions, if you could provide some > insight that would be helpful. > > Patrick > > Hiram Chirino wrote: >> >> I created issue: https://issues.apache.org/jira/browse/ZOOKEEPER-224 >> to track the request. >> >> Who's the current ZooKeeper release manager? >> >> On Fri, Nov 14, 2008 at 11:07 AM, Hiram Chirino <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi Guys, >>> >>> I've create a small maven 2 repository for the ZooKeeper 3.0.0 release >>> at: >>> http://people.apache.org/~chirino/zk-repo/ >>> >>> Ideally the ZooKeeper PMC can review the artifacts validate that they >>> match the release, GPG sign all the poms and jars and push them out to >>> the main apache m2 maven repository so it can get synchronized into >>> the maven central repo. That's at >>> people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository >>> BTW. >>> >>> But For now maven users of ZooKeeper can add the following to their >>> build to automatically download the release: >>> >>> >>> >>> chirino-zk-repo >>> Private ZooKeeper Repo >>> http://people.apache.org/~chirino/zk-repo/ >>> >>> >>> >>> >>> >>> org.apache.hadoop.zookeeper >>> zookeeper >>> 3.0.0 >>> >>> >>> >>> -- >>> 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-224) Deploy ZooKeeper 3.0.0 to a Maven Repository
[
https://issues.apache.org/jira/browse/ZOOKEEPER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649119#action_12649119
]
Hiram Chirino commented on ZOOKEEPER-224:
-
Hi Patrick,
1) Yeah.. same key used to sign the distro. Just so that folks who get the
artifacts from maven can verify that it's from a trusted source.
2) The /www/people.apache.org/repo/m2-ibiblio-rsync-repository directory is the
Apache Maven2 release repository. Only official releases should be pushed
there. Artifacts deployed here will get mirrored to the maven central
repository. You deploy to this the same way you deployed the release distro to
people.apache.org:/www/www.apache.org/dist/hadoop/zookeeper. I would just scp
to people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository
3) Yes. The entire directory structure and files contained within the
http://people.apache.org/~chirino/zk-repo/ directory need to be preserved. If
my directory had GPG signed all the artifacts (including poms), you would have
been able to ssh into the people.apache.org machine and run:
{code}
cp -r /x1/users/chirino/public_html/zk-repo/*
/www/people.apache.org/repo/m2-ibiblio-rsync-repository
{code}
4) Same implications that you have when your deploy your release distro to the
people.apache.org:/www/www.apache.org/dist/hadoop/zookeeper directory. As long
as the people.apache.org does not get hacked only Apache committers can deploy
a signed zk jar. Just like with release distros, the onus of verifying jar
signatures lies with the downstream user. You guys should document this well
on your website along with the KEYS file they should validate against. And
hope that the website hosting the KEYS file does not get hacked too :) (The
chain of trust and security is so fragile!)
> Deploy ZooKeeper 3.0.0 to a Maven Repository
>
>
> Key: ZOOKEEPER-224
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-224
> Project: Zookeeper
> Issue Type: Task
> Components: build
>Affects Versions: 3.0.0
>Reporter: Hiram Chirino
>Assignee: Patrick Hunt
>Priority: Critical
>
> I've created the maven poms needed for the 3.0.0 release.
> The directory structure and artifacts located at:
> http://people.apache.org/~chirino/zk-repo/
> aka
> people.apache.org:/x1/users/chirino/public_html/zk-repo
> Just need sto get GPG signed by the project KEY and deployed to:
> people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository
> Who's the current ZooKeeper release manager?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-224) Deploy ZooKeeper 3.0.0 to a Maven Repository
[ https://issues.apache.org/jira/browse/ZOOKEEPER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino reassigned ZOOKEEPER-224: --- Assignee: Patrick Hunt assigning to the guy that can do it :) > Deploy ZooKeeper 3.0.0 to a Maven Repository > > > Key: ZOOKEEPER-224 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-224 > Project: Zookeeper > Issue Type: Task > Components: build >Affects Versions: 3.0.0 > Reporter: Hiram Chirino >Assignee: Patrick Hunt >Priority: Critical > > I've created the maven poms needed for the 3.0.0 release. > The directory structure and artifacts located at: > http://people.apache.org/~chirino/zk-repo/ > aka > people.apache.org:/x1/users/chirino/public_html/zk-repo > Just need sto get GPG signed by the project KEY and deployed to: > people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository > Who's the current ZooKeeper release manager? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Maven artifacts for 3.0.0 release
I created issue: https://issues.apache.org/jira/browse/ZOOKEEPER-224 to track the request. Who's the current ZooKeeper release manager? On Fri, Nov 14, 2008 at 11:07 AM, Hiram Chirino <[EMAIL PROTECTED]> wrote: > Hi Guys, > > I've create a small maven 2 repository for the ZooKeeper 3.0.0 release at: > http://people.apache.org/~chirino/zk-repo/ > > Ideally the ZooKeeper PMC can review the artifacts validate that they > match the release, GPG sign all the poms and jars and push them out to > the main apache m2 maven repository so it can get synchronized into > the maven central repo. That's at > people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository > BTW. > > But For now maven users of ZooKeeper can add the following to their > build to automatically download the release: > > > > chirino-zk-repo > Private ZooKeeper Repo > http://people.apache.org/~chirino/zk-repo/ > > > > > > org.apache.hadoop.zookeeper > zookeeper > 3.0.0 > > > > -- > 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] Created: (ZOOKEEPER-224) Deploy ZooKeeper 3.0.0 to a Maven Repository
Deploy ZooKeeper 3.0.0 to a Maven Repository Key: ZOOKEEPER-224 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-224 Project: Zookeeper Issue Type: Task Components: build Affects Versions: 3.0.0 Reporter: Hiram Chirino Priority: Critical I've created the maven poms needed for the 3.0.0 release. The directory structure and artifacts located at: http://people.apache.org/~chirino/zk-repo/ aka people.apache.org:/x1/users/chirino/public_html/zk-repo Just need sto get GPG signed by the project KEY and deployed to: people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository Who's the current ZooKeeper release manager? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Maven artifacts for 3.0.0 release
Hi Guys, I've create a small maven 2 repository for the ZooKeeper 3.0.0 release at: http://people.apache.org/~chirino/zk-repo/ Ideally the ZooKeeper PMC can review the artifacts validate that they match the release, GPG sign all the poms and jars and push them out to the main apache m2 maven repository so it can get synchronized into the maven central repo. That's at people.apache.org:/www/people.apache.org/repo/m2-ibiblio-rsync-repository BTW. But For now maven users of ZooKeeper can add the following to their build to automatically download the release: chirino-zk-repo Private ZooKeeper Repo http://people.apache.org/~chirino/zk-repo/ org.apache.hadoop.zookeeper zookeeper 3.0.0 -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
[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, 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] 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-tabpanel&focusedCommentId=12620004#action_12620004 ] Hiram Chirino commented on ZOOKEEPER-103: - I think this patch is a nice middle ground. It's using only ANT, but adopting the maven directory conventions. So Pat's -1 does not really apply to this issue since ant is the only build system being used. Could the rest of the committers please post their thoughts on this? BTW once this is implemented, it should be easier to implement: ZOOKEEPER-95 and ZOOKEEPER-98 > 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] Updated: (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:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-103: Status: Patch Available (was: Open) > 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-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-tabpanel&focusedCommentId=12619871#action_12619871 ] Hiram Chirino commented on ZOOKEEPER-103: - On ZOOKEEPER-83 we plainly agreed that we were going to compromise and use maven conventions for the directory structure but only include a ant build. And yes.. it's suspicious because it IS using the maven conventions. There is no doubt about it. That was part of the compromise. > 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-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-tabpanel&focusedCommentId=12619658#action_12619658 ] Hiram Chirino commented on ZOOKEEPER-103: - The redundancy is a good convention since it makes it obvious which directory builds which jar file. And prefixing all the zookeeper jars with zookeeper- is a good convention too since it will help uniquely identify your jars in a project that uses multiple 3rd party jars. For example if ActiveMQ starts shipping some of the zookeeper bits in it's distribution. > 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-tabpanel&focusedCommentId=12619239#action_12619239 ] Hiram Chirino commented on ZOOKEEPER-83: I've created a maven plugin that can be used to verify integrity of downloaded dependencies. This should cross out the biggest concern that the hadoop folks had with maven. The plugin can be found here: https://svn.apache.org/repos/asf/servicemix/maven-plugins/checksum-maven-plugin/trunk > 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 > > 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 test harness needs work
I was dual core Intel Mac Book Pro. On Fri, Aug 1, 2008 at 4:57 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > Could be, but I don't think I'm seeing that in the test failure cases I've > seen lately. In some cases the VM itself was crashing! Notice ZOOKEEPER-2 > was seeing NPEs in the QuorumPeer. > > I did notice in AsyncTest that it's closing the server(s) before closing the > clients, which is causing alot of noise in the logs (planning to patch > that). > > What OS/cpu type configuration are you on? I'm on Ubuntu on 1core cpu. > > Patrick > > Hiram Chirino wrote: >> >> Lots of times when a test runs it seems like the ports are already >> bound. Anybody else see this? Is this the cause of the intermittent >> failures you see? >> >> Regards, >> Hiram >> >> On Wed, Jul 30, 2008 at 12:32 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: >>> >>> I'm soliciting ideas on how to improve the reliability and usability >>> (creating new tests in particular) of our current test harness. >>> >>> Hudson and some users are seeing intermittent failures, primarily due to >>> timing related issue in test setup; the test starts a server, runs some >>> tests, then shuts down the server, loop to the next test. There is some >>> code >>> in ClientBase that's supposed to provide a latch for the server startup, >>> but >>> we also have a number of "sleeps" in the test setup, without which the >>> tests >>> fail more frequently (so something is still busted). In particular I want >>> to >>> make it easier to write server tests and to remove the need for sleeps as >>> this causes the unit tests to run slowly. >>> >>> Additionally we are seeing a need to tests clients in addition to the >>> server >>> (much of our current testing is related to verifying the correct function >>> of >>> the zk server). In this case we are not currently able to test any client >>> failure handling cases (such as disconnect handling) as we are running >>> against a fully functional zk server. >>> >>> I'm thinking we should do two things: >>> >>> 1) create a better test harness for the server >>> 2) implement a mock ZooKeeper.java that has similar semantics as zk >>> server >>> proper but has the capability to inject/reproduce/verify various error >>> scenarios for client testing. >>> >>> If you have any ideas/suggestions/comments/etc.. or would like to work >>> on/with please let me know. >>> >>> Patrick >>> >> >> >> > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
Re: ZooKeeper test harness needs work
Lots of times when a test runs it seems like the ports are already bound. Anybody else see this? Is this the cause of the intermittent failures you see? Regards, Hiram On Wed, Jul 30, 2008 at 12:32 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > I'm soliciting ideas on how to improve the reliability and usability > (creating new tests in particular) of our current test harness. > > Hudson and some users are seeing intermittent failures, primarily due to > timing related issue in test setup; the test starts a server, runs some > tests, then shuts down the server, loop to the next test. There is some code > in ClientBase that's supposed to provide a latch for the server startup, but > we also have a number of "sleeps" in the test setup, without which the tests > fail more frequently (so something is still busted). In particular I want to > make it easier to write server tests and to remove the need for sleeps as > this causes the unit tests to run slowly. > > Additionally we are seeing a need to tests clients in addition to the server > (much of our current testing is related to verifying the correct function of > the zk server). In this case we are not currently able to test any client > failure handling cases (such as disconnect handling) as we are running > against a fully functional zk server. > > I'm thinking we should do two things: > > 1) create a better test harness for the server > 2) implement a mock ZooKeeper.java that has similar semantics as zk server > proper but has the capability to inject/reproduce/verify various error > scenarios for client testing. > > If you have any ideas/suggestions/comments/etc.. or would like to work > on/with please let me know. > > Patrick > -- 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-tabpanel&focusedCommentId=12619107#action_12619107 ] Hiram Chirino commented on ZOOKEEPER-103: - The maven convention is to have each module/jar the it's own directory who's name matches the module/jar name. The ant build does not do this (yet) but in the maven build, you end up with zookeeper-xxx.jar files. > 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-107) Allow dynamic changes to server cluster membership
[
https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619106#action_12619106
]
Hiram Chirino commented on ZOOKEEPER-107:
-
I personally think that this needs to stay decoupled so that group membership
can be controlled via different implementations. In other words, I think that
the QuorumPeer should not have to have any constructor args for it to know it's
peers. It should persistently store/remember what the list of peers are part
of the group since it last started.
Not sure if it makes sense to keep that list in the ZK db or not.
When a node that is not part of a cluster first starts up, it needs to know if
it's starting a new cluster or if it is joining an existing cluster.
Therefore, I think the QuorumPeer class needs methods like the following:
{code}
/**
* Contacts a ZK server in the cluster, adds this peer to the cluster and gets
a listing of the rest of the peers in
* the cluster.
*
* Optional: is slaveOnly is true, then this peer should never be elected
master.
*
* Throws an error if this peer is already part of a cluster.
*/
void joinCluster( URI server, bool slaveOnly )
/**
* Starts this peer as the first node in the cluster and makes him the master.
*
* Throws an error if this peer is already part of a cluster.
*/
void createCluster()
/**
* Removes this peer from the peer list maintained by the cluster.
*
* Throws an error if this peer is not part of a cluster.
*/
void leaveCluster()
/**
* Gets a list of peers in the cluser.
*
* @return null if not part of a cluster yet.
*/
List getClusterPeers()
{code}
If methods like the above are available, then an administrator can dynamically
manage adding/removing nodes on an existing ZooKeeper cluster. or some
automated agent could do it. Note that the peer list needs to get replicated
to all cluster members and persisted to avoid split brain issues on peer
restart. Operations like joinCluster(), leaveCluster(), getClusterPeers()
would block until a master is elected in the cluster.
Please note the 'nice to have feature' where you have the ability to designate
some peers as NOT being eligible to become a master. This would allow you to
support using heterogeneous peers, and enforce only allowing the higher end
machines to become the masters.
> Allow dynamic changes to server cluster membership
> --
>
> Key: ZOOKEEPER-107
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
> Project: Zookeeper
> Issue Type: Improvement
> Components: server
>Reporter: Patrick Hunt
>
> Currently cluster membership is statically defined, adding/removing hosts
> to/from the server cluster dynamically needs to be supported.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-80) Document process for client recipe contributions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617868#action_12617868 ] Hiram Chirino commented on ZOOKEEPER-80: Patrick, no.. as the recipes will be grouped by language. I only see a few top level dirs being created. > Document process for client recipe contributions > > > Key: ZOOKEEPER-80 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-80 > Project: Zookeeper > Issue Type: Task > Components: documentation >Reporter: Patrick Hunt >Assignee: Patrick Hunt > > Per Doug's suggestion I'll use a link instead of copy/paste: > http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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-tabpanel&focusedCommentId=12617859#action_12617859 ] Hiram Chirino commented on ZOOKEEPER-103: - Generally it's just a good sign showing that stuff is decoupled. we could group things into directories but that would just deepen the directory tree and not add tremendous amount of value. > 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-80) Document process for client recipe contributions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617827#action_12617827 ] Hiram Chirino commented on ZOOKEEPER-80: Hi, Here are my 2 cents for how to implement this so it co-exists nicely with ZOOKEEPER-103 For java at least, you want to group lots of small disjoint contributions into one jar. If they become more massive, it may be worth splitting it out to independent jars, but simplicities sake/maintenance needed to manage small contributions, one jar should be enough. The only tricky bit is that we also want to support implementing the recipe in other languages, so we want to also support multiple module directories. So my proposal is to have a module which would mainly hold the general documentation for the protocol which should be language agnostic: trunk/zookeeper-recipes/ trunk/zookeeper-recipes/src/docs And then we just have sub modules for the implementation of those recipes for the different languages. The java module would use maven directory layouts trunk/zookeeper-recipes/zookeeper-java-recipes trunk/zookeeper-recipes/zookeeper-java-recipes/src/main/java The c stuff would standard GNU c source layout trunk/zookeeper-recipes/zookeeper-c-recipes trunk/zookeeper-recipes/zookeeper-c-recipes/src ruby would use what every ruby folks are used to. trunk/zookeeper-recipes/zookeeper-ruby-recipes Also note that it might be better to replace 'recipes' term with 'protocols'. > Document process for client recipe contributions > > > Key: ZOOKEEPER-80 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-80 > Project: Zookeeper > Issue Type: Task > Components: documentation >Reporter: Patrick Hunt >Assignee: Patrick Hunt > > Per Doug's suggestion I'll use a link instead of copy/paste: > http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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-tabpanel&focusedCommentId=12617823#action_12617823 ] Hiram Chirino commented on ZOOKEEPER-103: - Benjamin, Good point.. I'll comment on ZOOKEERER-80 on how best to sort out the recipies/contrib stuff. > 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-tabpanel&focusedCommentId=12617505#action_12617505 ] Hiram Chirino commented on ZOOKEEPER-83: FYI: The maven folks are working on the security issue: http://docs.codehaus.org/display/MAVEN/Repository+Security > 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 > > 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-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-tabpanel&focusedCommentId=12617503#action_12617503 ] Hiram Chirino commented on ZOOKEEPER-103: - Any updates on this? > 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-102) Need to replace Jute with supported code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617226#action_12617226 ] Hiram Chirino commented on ZOOKEEPER-102: - [protobuf|http://code.google.com/p/protobuf/] might be an option. > Need to replace Jute with supported code > > > Key: ZOOKEEPER-102 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-102 > Project: Zookeeper > Issue Type: Improvement >Reporter: Benjamin Reed > > ZooKeeper currently uses Jute to serialize objects to put on the wire and on > disk. We pulled Jute out of Hadoop and added a C binding. Both versions of > Jute have evolved (although Hadoop still doesn't have a C binding). It would > be nice to use a more standard serialization library. Some options include > Thrift or Google's protocol buffers. > Our main requirements would be Java and C bindings and good performance. (For > example, serializing to XML would give us incredibly bad performance and > would not be acceptible!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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-tabpanel&focusedCommentId=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-96) The jute parser should get generated from the jj files instead of checking in the generated sources
[ https://issues.apache.org/jira/browse/ZOOKEEPER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617087#action_12617087 ] Hiram Chirino commented on ZOOKEEPER-96: +1 on checking in the jar > The jute parser should get generated from the jj files instead of checking in > the generated sources > --- > > Key: ZOOKEEPER-96 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-96 > Project: Zookeeper > Issue Type: Improvement > Components: build > Reporter: Hiram Chirino > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ZooKeeper community
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-98) Make the ZooKeeper optional bits seperate jars.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617072#action_12617072 ] Hiram Chirino commented on ZOOKEEPER-98: It just means the build needs to get updated so that each modules javac output has it's own directory so that a proper jar for each can get created. Right now all the modules: jmx, source code generators, main stuff all get dumped into one classes directory. > 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] 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-tabpanel&focusedCommentId=12617070#action_12617070 ] Hiram Chirino commented on ZOOKEEPER-83: Re-opened as a new issue ZOOKEEPER-103 it reduces the scope of the patch to just be implementing the maven directory conventions. > 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 > > 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-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:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-103: Fix Version/s: 3.0.0 Affects Version/s: (was: 3.0.0) Status: Patch Available (was: Open) > 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 > 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] Updated: (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:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-103: Attachment: ZOOKEEPER-103.patch Attaching patch file for ant build so that it works using the new directory organization. > 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 > 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] Updated: (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:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-103: Attachment: ZOOKEEPER-103.sh This the shell script that will reorgnaize the source locations. > 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 >Affects Versions: 3.0.0 > Reporter: Hiram Chirino > Attachments: 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] Created: (ZOOKEEPER-103) Reorganize the ZooKeeper source distro to follow maven conventions
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 Affects Versions: 3.0.0 Reporter: Hiram Chirino Attachments: 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] 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: --- Attachment: (was: zookeeper-mavened.tgz) > 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 > > 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-97) The code generators should support an optional output directory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-97: --- Attachment: ZOOKEEPER-97.patch Attaching patch that implements the feature. > The code generators should support an optional output directory > --- > > Key: ZOOKEEPER-97 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-97 > Project: Zookeeper > Issue Type: Improvement > Reporter: Hiram Chirino > Attachments: ZOOKEEPER-97.patch > > > Currently the code generators (jute compiler and version gen) generate code > the current directory. If these tools are to be re-used by smart ides, ant > tasks, or maven plugins, the output directory needs to be parameter to the > tools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-97) The code generators should support an optional output directory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617034#action_12617034 ] Hiram Chirino commented on ZOOKEEPER-97: This was actually extracted from the change proposed in ZOOKEEPER-82 > The code generators should support an optional output directory > --- > > Key: ZOOKEEPER-97 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-97 > Project: Zookeeper > Issue Type: Improvement > Reporter: Hiram Chirino > Attachments: ZOOKEEPER-97.patch > > > Currently the code generators (jute compiler and version gen) generate code > the current directory. If these tools are to be re-used by smart ides, ant > tasks, or maven plugins, the output directory needs to be parameter to the > tools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-97) The code generators should support an optional output directory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-97: --- Status: Patch Available (was: Open) > The code generators should support an optional output directory > --- > > Key: ZOOKEEPER-97 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-97 > Project: Zookeeper > Issue Type: Improvement > Reporter: Hiram Chirino > Attachments: ZOOKEEPER-97.patch > > > Currently the code generators (jute compiler and version gen) generate code > the current directory. If these tools are to be re-used by smart ides, ant > tasks, or maven plugins, the output directory needs to be parameter to the > tools. -- 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-tabpanel&focusedCommentId=12617028#action_12617028 ] Hiram Chirino commented on ZOOKEEPER-82: created issue ZOOKEEPER-100 to track that Thread change idea. > 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.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: --- 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.
[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.
[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] 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-tabpanel&focusedCommentId=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] 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-tabpanel&focusedCommentId=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] Created: (ZOOKEEPER-99) All MXBeans interfaces that don't use complex paramters need to be renamed as MBean interaces.
All MXBeans interfaces that don't use complex paramters need to be renamed as MBean interaces. --- Key: ZOOKEEPER-99 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-99 Project: Zookeeper Issue Type: Bug Components: server Reporter: Hiram Chirino Fix For: 3.0.0 All the MXBean interfaces that I've looked at are standard MBean interfaces. The interface names should get renamed to MBean instaead of MXBean. That way the server can also run on a the Java 1.5 Platform. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-98) Make the ZooKeeper optional bits seperate jars.
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] Created: (ZOOKEEPER-97) The code generators should support an optional output directory
The code generators should support an optional output directory --- Key: ZOOKEEPER-97 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-97 Project: Zookeeper Issue Type: Improvement Reporter: Hiram Chirino Currently the code generators (jute compiler and version gen) generate code the current directory. If these tools are to be re-used by smart ides, ant tasks, or maven plugins, the output directory needs to be parameter to the tools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-96) The jute parser should get generated from the jj files instead of checking in the generated sources
The jute parser should get generated from the jj files instead of checking in the generated sources --- Key: ZOOKEEPER-96 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-96 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-94) JMX tests are needed to verify that the JMX MBeans work properly
JMX tests are needed to verify that the JMX MBeans work properly Key: ZOOKEEPER-94 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-94 Project: Zookeeper Issue Type: Bug Components: server Reporter: Hiram Chirino Fix For: 3.0.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-95) There is no need to include the code generators in the zookeeper jar
There is no need to include the code generators in the zookeeper jar Key: ZOOKEEPER-95 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-95 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Interested in IRC to lube ZK communication?
+1 On Fri, Jul 25, 2008 at 12:23 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > http://hadoop.apache.org/zookeeper/irc.html > > Patrick > -- 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-tabpanel&focusedCommentId=12616577#action_12616577 ] Hiram Chirino commented on ZOOKEEPER-83: BTW Hudson does support maven.. see: http://weblogs.java.net/blog/kohsuke/archive/2007/02/maven_2_integra.html > 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.
[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-tabpanel&focusedCommentId=12616575#action_12616575 ] Hiram Chirino commented on ZOOKEEPER-83: BTW there are lots of CI tools used at the ASF which DO support maven. But hey if you like Hudson that's cool. Can we at least merge the patch in so that the maven directory convention is preserved and then we can delete the maven build files if you like. The ant build can work with that structure just fine. If we do that then I can provide folks who are interested in a maven build the pom files that just overlay onto the project do they can use maven to build it. So we both win. ZooKeeper only has 1 build system ant. Maven users also win cause they can get some optional poms from me to build the project with. What do you think? > 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.
[jira] Issue Comment Edited: (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-tabpanel&focusedCommentId=12616567#action_12616567 ] chirino edited comment on ZOOKEEPER-78 at 7/24/08 11:30 AM: -- Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are both Apache committers and Members, and as such, when we commit code to the ASF repository a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] was (Author: chirino): Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are bother Apache committers and Members, and as such, when we commit code to the ASF repository a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] > 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.
[jira] Issue Comment Edited: (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-tabpanel&focusedCommentId=12616567#action_12616567 ] chirino edited comment on ZOOKEEPER-78 at 7/24/08 11:28 AM: -- Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are bother Apache committers and Members, and as such, when we commit code to the ASF repository a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] was (Author: chirino): Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are bother Apache committers and Members, as such when we commit code to the ASF repository like what James had done, and like when you do when you commit code to zookeeper trunk, a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] > 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.
[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-tabpanel&focusedCommentId=12616567#action_12616567 ] Hiram Chirino commented on ZOOKEEPER-78: Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are bother Apache committers and Members, as such when we commit code to the ASF repository like what James had done, and like when you do when you commit code to zookeeper trunk, a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] > 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.
Re: ZooKeeper community
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
Re: ZooKeeper community
> > Are all you guys also PMC members on Hadoop? > Never mind.. I just looked it up in the asf-authorization file. hadoop-zookeeper=akornev,breed,fpj,mahadev,phunt hadoop-pmc=ab,cutting,dhruba,enis,jimk,nigel,omalley,stack,taton,tomwhite 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. Is this being addressed?
Re: ZooKeeper community
On Wed, Jul 23, 2008 at 3:03 PM, Mahadev Konar <[EMAIL PROTECTED]> wrote: > We are fully aware of that Hiram. We are still a sub project of Hadoop and > have been on sourceforge for a while. For being a sub project the Hadoop PMC > needs to vote for it. Zookeeper is in the future roadmap of Hadoop for High > Availability/ configuration management and mounting of different > filesystems. > So that's why were able to get in as a subproject of Hadoop. Yeah.. wish it would have been that easy when we tried to being in ActiveMQ from Codehaus as sub-project of Geronimo since it was THE JMS implementation shipping with Geronimo. I guess the big difference was you guys did a code grant, while the ActiveMQ stuff had to have it's ip checked. Count your blessings. The incubator is really a horrible speed bump to go through. > We are trying to build a community of diverse committers and developers and > its just the start :). > Awesome > Hope you guys can help :). > Yep! You guys have a very interesting project and hard to keep my hands off it. Are all you guys also PMC members on Hadoop? > Mahadev > > > On 7/23/08 11:54 AM, "Hiram Chirino" <[EMAIL PROTECTED]> wrote: > >> Hope your mentors have mentioned that diversity is a good thing. Also >> how did you guys bypass the incubator? >> >> On Wed, Jul 23, 2008 at 2:50 PM, Mahadev Konar <[EMAIL PROTECTED]> wrote: >>> Yes they are! >>> >>> mahadev >>> >>> >>> On 7/23/08 11:47 AM, "Hiram Chirino" <[EMAIL PROTECTED]> wrote: >>> >>>> 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: ZooKeeper community
Hope your mentors have mentioned that diversity is a good thing. Also how did you guys bypass the incubator? On Wed, Jul 23, 2008 at 2:50 PM, Mahadev Konar <[EMAIL PROTECTED]> wrote: > Yes they are! > > mahadev > > > On 7/23/08 11:47 AM, "Hiram Chirino" <[EMAIL PROTECTED]> wrote: > >> 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
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
Re: ZooKeeper community
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
[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.
[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: --- Assignee: (was: Hiram Chirino) 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 > 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] Issue Comment Edited: (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-tabpanel&focusedCommentId=12616200#action_12616200
]
chirino edited comment on ZOOKEEPER-83 at 7/23/08 11:18 AM:
--
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}
was (Author: chirino):
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] 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-tabpanel&focusedCommentId=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.
ZooKeeper community
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-82) Make the ZooKeeperServer more DI friendly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
[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-tabpanel&focusedCommentId=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-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615793#action_12615793 ] Hiram Chirino commented on ZOOKEEPER-83: Sure.. maven is not yet impervious to having it's repository hacked. But does it actually happen? No. But then again any repository can get hacked.. even the one we deploy our distributions to. Yes we sign the releases, but how often do folks actually validate against it? So in most systems that kind of attack will happen. Is that the only issue? > 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.
Re: Website
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: Website
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
[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-tabpanel&focusedCommentId=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 > > > 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-tabpanel&focusedCommentId=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-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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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.
Re: Website
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-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-tabpanel&focusedCommentId=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.
Website
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-tabpanel&focusedCommentId=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.
[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-tabpanel&focusedCommentId=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.
