Re: Build on trunk seems to be busted

2010-04-24 Thread Mahadev Konar
Hi Alan,
  It seems to work fine for me.

Can you try:

Ant clean

And then 

Ant jar?

Could be possible that some classes might have been accidentally deleted!

Also, please check svn status to see if any java files are missing from the
source tree.


Thanks
mahadev


On 4/24/10 7:44 AM, "Alan D. Cabrera"  wrote:

> BUILD FAILED
> /Users/acabrera/dev/hadoop/zookeeper/build.xml:911: The following
> error occurred while executing this line:
> /Users/acabrera/dev/hadoop/zookeeper/build.xml:446: Reference
> classpath not found.
> [acabrera-mn:zookeeper 538]$ java -version
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125)
> Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)
> 
> 
> 
> Regards,
> Alan
> 



[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

2010-04-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860608#action_12860608
 ] 

Hadoop QA commented on ZOOKEEPER-679:
-

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12442757/ZOOKEEPER-679.patch
  against trunk revision 936624.

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 3 new or modified tests.

+1 javadoc.  The javadoc tool did not generate any warning messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

+1 findbugs.  The patch does not introduce any new Findbugs warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

+1 core tests.  The patch passed core unit tests.

+1 contrib tests.  The patch passed contrib unit tests.

Test results: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/73/testReport/
Findbugs warnings: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/73/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/73/console

This message is automatically generated.

> Offers a node design for interacting with the Java Zookeeper client.
> 
>
> Key: ZOOKEEPER-679
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: contrib, java client, tests
>Reporter: Aaron Crow
>Assignee: Aaron Crow
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, 
> ZOOKEEPER-679.patch, ZOOKEEPER-679.patch
>
>
> Following up on my conversations with Patrick and Mahadev 
> (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695).
> This patch includes the implementation as well as unit tests. The first unit 
> test gives a simple high level demo of using the node API.
> The current implementation is simple and is only what I need withe current 
> project I am working on. However, I am very open to any and all suggestions 
> for improvement.
> This is a proposal to support a simplified node (or File) like API into a 
> Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to 
> Java's File API design.
> Although, I'm trying to make it easier in a few spots. For example, deleting 
> a Node recursively is done by default. I also lean toward resolving 
> Exceptions "under the hood" when it seems appropriate. For example, if you 
> ask a Node if it exists, and its parent doesn't even exist, you just get a 
> false back (rather than a nasty Exception).
> As for watches and ephemeral nodes, my current work does not need these 
> things so I currently have no handling of them. But if potential users of  
> the "Node a.k.a. File" design want these things, I'd be open to supporting 
> them as reasonable.

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



[jira] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

2010-04-24 Thread Aaron Crow (JIRA)

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

Aaron Crow updated ZOOKEEPER-679:
-

Status: Patch Available  (was: Open)

now with proper diff, to put ztree library in contrib

> Offers a node design for interacting with the Java Zookeeper client.
> 
>
> Key: ZOOKEEPER-679
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: contrib, java client, tests
>Reporter: Aaron Crow
>Assignee: Aaron Crow
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, 
> ZOOKEEPER-679.patch, ZOOKEEPER-679.patch
>
>
> Following up on my conversations with Patrick and Mahadev 
> (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695).
> This patch includes the implementation as well as unit tests. The first unit 
> test gives a simple high level demo of using the node API.
> The current implementation is simple and is only what I need withe current 
> project I am working on. However, I am very open to any and all suggestions 
> for improvement.
> This is a proposal to support a simplified node (or File) like API into a 
> Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to 
> Java's File API design.
> Although, I'm trying to make it easier in a few spots. For example, deleting 
> a Node recursively is done by default. I also lean toward resolving 
> Exceptions "under the hood" when it seems appropriate. For example, if you 
> ask a Node if it exists, and its parent doesn't even exist, you just get a 
> false back (rather than a nasty Exception).
> As for watches and ephemeral nodes, my current work does not need these 
> things so I currently have no handling of them. But if potential users of  
> the "Node a.k.a. File" design want these things, I'd be open to supporting 
> them as reasonable.

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



[jira] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

2010-04-24 Thread Aaron Crow (JIRA)

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

Aaron Crow updated ZOOKEEPER-679:
-

Attachment: ZOOKEEPER-679.patch

Actual patch to move library to contrib/ztree

