I'm open to this, how do we create a binary releases using maven using assemblies?
Aaron On Wed, Oct 24, 2012 at 5:49 PM, Patrick Hunt <[email protected]> wrote: > What do you think about moving everything that's in the "src" > directory up one level? (and remove src) It would be more consistent > with typical maven based projects. i.e. top level pom, everything > below that. > > Might also help us out when it comes time to do the packaging work. > Everything in blur repo would be available as a sub directory to the > top level pom. We're also likely to remove the lib directory once we > have our own assemblies. (not sure about interface dir, some of > bin/conf might go into src/main/resources...) > > Patrick > > On Wed, Oct 24, 2012 at 1:45 PM, Aaron McCurry <[email protected]> wrote: >> +1 >> >> Sent from my iPhone >> >> On Oct 24, 2012, at 4:40 PM, Patrick Hunt <[email protected]> wrote: >> >>> If there are no objections I'll merge in my blur client shell >>> submission, sound good? >>> >>> Patrick >>> >>> On Wed, Oct 24, 2012 at 11:27 AM, Aaron McCurry <[email protected]> wrote: >>>> +1 on this solution. >>>> >>>> On Wed, Oct 24, 2012 at 2:24 PM, Patrick Hunt <[email protected]> wrote: >>>>> Hi Gagan, I did find the cause, but not a good solution. Relying on >>>>> everyone to set their umask is going to be onerous. It would be great >>>>> if you could provide a proper solution - the one you suggested sounds >>>>> good. >>>>> >>>>> Regards, >>>>> >>>>> Patrick >>>>> >>>>> On Tue, Oct 23, 2012 at 11:53 PM, Gagan Juneja >>>>> <[email protected]> wrote: >>>>>> Oops! I missed Patrick's last post. >>>>>> >>>>>> On Wed, Oct 24, 2012 at 12:07 PM, Gagan Juneja >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> I have simulated this issue on ubuntu box. I found that by default >>>>>>> ubuntu >>>>>>> creates directory with *775 *permissions. And there is one property in >>>>>>> Hadoop Configuration named "dfs.datanode.data.dir.perm" and default >>>>>>> value >>>>>>> for this is *755*. Somewhere in code permissions for data directories >>>>>>> are >>>>>>> verified and it fails there and then. >>>>>>> >>>>>>> If we set this property in Configuration object with value *775,* all >>>>>>> the >>>>>>> test cases are passing and build is Successful. >>>>>>> >>>>>>> We can set this in *startDfs* method of >>>>>>> *org.apache.blur.MiniCluster*class. Please verify this, if problem got >>>>>>> resolved at your end then I can >>>>>>> provide patch for this. >>>>>>> >>>>>>> Regards, >>>>>>> Gagan >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 24, 2012 at 4:32 AM, Patrick Hunt <[email protected]> wrote: >>>>>>> >>>>>>>> Pushed a small cleanup to move all test file output into respective >>>>>>>> target directories and use absolute paths for test file locations. >>>>>>>> >>>>>>>> I thought this might fix the BlurClusterTest however that's not the >>>>>>>> case: >>>>>>>> >>>>>>>> Starting DataNode 0 with dfs.data.dir: >>>>>>>> >>>>>>>> /home/phunt/dev/blur/src/blur-core/target/tmp/cluster/dfs/data/data1,/home/phunt/dev/blur/src/blur-core/target/tmp/cluster/dfs/data/data2 >>>>>>>> ERROR 20121023_15:58:10:010_PDT [main] datanode.DataNode: All >>>>>>>> directories in dfs.data.dir are invalid. >>>>>>>> ERROR 20121023_15:58:10:010_PDT [main] datanode.DataNode: All >>>>>>>> directories in dfs.data.dir are invalid. >>>>>>>> ERROR 20121023_15:58:10:010_PDT [main] blur.MiniCluster: error opening >>>>>>>> file system >>>>>>>> java.lang.NullPointerException >>>>>>>> at >>>>>>>> org.apache.hadoop.hdfs.MiniDFSCluster.startDataNodes(MiniDFSCluster.java:422) >>>>>>>> at >>>>>>>> org.apache.hadoop.hdfs.MiniDFSCluster.<init>(MiniDFSCluster.java:280) >>>>>>>> at >>>>>>>> org.apache.hadoop.hdfs.MiniDFSCluster.<init>(MiniDFSCluster.java:124) >>>>>>>> >>>>>>>> Patrick >>>>>>>> >>>>>>>> On Tue, Oct 23, 2012 at 2:43 PM, Patrick Hunt <[email protected]> wrote: >>>>>>>>> I pushed a small cleanup to versioning in the poms. >>>>>>>>> >>>>>>>>> Patrick >>>>>>>>> >>>>>>>>> On Tue, Oct 23, 2012 at 2:38 PM, Patrick Hunt <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> I'll work on fixing the tmp issue, that's something I can handle. ;-) >>>>>>>>>> Everything should be in target. >>>>>>>>>> >>>>>>>>>> Patrick >>>>>>>>>> >>>>>>>>>> On Tue, Oct 23, 2012 at 2:37 PM, Aaron McCurry <[email protected]> >>>>>>>> wrote: >>>>>>>>>>> Hmm, I will take a look at that one next. >>>>>>>>>>> >>>>>>>>>>> Aaron >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 23, 2012 at 5:20 PM, Patrick Hunt <[email protected]> >>>>>>>> wrote: >>>>>>>>>>>> Thanks Aaron. The other failing test "BlurClusterTest" is somehow >>>>>>>>>>>> due >>>>>>>>>>>> to the directory used. "./tmp/cluster". If I change to >>>>>>>>>>>> "file://tmp/cluster" the test passes. Any ideas? Seems somehow >>>>>>>> related >>>>>>>>>>>> to using relative paths? >>>>>>>>>>>> >>>>>>>>>>>> Patrick >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 23, 2012 at 2:13 PM, Aaron McCurry <[email protected]> >>>>>>>> wrote: >>>>>>>>>>>>> Found it, the test did not setup the indexing options correctly. >>>>>>>>>>>>> I >>>>>>>>>>>>> have committed a fix for the test. >>>>>>>>>>>>> >>>>>>>>>>>>> Aaron >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Oct 23, 2012 at 5:08 PM, Aaron McCurry >>>>>>>>>>>>> <[email protected]> >>>>>>>> wrote: >>>>>>>>>>>>>> After cleaning up the test, I have gotten the same NPE. Strange >>>>>>>>>>>>>> behavior, still working on why. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Aaron >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Oct 23, 2012 at 3:06 PM, Patrick Hunt <[email protected]> >>>>>>>> wrote: >>>>>>>>>>>>>>> NP. here's the output. I'm on ubuntu 12.04. 1.6.0_26 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "mvn clean test" results in: (I also removed the tmp directories >>>>>>>>>>>>>>> manually, btw, we should move this to mvn target dir) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>>>>>>>> Test set: org.apache.blur.utils.TermDocIterableTest >>>>>>>>>>>>>>> >>>>>>>> ------------------------------------------------------------------------------- >>>>>>>>>>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: >>>>>>>> 0.005 >>>>>>>>>>>>>>> sec <<< FAILURE! >>>>>>>>>>>>>>> testTermDocIterable(org.apache.blur.utils.TermDocIterableTest) >>>>>>>> Time >>>>>>>>>>>>>>> elapsed: 0.005 sec <<< ERROR! >>>>>>>>>>>>>>> java.lang.NullPointerException >>>>>>>>>>>>>>> at >>>>>>>> org.apache.blur.utils.TermDocIterable.getNext(TermDocIterable.java:82) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.blur.utils.TermDocIterable.access$000(TermDocIterable.java:29) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.blur.utils.TermDocIterable$1.<init>(TermDocIterable.java:48) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.blur.utils.TermDocIterable.iterator(TermDocIterable.java:47) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.blur.utils.TermDocIterableTest.testTermDocIterable(TermDocIterableTest.java:65) >>>>>>>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>> Method) >>>>>>>>>>>>>>> at >>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>>>>>>>>>>>>> at >>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>>>>>>>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:597) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) >>>>>>>>>>>>>>> at >>>>>>>> org.junit.runners.ParentRunner.run(ParentRunner.java:236) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) >>>>>>>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>>>> Method) >>>>>>>>>>>>>>> at >>>>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>>>>>>>>>>>>> at >>>>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>>>>>>>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:597) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) >>>>>>>>>>>>>>> at >>>>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Oct 23, 2012 at 12:02 PM, Aaron McCurry < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> Sorry, just missed that message. Hmm, I will look around and >>>>>>>> try to >>>>>>>>>>>>>>>> see if I can find something. Thanks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Aaron >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Oct 23, 2012 at 2:59 PM, Patrick Hunt >>>>>>>>>>>>>>>> <[email protected]> >>>>>>>> wrote: >>>>>>>>>>>>>>>>> this is null in termdocsitertest >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> DocsEnum termDocs = atomicReader.termDocsEnum(new >>>>>>>> Term("id", >>>>>>>>>>>>>>>>> Integer.toString(id))); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> due to fields() being null in termDocsEnum method >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I don't see why yet though. Given the segment file exists on >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> filesystem, etc... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Patrick >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Oct 23, 2012 at 11:50 AM, Aaron McCurry < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> Trying to reproduce on Ubuntu. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Oct 23, 2012 at 1:58 PM, Patrick Hunt < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>> Hm, I just updated and I'm seeing two errors (which is 1 >>>>>>>>>>>>>>>>>>> less >>>>>>>> issue >>>>>>>>>>>>>>>>>>> than before): >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>> testTermDocIterable(org.apache.blur.utils.TermDocIterableTest) >>>>>>>>>>>>>>>>>>> org.apache.blur.thrift.BlurClusterTest: >>>>>>>> java.lang.NullPointerException >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Let me look and see if I can at least determine what the >>>>>>>> underlying >>>>>>>>>>>>>>>>>>> problems are. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Patrick >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Oct 23, 2012 at 10:12 AM, Aaron McCurry < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>> I ran into some errors with ZookeeperClusterStatusTest >>>>>>>>>>>>>>>>>>>> tests >>>>>>>> and have >>>>>>>>>>>>>>>>>>>> resolved the issues I found. All units tests pass on OSX, >>>>>>>>>>>>>>>>>>>> I >>>>>>>> have not >>>>>>>>>>>>>>>>>>>> had a chance to run them on Linux yet. I also fixed the >>>>>>>> nasty NPE >>>>>>>>>>>>>>>>>>>> exception on the BlurClusterTest (it was affecting the >>>>>>>> functional >>>>>>>>>>>>>>>>>>>> tests as well). I ran a few burn-in tests on a VM running >>>>>>>>>>>>>>>>>>>> a >>>>>>>> 2 >>>>>>>>>>>>>>>>>>>> controller + 3 shard server Blur cluster. The tests >>>>>>>> included loaded >>>>>>>>>>>>>>>>>>>> data as fast as possibly while running searches against >>>>>>>>>>>>>>>>>>>> that >>>>>>>> data as >>>>>>>>>>>>>>>>>>>> fast as possible. The tests ran without issue (basically >>>>>>>> like they >>>>>>>>>>>>>>>>>>>> did before the upgrade to Lucene 4). I feel like the code >>>>>>>> is in a >>>>>>>>>>>>>>>>>>>> good state at this point. I'm going to merge this code to >>>>>>>> master and >>>>>>>>>>>>>>>>>>>> create another branch to begin modifying the RPC API. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Anyone have any objections? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Aaron >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Mon, Oct 22, 2012 at 8:29 PM, Patrick Hunt < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>> On Mon, Oct 22, 2012 at 5:23 PM, Aaron McCurry < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>> Hmm. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Mon, Oct 22, 2012 at 8:17 PM, Patrick Hunt < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>>> Sounds good to me. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Not sure if anyone else is seeing this but the unit >>>>>>>>>>>>>>>>>>>>>>> tests >>>>>>>> are not >>>>>>>>>>>>>>>>>>>>>>> passing for me on ubuntu. I see one failure and two >>>>>>>> errors. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Failed tests: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> testSafeModeSetInFuture(org.apache.blur.manager.clusterstatus.ZookeeperClusterStatusTest) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Haven't seen this. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Tests in error: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> testTermDocIterable(org.apache.blur.utils.TermDocIterableTest) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> This either. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> org.apache.blur.thrift.BlurClusterTest: >>>>>>>> java.lang.NullPointerException >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I think I have been seeing this one during some >>>>>>>>>>>>>>>>>>>>>> functional >>>>>>>> tests. >>>>>>>>>>>>>>>>>>>>>> Haven't figured out the cause yet, but it seems like it's >>>>>>>> a nasty >>>>>>>>>>>>>>>>>>>>>> threading problem. Because when I drop the mutate >>>>>>>>>>>>>>>>>>>>>> threads >>>>>>>> back 1 >>>>>>>>>>>>>>>>>>>>>> everything works fine. However the test was passing on >>>>>>>> OSX. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Just me or is this expected? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Not expected. I'm going to setup a VM on computer to run >>>>>>>> tests in >>>>>>>>>>>>>>>>>>>>>> Linux as well. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Ok. Let me know how it goes and I can try and debug it a >>>>>>>> bit, although >>>>>>>>>>>>>>>>>>>>> you're running much faster than I can at this point. ;-) >>>>>>>> Definitely >>>>>>>>>>>>>>>>>>>>> let me know if you can't reproduce it and I'll dig into it >>>>>>>> for sure. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Patrick >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Patrick >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Sun, Oct 21, 2012 at 10:38 AM, Aaron McCurry < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>>>> We can fix the jira issues. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Sun, Oct 21, 2012 at 1:36 PM, Garrett Barton >>>>>>>>>>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Sounds good to me Aaron, call it 0.2. Does that mess >>>>>>>>>>>>>>>>>>>>>>>>> up >>>>>>>> Jira if you have >>>>>>>>>>>>>>>>>>>>>>>>> things scheduled against releases? >>>>>>>>>>>>>>>>>>>>>>>>> On Oct 21, 2012 9:44 AM, "Aaron McCurry" < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Ok, I think it will be some time before all the >>>>>>>> changes for the new >>>>>>>>>>>>>>>>>>>>>>>>>> api are in place and fully functional. So perhaps we >>>>>>>> should merge the >>>>>>>>>>>>>>>>>>>>>>>>>> lucene-4.0.0 branch into master and fix whatever bugs >>>>>>>> are found. I >>>>>>>>>>>>>>>>>>>>>>>>>> did some system testing yesterday and only found one >>>>>>>> big issue. There >>>>>>>>>>>>>>>>>>>>>>>>>> seems to be a threading problem with the >>>>>>>>>>>>>>>>>>>>>>>>>> BlurAnalyzer. >>>>>>>> If a single >>>>>>>>>>>>>>>>>>>>>>>>>> instance is in use across multiple threads some weird >>>>>>>> behaviors >>>>>>>>>>>>>>>>>>>>>>>>>> happen. Otherwise everything else seems to work, >>>>>>>> normally (I will >>>>>>>>>>>>>>>>>>>>>>>>>> create a jira issue). >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> If we do merge the lucene-4.0.0 branch, I feel like >>>>>>>>>>>>>>>>>>>>>>>>>> we >>>>>>>> should change >>>>>>>>>>>>>>>>>>>>>>>>>> the version to 0.2. The reason is, the indexes in >>>>>>>> 0.1.x are not going >>>>>>>>>>>>>>>>>>>>>>>>>> to be backwards compatible (at least not with out >>>>>>>>>>>>>>>>>>>>>>>>>> some >>>>>>>> work). Does >>>>>>>>>>>>>>>>>>>>>>>>>> anyone have any strong feelings on this? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Aaron >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, Oct 20, 2012 at 10:10 PM, Gagan Juneja >>>>>>>>>>>>>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> I agree with Garrett. We can merge this branch to >>>>>>>> the place from where we >>>>>>>>>>>>>>>>>>>>>>>>>>> cut it. Again as Garrett said If we want to keep >>>>>>>> only new api thing then >>>>>>>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>>>>>>>> can merge it to master as well. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>>>>>>> Gagan >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Sat, Oct 20, 2012 at 9:50 PM, Garrett Barton < >>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I guess it depends on if your planning a 1.4 >>>>>>>> release with lucene 4. If >>>>>>>>>>>>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>>>>>>>>>>>>>>> then merge and work towards making everything >>>>>>>> functional. If not then >>>>>>>>>>>>>>>>>>>>>>>>>> leave >>>>>>>>>>>>>>>>>>>>>>>>>>>> the 1.3.x in master for bug fixing or whatnot and >>>>>>>> merge this branch into >>>>>>>>>>>>>>>>>>>>>>>>>>>> the new api one. >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Oct 20, 2012 11:03 AM, "Aaron McCurry" < >>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think that we can merge the lucene-4.0.0 branch >>>>>>>> back into the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> master, since tests and code are compiling. I >>>>>>>> haven't done any >>>>>>>>>>>>>>>>>>>>>>>>>>>>> functional testing yet, but if much of the RPC >>>>>>>> and internals are going >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to change I think that it may be a waste of time >>>>>>>> to test and fix >>>>>>>>>>>>>>>>>>>>>>>>>>>>> everything that we are about to change. What do >>>>>>>> others think? >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Aaron >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>>
