[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-tabpanelfocusedCommentId=12923516#action_12923516 ] Doug Cutting commented on ZOOKEEPER-102: Avro is not wire-compatible with Jute. 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-521) include autotools (autoconf/automake) in NOTICE file
[ https://issues.apache.org/jira/browse/ZOOKEEPER-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12752752#action_12752752 ] Doug Cutting commented on ZOOKEEPER-521: This is not required. Many Apache projects (e.g., HTTPD) have long included autoconf-generated configure scripts in their releases and none to my knowledge include anything in the NOTICE file. If someone feels this policy is incorrect or needs clarificaiton then they should take it up on legal-disc...@a.o, not on zookeeper-...@h.a.o. include autotools (autoconf/automake) in NOTICE file Key: ZOOKEEPER-521 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-521 Project: Zookeeper Issue Type: Task Components: build, documentation Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.3.0 The toplevel notice file should be updated to credit the gnu autotools project, something like: This project includes scripts generated by GNU autotools (autoconf/automake/etc...). These files are released under the Apache license. This is permissible under the license clarification at: http://ftp.gnu.org/old-gnu/Manuals/autoconf-2.53/html_node/Distributing.html#Distributing we should also take the opportunity to adjust the existing text as detailed here: http://apache.org/legal/src-headers.html#notice -- 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 3.2.0 to a Maven Repository
[ https://issues.apache.org/jira/browse/ZOOKEEPER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723211#action_12723211 ] Doug Cutting commented on ZOOKEEPER-224: why do we need ivy? Ivy seems to be the best way to integrate Ant-based projects into the Maven world. You write an Ivy config that lists the jars you depend on, and Ivy fetches them, so that you no longer need to include them in svn. It can generate a POM file from its configuration, so that applications that depend on Zookeeper can easily get it and its dependencies. If you maintain your POM file manually, then each time you add or upgrade a lib you have to update multiple places, while with Ivy you only list your dependencies in one place. I think Ivy can also push releases into Maven repos, but I haven't tried that yet. I think this can also be done manually just by copying the .jar, .md5, .sha1, .pom, and .asc files to the right directory on people.apache.org. I did a simplisitic conversion of Avro to Ivy (AVRO-53, http://svn.apache.org/viewvc?view=revrevision=785776). The build.xml now generates all of the files but the .asc. When I first try to do a release I'll learn whether this works! Deploy ZooKeeper 3.2.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 Fix For: 3.2.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-224) Deploy ZooKeeper 3.2.0 to a Maven Repository
[ https://issues.apache.org/jira/browse/ZOOKEEPER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723257#action_12723257 ] Doug Cutting commented on ZOOKEEPER-224: but for the specific issue of getting our jars into the maven repository, we can just run a command after we do the release. right? Moreover, I think you have to. I don't think either Maven or Ivy can sign things correctly. Deploy ZooKeeper 3.2.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 Fix For: 3.2.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-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-tabpanelfocusedCommentId=12650636#action_12650636 ] Doug Cutting commented on ZOOKEEPER-224: Shouldn't the pom metadata files be either included in svn or generated by the build? We shouldn't be publishing artifacts without a documented process in place so that any committer can build the next release. So the creation of this needs to be part of http://wiki.apache.org/hadoop/ZooKeeper/HowToRelease. We shouldn't generate new release artifacts after the release vote. Maybe, if the process is documented, and Pat's willing to create publish these artifacts after the fact, an exception can be made for a few past releases, but going forward, this is not a good process. 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] Commented: (ZOOKEEPER-233) Create a slimer jar for clients to reduce thier disk footprint.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12650766#action_12650766 ] Doug Cutting commented on ZOOKEEPER-233: Why not generate two disjoint jar files, one that requires the other? 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.
[jira] Commented: (ZOOKEEPER-233) Create a slimer jar for clients to reduce thier disk footprint.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12650814#action_12650814 ] Doug Cutting commented on ZOOKEEPER-233: I think the more common thing for projects that generate multiple jars is for them to be disjoint, so it might be less confusing if they're disjoint. 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.
[jira] Commented: (ZOOKEEPER-110) Build script relies on svnant, which is not compatible with subversion 1.5 working copies
[ https://issues.apache.org/jira/browse/ZOOKEEPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620337#action_12620337 ] Doug Cutting commented on ZOOKEEPER-110: The exec task will fail on Windows - it won't be able to find the executable sh.exe. Hadoop requires cygwin on Windows. Build script relies on svnant, which is not compatible with subversion 1.5 working copies - Key: ZOOKEEPER-110 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-110 Project: Zookeeper Issue Type: Bug Components: build Affects Versions: 3.0.0 Environment: Subversion 1.5 command line, or subclipse version 1.4.x Reporter: Jakob Homan Assignee: Jakob Homan Attachments: svntask.diff The current build.xml ant script uses svnant to obtain the latest revision number from the repo, however svnant is not compatible with subversion 1.5 (http://subversion.tigris.org/svn_1.5_releasenotes.html), and so the build fails with working copies checked out by this version. The build fails with this version of subversion is too old, please get a newer version... This will become more apparent as svn 1.5 trickles out; I'm using a brand new dev environment with both subclipse 1.4 and svn 1.5 client, so I got bit rather quickly. Those with svn 1.5 can get the code from the trunk, but cannot do an ant build. svnant hasn't been updated in more than a year and appears to be dead, so it may no longer be a viable tool for the ant build. -- 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-tabpanelfocusedCommentId=12619975#action_12619975 ] Doug Cutting commented on ZOOKEEPER-103: On ZOOKEEPER-83 we plainly agreed that we were going to compromise and use maven conventions for the directory structure I don't see that. Pat Nigel agreed that we should be able to produce Maven artifacts. Mahadev supported Maven naming conventions, but I don't see Pat reversing his -1 on supporting multiple build systems. 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-tabpanelfocusedCommentId=12619111#action_12619111 ] Doug Cutting 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. That imposes big, redundant directory names. Is there no way to configure Maven otherwise? Reorganize the ZooKeeper source distro to follow maven conventions -- Key: ZOOKEEPER-103 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-103 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 3.0.0 Attachments: ZOOKEEPER-103.patch, ZOOKEEPER-103.sh This was sugested as way to bridge the gap in ZOOKEEPER-83 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615799#action_12615799 ] Doug Cutting commented on ZOOKEEPER-83: --- Is that the only issue? I think its fundamentally a cultural issue. We have developers here who are familiar with Ant and have developed processes around Ant and are not frustrated with Ant and see no need to switch to a different build system. It's a bit like git versus svn: git may be better, but not enough folks yet feel that svn is a significant bottleneck, perhaps through ignorance. I still use Emacs, despite folks telling me I should use an IDE. If the majority of Zookeeper's community want to switch to Maven, I would certainly not oppose it. 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-80) Document process for client recipe contributions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614466#action_12614466
]
Doug Cutting commented on ZOOKEEPER-80:
---
Whoa! Big issue description! Perhaps you could have gone with a link to the
mail archive? Descriptions are included in every message about the issue...
In any case, I think perhaps each recipe deserves its own code-tree, and should
hence be a separate contrib module. Perhaps, instead of 'contrib/' these
should just be under 'recipes/', with a separate src/, lib/, doc/, build.xml,
README.txt, etc. for each? Multiple language implementations would go in
different src/ subdirectories. Does that work?
Also, I am -1 for making these subversion-only. Only released software is
fully covered by the Apache license. Subversion is for internal exchange by
Apache of works-in-progress, not for end users.
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
How do we accept zk client recipe contributions? Initiated by the following
discussion on the mailing list:
-- ben reed wrote
Excellent proposal. The only thing I would add is that there should be
an english description of the recipe in subversion. That way if someone
wanted to do a compatible binding they can do it. If the recipe is on
the wiki it would be hard to keep it in sync, so it is important that it
is in subversion. My preference would be that the doc would be in the
same contrib subdirectory as the source for ease of maintenance.
ben
Patrick Hunt wrote:
James, thanks for the contribution! Tests and everything. :-)
Jacob sent some mail to the list recently (attached) that details a
protocol that he's used successfully (and picked up by some zk users).
I have a todo item to document this protocol on the recipes wiki page,
haven't gotten to it yet. Not sure how/if this matches what you've
done but we should sync up (also see below).
https://issues.apache.org/jira/browse/ZOOKEEPER-79
There has been some discussion on client side helper code in the past
however this is the first contribution. We need to make some decisions
and outline what/how we will accept.
1) I think we should have a
contrib/recipes/{java/{main,test}/org/apache/zookeeper/... ,c/,...}
hierarchy for contributions that implement recipes, including any
helper code
2) We should first document recipes on the wiki, then implement them
in the code
http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperRecipes
The code should fully document the api/implementation, and refer to
wiki page for protocol specifics.
3) What should we do relative to ZK releases. Are recipes included in
a release? Will bugs in recipes hold up a release?
My initial thought is that contrib is available through svn, but not
included in the release. If users want to access/use this code they
will be required to checkout/build themselves. (at least initially)
4) We will not require parody btw the various client languages.
Currently we support Java/C clients, we will be adding various
scripting languages soon. Contributions will be submitted for various
clients (James' submission is for java), that will be placed into
contrib, if someone else contributes C bindings (etc...) we will add
those to contrib/recipes as well.
5) Implementations should strive to implement similar recipe protocols
(see 2 above, a good reason to document before implement). There may
be multiple, different, protocols each with their own implementation,
but for a particular protocol the implementations should be the same.
We may want to stress 5 even more - if multiple clients
implementations (c/java/...) are participating in a single instance of
leader election it will be CRITICAL for them to be inter-operable.
Comments, questions, suggestion?
Patrick
James Strachan wrote:
So having recently discovered ZooKeeper, I'm really liking it - good
job folks!
I've seen discussions of building high level features from the core ZK
library and had not seen any available on the interweb so figured I'd
have a try creating a simple one. Feel free to ignore it if a ZK ninja
can think of a neater way of doing it - I've basically followed the
protocol defined in the recent ZK presentation...
http://developer.yahoo.com/blogs/hadoop/2008/03/intro-to-zookeeper-video.html
I've submitted the code as a patch here...
https://issues.apache.org/jira/browse/ZOOKEEPER-78
I