> Offers a node design for interacting with the Java Zookeeper client.
> 
>
> Key: ZOOKEEPER-679
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: contrib, java client, tests
>Reporter: Aaron Crow
>Assignee: Aaron Crow
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, 
> ZOOKEEPER-679.patch, ZOOKEEPER-679.patch
>
>
> Following up on my conversations with Patrick and Mahadev 
> (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695).
> This patch includes the implementation as well as unit tests. The first unit 
> test gives a simple high level demo of using the node API.
> The current implementation is simple and is only what I need withe current 
> project I am working on. However, I am very open to any and all suggestions 
> for improvement.
> This is a proposal to support a simplified node (or File) like API into a 
> Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to 
> Java's File API design.
> Although, I'm trying to make it easier in a few spots. For example, deleting 
> a Node recursively is done by default. I also lean toward resolving 
> Exceptions "under the hood" when it seems appropriate. For example, if you 
> ask a Node if it exists, and its parent doesn't even exist, you just get a 
> false back (rather than a nasty Exception).
> As for watches and ephemeral nodes, my current work does not need these 
> things so I currently have no handling of them. But if potential users of  
> the "Node a.k.a. File" design want these things, I'd be open to supporting 
> them as reasonable.

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



[jira] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

2010-04-24 Thread Aaron Crow (JIRA)

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

Aaron Crow updated ZOOKEEPER-679:
-

Status: Open  (was: Patch Available)

oops, I think I forgot to upload latest diff

> Offers a node design for interacting with the Java Zookeeper client.
> 
>
> Key: ZOOKEEPER-679
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: contrib, java client, tests
>Reporter: Aaron Crow
>Assignee: Aaron Crow
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, 
> ZOOKEEPER-679.patch, ZOOKEEPER-679.patch
>
>
> Following up on my conversations with Patrick and Mahadev 
> (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695).
> This patch includes the implementation as well as unit tests. The first unit 
> test gives a simple high level demo of using the node API.
> The current implementation is simple and is only what I need withe current 
> project I am working on. However, I am very open to any and all suggestions 
> for improvement.
> This is a proposal to support a simplified node (or File) like API into a 
> Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to 
> Java's File API design.
> Although, I'm trying to make it easier in a few spots. For example, deleting 
> a Node recursively is done by default. I also lean toward resolving 
> Exceptions "under the hood" when it seems appropriate. For example, if you 
> ask a Node if it exists, and its parent doesn't even exist, you just get a 
> false back (rather than a nasty Exception).
> As for watches and ephemeral nodes, my current work does not need these 
> things so I currently have no handling of them. But if potential users of  
> the "Node a.k.a. File" design want these things, I'd be open to supporting 
> them as reasonable.

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



[jira] Commented: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

2010-04-24 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12860597#action_12860597
 ] 

Hadoop QA commented on ZOOKEEPER-679:
-

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12440561/ZOOKEEPER-679.patch
  against trunk revision 936624.

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 3 new or modified tests.

+1 javadoc.  The javadoc tool did not generate any warning messages.

+1 javac.  The applied patch does not increase the total number of javac 
compiler warnings.

+1 findbugs.  The patch does not introduce any new Findbugs warnings.

+1 release audit.  The applied patch does not increase the total number of 
release audit warnings.

+1 core tests.  The patch passed core unit tests.

+1 contrib tests.  The patch passed contrib unit tests.

Test results: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/72/testReport/
Findbugs warnings: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/72/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h1.grid.sp2.yahoo.net/72/console

This message is automatically generated.

> Offers a node design for interacting with the Java Zookeeper client.
> 
>
> Key: ZOOKEEPER-679
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: contrib, java client, tests
>Reporter: Aaron Crow
>Assignee: Aaron Crow
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, 
> ZOOKEEPER-679.patch
>
>
> Following up on my conversations with Patrick and Mahadev 
> (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695).
> This patch includes the implementation as well as unit tests. The first unit 
> test gives a simple high level demo of using the node API.
> The current implementation is simple and is only what I need withe current 
> project I am working on. However, I am very open to any and all suggestions 
> for improvement.
> This is a proposal to support a simplified node (or File) like API into a 
> Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to 
> Java's File API design.
> Although, I'm trying to make it easier in a few spots. For example, deleting 
> a Node recursively is done by default. I also lean toward resolving 
> Exceptions "under the hood" when it seems appropriate. For example, if you 
> ask a Node if it exists, and its parent doesn't even exist, you just get a 
> false back (rather than a nasty Exception).
> As for watches and ephemeral nodes, my current work does not need these 
> things so I currently have no handling of them. But if potential users of  
> the "Node a.k.a. File" design want these things, I'd be open to supporting 
> them as reasonable.

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



[jira] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

2010-04-24 Thread Aaron Crow (JIRA)

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

Aaron Crow updated ZOOKEEPER-679:
-

Status: Patch Available  (was: In Progress)

