[
https://issues.apache.org/jira/browse/WHIRR-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086470#comment-13086470
]
Tom White commented on WHIRR-361:
---------------------------------
I tried the latest patch and a ZK cluster starts OK (I get 'imok' back from
each server), even though the integration test still fails in the same way as
before. Since it works for others, this is not a blocker for release, although
it would be nice to find out what's going on here.
> refactor jclouds dependencies
> -----------------------------
>
> Key: WHIRR-361
> URL: https://issues.apache.org/jira/browse/WHIRR-361
> Project: Whirr
> Issue Type: Improvement
> Components: core
> Affects Versions: 0.6.0
> Reporter: Adrian Cole
> Assignee: Adrian Cole
> Priority: Blocker
> Fix For: 0.6.0
>
> Attachments: ConfigureClusterAction.java, WHIRR-361-fixguava.patch,
> WHIRR-361.patch, WHIRR-361.patch, WHIRR-361.patch, WHIRR-361.patch,
> WHIRR-361.patch,
> org.apache.whirr.service.hbase.integration.HBase089ServiceTest.txt
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> There are a few problems in our maven configuration, and a couple places
> where we aren't using the best jclouds configuration.
> * in our pom files, we needlessly declare transitive dependencies modules.
> this is unnecessary maintenance, as jclouds version/dependency configuration
> is scoped to whirr core
> * we've switched to SLF4J, yet haven't configured jclouds to use it
> * especially considering we are uploading large blobs, we should be using
> the jclouds EnterpriseConfigurationModule which handles file slicing much
> more effectively.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
