incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: [VOTE] Merge lucene-4.0.0 branch to master
Date Thu, 25 Oct 2012 16:42:37 GMT
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 <amccurry@gmail.com> 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 <phunt@apache.org> 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 <amccurry@gmail.com> wrote:
>>> +1
>>>
>>> Sent from my iPhone
>>>
>>> On Oct 24, 2012, at 4:40 PM, Patrick Hunt <phunt@apache.org> 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 <amccurry@gmail.com>
wrote:
>>>>> +1 on this solution.
>>>>>
>>>>> On Wed, Oct 24, 2012 at 2:24 PM, Patrick Hunt <phunt@apache.org>
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
>>>>>> <gagandeepjuneja@gmail.com> wrote:
>>>>>>> Oops! I missed Patrick's last post.
>>>>>>>
>>>>>>> On Wed, Oct 24, 2012 at 12:07 PM, Gagan Juneja <gagandeepjuneja@gmail.com>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 <phunt@apache.org>
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.&lt;init&gt;(MiniDFSCluster.java:280)
>>>>>>>>>        at
>>>>>>>>> org.apache.hadoop.hdfs.MiniDFSCluster.&lt;init&gt;(MiniDFSCluster.java:124)
>>>>>>>>>
>>>>>>>>> Patrick
>>>>>>>>>
>>>>>>>>> On Tue, Oct 23, 2012 at 2:43 PM, Patrick Hunt <phunt@apache.org>
wrote:
>>>>>>>>>> I pushed a small cleanup to versioning in the poms.
>>>>>>>>>>
>>>>>>>>>> Patrick
>>>>>>>>>>
>>>>>>>>>> On Tue, Oct 23, 2012 at 2:38 PM, Patrick Hunt <phunt@apache.org>
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
<amccurry@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>> Hmm, I will take a look at that one next.
>>>>>>>>>>>>
>>>>>>>>>>>> Aaron
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Oct 23, 2012 at 5:20 PM, Patrick
Hunt <phunt@apache.org>
>>>>>>>>> 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 <amccurry@gmail.com>
>>>>>>>>> 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 <amccurry@gmail.com>
>>>>>>>>> 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 <phunt@apache.org>
>>>>>>>>> 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 <
>>>>>>>>> amccurry@gmail.com> 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 <phunt@apache.org>
>>>>>>>>> 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 <
>>>>>>>>> amccurry@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>> Trying to reproduce
on Ubuntu.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Tue, Oct 23,
2012 at 1:58 PM, Patrick Hunt <
>>>>>>>>> phunt@apache.org> 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 <
>>>>>>>>> amccurry@gmail.com> 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 <
>>>>>>>>> phunt@apache.org> wrote:
>>>>>>>>>>>>>>>>>>>>>> On
Mon, Oct 22, 2012 at 5:23 PM, Aaron McCurry <
>>>>>>>>> amccurry@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
Hmm.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
On Mon, Oct 22, 2012 at 8:17 PM, Patrick Hunt <
>>>>>>>>> phunt@apache.org> 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 <
>>>>>>>>> amccurry@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
We can fix the jira issues.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
On Sun, Oct 21, 2012 at 1:36 PM, Garrett Barton
>>>>>>>>>>>>>>>>>>>>>>>>>
<garrett.barton@gmail.com> 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" <
>>>>>>>>> amccurry@gmail.com> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>
<gagandeepjuneja@gmail.com> 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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>
garrett.barton@gmail.com>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" <
>>>>>>>>> amccurry@gmail.com> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>

Mime
View raw message