> Offers a node design for interacting with the Java Zookeeper client.
> 
>
> Key: ZOOKEEPER-679
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: contrib, java client, tests
>Reporter: Aaron Crow
>Assignee: Aaron Crow
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, 
> ZOOKEEPER-679.patch
>
>
> Following up on my conversations with Patrick and Mahadev 
> (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695).
> This patch includes the implementation as well as unit tests. The first unit 
> test gives a simple high level demo of using the node API.
> The current implementation is simple and is only what I need withe current 
> project I am working on. However, I am very open to any and all suggestions 
> for improvement.
> This is a proposal to support a simplified node (or File) like API into a 
> Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to 
> Java's File API design.
> Although, I'm trying to make it easier in a few spots. For example, deleting 
> a Node recursively is done by default. I also lean toward resolving 
> Exceptions "under the hood" when it seems appropriate. For example, if you 
> ask a Node if it exists, and its parent doesn't even exist, you just get a 
> false back (rather than a nasty Exception).
> As for watches and ephemeral nodes, my current work does not need these 
> things so I currently have no handling of them. But if potential users of  
> the "Node a.k.a. File" design want these things, I'd be open to supporting 
> them as reasonable.

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



[jira] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

2010-04-24 Thread Aaron Crow (JIRA)

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

Aaron Crow updated ZOOKEEPER-679:
-

Status: Patch Available  (was: Open)

Moving ztree library to contrib, per Mahadev's request.

> Offers a node design for interacting with the Java Zookeeper client.
> 
>
> Key: ZOOKEEPER-679
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: contrib, java client, tests
>Reporter: Aaron Crow
>Assignee: Aaron Crow
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, 
> ZOOKEEPER-679.patch
>
>
> Following up on my conversations with Patrick and Mahadev 
> (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695).
> This patch includes the implementation as well as unit tests. The first unit 
> test gives a simple high level demo of using the node API.
> The current implementation is simple and is only what I need withe current 
> project I am working on. However, I am very open to any and all suggestions 
> for improvement.
> This is a proposal to support a simplified node (or File) like API into a 
> Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to 
> Java's File API design.
> Although, I'm trying to make it easier in a few spots. For example, deleting 
> a Node recursively is done by default. I also lean toward resolving 
> Exceptions "under the hood" when it seems appropriate. For example, if you 
> ask a Node if it exists, and its parent doesn't even exist, you just get a 
> false back (rather than a nasty Exception).
> As for watches and ephemeral nodes, my current work does not need these 
> things so I currently have no handling of them. But if potential users of  
> the "Node a.k.a. File" design want these things, I'd be open to supporting 
> them as reasonable.

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



[jira] Updated: (ZOOKEEPER-679) Offers a node design for interacting with the Java Zookeeper client.

2010-04-24 Thread Aaron Crow (JIRA)

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

Aaron Crow updated ZOOKEEPER-679:
-

Status: In Progress  (was: Patch Available)

> Offers a node design for interacting with the Java Zookeeper client.
> 
>
> Key: ZOOKEEPER-679
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-679
> Project: Zookeeper
>  Issue Type: New Feature
>  Components: contrib, java client, tests
>Reporter: Aaron Crow
>Assignee: Aaron Crow
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-679.patch, ZOOKEEPER-679.patch, 
> ZOOKEEPER-679.patch
>
>
> Following up on my conversations with Patrick and Mahadev 
> (http://n2.nabble.com/Might-I-contribute-a-Node-design-for-the-Java-API-td4567695.html#a4567695).
> This patch includes the implementation as well as unit tests. The first unit 
> test gives a simple high level demo of using the node API.
> The current implementation is simple and is only what I need withe current 
> project I am working on. However, I am very open to any and all suggestions 
> for improvement.
> This is a proposal to support a simplified node (or File) like API into a 
> Zookeeper tree, by wrapping the Zookeeper Java client. It is similar to 
> Java's File API design.
> Although, I'm trying to make it easier in a few spots. For example, deleting 
> a Node recursively is done by default. I also lean toward resolving 
> Exceptions "under the hood" when it seems appropriate. For example, if you 
> ask a Node if it exists, and its parent doesn't even exist, you just get a 
> false back (rather than a nasty Exception).
> As for watches and ephemeral nodes, my current work does not need these 
> things so I currently have no handling of them. But if potential users of  
> the "Node a.k.a. File" design want these things, I'd be open to supporting 
> them as reasonable.

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



Build on trunk seems to be busted

2010-04-24 Thread Alan D. Cabrera

BUILD FAILED
/Users/acabrera/dev/hadoop/zookeeper/build.xml:911: The following  
error occurred while executing this line:
/Users/acabrera/dev/hadoop/zookeeper/build.xml:446: Reference  
classpath not found.

[acabrera-mn:zookeeper 538]$ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-9M3125)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)



Regards,
Alan