Back to the original question. Can I go ahead and merge lucene-4.0.0 to master? I feel like we can work the testing issues as we go.
Aaron On Thu, Oct 25, 2012 at 12:42 PM, Patrick Hunt <[email protected]> wrote: > If you follow maven conventions it's not too bad. We probably will > have to move things around a bit. Basically small updates to the pom > and define an assembly descriptor that specifies what goes where. Here > are a few links with background: > > https://maven.apache.org/plugins/maven-assembly-plugin/ > http://www.petrikainulainen.net/programming/tips-and-tricks/creating-a-runnable-binary-distribution-with-maven-assembly-plugin/ > > Take a look at what we did for Apache Whirr - there are two > assemblies, one for the source artifact and one for the binary: > http://svn.apache.org/repos/asf/whirr/trunk/build-tools/src/ > the results of which you can see here: > http://apache.mirrors.pair.com/whirr/whirr-0.8.1/ > > I can take a whack on a separate branch if you like. Once master is updated. > > Patrick > > On Thu, Oct 25, 2012 at 9:12 AM, Aaron McCurry <[email protected]> wrote: >> 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>
