Zookeeper isn't strictly needed to make the gora-solr module work. The Zookeeper dependency occurs when we want to do partitioned queries and updates, and that's not implemented yet. The Solr test framework, however, does need Zookeeper. I think Maven uses separate class loaders for each module when they're tested, so the only time this would be an issue is when an integration test needs both the Solr test framework and HBase, and that's going to be an issue regardless of whether you're using Gora.
Would it work to move Zookeeper from the parent pom to the gora-solr pom and scope it as "test"? There are undoubtably several other dependencies that can be scoped that way too. Cheers, -Scott On Jul 19, 2013, at 3:37 PM, Apostolis Giannakidis <[email protected]> wrote: > Regarding the Avro upgrade, even though I am not yet convinced that it is > necessary to be done in order to successfully accomplish the integration > with Oracle NoSQL, I am also +1 for upgrading Avro. It would definitely > improve Gora's potential for integrating with other projects. I would also > like to contribute to this as well. > > Cheers, > Apos > > > On Fri, Jul 19, 2013 at 10:28 PM, Renato Marroquín Mogrovejo < > [email protected]> wrote: > >> Hi all, >> >> >> I think we should all work on getting rid of those ugly Avro problems as we >> need to support newer versions of it and also because that Avro upgrade is >> needed for Apos in his GSoC and maybe for Udesh as well? >> >> I think that GORA-72/257 is also a very appealing thing to do, but maybe it >> can wait until we dust the Avro stuff because we really need it to make >> Gora play around with other projects e.g. Bigtop, Cascasing, Giraph, and >> others. And as Lewis said, we might think on trying to separate gora-core >> as much as possible from external dependencies (maybe having a gora-avro >> module?) >> >> So I think we are reaching a consensus here (: >> >> 1. Disable the Solr module until we get to GORA-72/257, and people who >> needs it can just manually enable it and use it. >> I am +1 on this one. >> 2. Upgrade Avro version across Gora as we desperately need it for >> integration with other projects >> I am a big +1 on this one, and I can chip in and learn what is needed. >> 3. Releasing 0.4 (getting some more features in until it) and start looking >> into GORA-72/257 >> 4. Review Avro dependencies within gora-core >> >> What do you guys think? >> >> >> Renato M. >> >> 2013/7/18 Lewis John Mcgibbney <[email protected]> >> >>> Hi, >>> >>> On Thu, Jul 18, 2013 at 3:12 PM, <[email protected]> >> wrote: >>> >>>> Sorry for late reply. >>>> >>> >>> Same here. I have been getting rammed in work right now so apologies for >>> late reply to lists. >>> >>>> >>>> Could we disable solr module for a while and release note it until we >>>> resolve no 3 with HBase module? >>>> >>> >>> This is certainly an option indeed. I would like to throw the cat in >>> amongst the pigeons and propose the following in an attempt for us to >> reach >>> consensus on a 0.4 roadmap... of sorts. >>> >>> * GORA-201 - Upgrade HBase API >>> * GORA-72/257 OSGi/Classloading >>> >>> I am only throwing these two in right now as I think they are the most >>> critical ones to address. I think it will give us a lot of flexibility if >>> we can get the latter working as then it means modules can progress >>> independently from a dependency POV. This is really important. When >> Renato >>> was in town he was talking with some folks from another social network >>> other than Facebook ;) which are having some Avro problems... The >>> classloading and dependency management for us is an issue. >>> One thought I've had on this though is that fundamentally everything >> needs >>> to tie back in to core anyway... as we extend everything here... is it >>> possible for us to decouple/extract away as much of our reliance upon >>> external API's (such as Avro)? This would mean that core has less >> external >>> dependencies? >>> >>> That being said, I think it would be nice for us to reach agreement on >> what >>> needs to be fixed with the most urgency? >>> >>> I am happy to chip in on the HBase side when I get free time... but I do >>> not wish to try this one alone as I'm going to be learning a pile of gear >>> here. >>> >>> I will back a consensus. If the choice is to disable the Solr Module >>> (temporarily adding HBase 0.90.4 compliant deps) then working on a branch >>> for either issue... then I am happy to do this. >>> >>> Thanks >>> Lewis >>> >>> https://issues.apache.org/jira/browse/GORA-201 >>> https://issues.apache.org/jira/browse/GORA-257 >>> >>
