Mailing-List: contact user-help@lucenenet.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@lucenenet.apache.org
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_0AA40C2B-68D1-4135-B268-248E4CAC8FB5"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Subject: Re: Source not in solution
From: Kent Boogaart <kent.boogaart@gmail.com>
In-Reply-To: <563DAB75.40102@devhost.se>
Date: Sat, 7 Nov 2015 22:27:17 +1030
Cc: user@lucenenet.apache.org
Message-Id: <2A2DAD86-B221-425E-BFD8-985DF9D1F63E@gmail.com>
References: <A6F25884-AE13-4FDA-A715-7D802C9D6270@gmail.com>
 <3EB0517A-EB03-4CE4-B3B8-A417D47153AB@gmail.com> <563DAB75.40102@devhost.se>
To: Simon Svensson <sisve@devhost.se>

--Apple-Mail=_0AA40C2B-68D1-4135-B268-248E4CAC8FB5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks Simon.

So, just to be clear, there are no usable branches of Lucene.NET post =
3.0.x? I was assuming there was something usable because of this post: =
http://stackoverflow.com/a/24897255/1228288, wherein Peter Bailey says =
be has used a later build to avoid the spurious exceptions I mentioned =
in point #1.

Assuming there is nothing post 3.0.x I can use, my recourse here will be =
to simply use the project as is and debug it to try to determine why =
I=E2=80=99m getting the second issue. I can live with the first-chance =
exceptions, but the second issue is a blocker.

FWIW, the changes I needed to make to the core project to get it to =
build for iOS were all to do with AppSettings, because =
ConfigurationManager simply doesn=E2=80=99t exist. Consequently, there =
are some knock-on changes to Contants.cs and StringHelper.cs. One other =
thing I had to do when I was using that project was to manually add the =
snowball analyzer in, since it was omitted.

Cheers,
Kent

> On 7 Nov 2015, at 6:12 PM, Simon Svensson <sisve@devhost.se> wrote:
>=20
> Hi Kent,
>=20
> Based on the core/Util/Version.cs of chrigu-ebert/Xamarin-Lucene, it's
> version 3.0.x. The latest stable version of Lucene.Net =
<http://lucene.net/> is 3.0.3, so his
> sources seem correct. (I have, however, issues with his non-documented
> approach to modifying the source code. Are these changes that perhaps
> could go back to the real Lucene.Net <http://lucene.net/> source?)
>=20
> There are no newer stable code for you to use. I presume you tried the
> master branch of apache/lucenenet, but it's currently an in-progress
> port of Lucene 4.8 and is in no ways complete.
>=20
> The MultiFieldQueryParser (and the QueryParser) are not longer present
> in the core, but moved to the [java-package
> org.apache.lucene.queryparser.classic][1]. This means that we'll have =
in
> a separate project once it's ported, but there is to timeline for =
that.
>=20
> // Simon
>=20
> [1]:
> =
https://lucene.apache.org/core/4_8_1/queryparser/org/apache/lucene/querypa=
rser/classic/package-summary.html =
<https://lucene.apache.org/core/4_8_1/queryparser/org/apache/lucene/queryp=
arser/classic/package-summary.html>
>=20
> On 07/11/15 07:50, Kent Boogaart wrote:
>> OK, I=E2=80=99ve changed tact. I=E2=80=99m instead building the =
Lucene.Net source
>> whilst targeting Xamarin platforms.
>>=20
>> I can get the core project to build with a few minor changes.
>> However, the Lucene.Net solution appears to be completely missing
>> MultiFieldQueryParser. Where has this gone? Can anyone please
>> enlighten me - I=E2=80=99m struggling to reconcile the state of this =
project
>> against the Javadocs for Lucene itself (which shows that
>> MultiFieldQueryParser is still a thing).
>>=20
>> Thanks, Kent
>>=20
>>> On 7 Nov 2015, at 11:06 AM, Kent Boogaart <kent.boogaart@gmail.com>
>>> wrote:
>>>=20
>>> Hi,
>>>=20
>>> I=E2=80=99m using Lucene from a mobile app (using Xamarin) via this
>>> project: https://github.com/chrigu-ebert/Xamarin-Lucene.Net
>>> <https://github.com/chrigu-ebert/Xamarin-Lucene.Net =
<https://github.com/chrigu-ebert/Xamarin-Lucene.Net>>
>>>=20
>>> However, I would like to upgrade to a more recent Lucene.NET =
<http://lucene.net/>
>>> <http://lucene.net/ <http://lucene.net/>> to address two issues I =
have. Briefly, the two
>>> issues I have are:
>>>=20
>>> 1. First-chance exceptions are raised on every search, such as
>>> =E2=80=9CIOException: read past eof=E2=80=9D and =
=E2=80=9CLookaheadSuccess: Error in the
>>> application=E2=80=9D 2. On a brand new install of my app, the first =
attempt
>>> to search results in an exception: "System.IO.IOException: Invalid
>>> handle to path
>>> =
"/private/var/mobile/Containers/Bundle/Application/EDDBC7B3-E54E-46CC-BC51=
-0CDE18A066F4/my.app/[Unknown]=E2=80=9D=E2=80=9D
>>>=20
>>>=20
>>>=20
> My understanding is that later versions of Lucene.NET =
<http://lucene.net/>
> <http://lucene.net/ <http://lucene.net/>> have addressed #1. By =
upgrading I hope to also
> address #2, though even if I don=E2=80=99t I will be in a good =
position to look
> deeper into the matter.
>>>=20
>>> As a starting point, I forked the Xamarin Lucene.NET =
<http://lucene.net/>
>>> <http://lucene.net/ <http://lucene.net/>> project, cloned Lucene.NET =
<http://lucene.net/>
>>> <http://lucene.net/ <http://lucene.net/>>, and wrote a little script =
to copy like-named
>>> files from the Lucene.NET <http://lucene.net/> <http://lucene.net/ =
<http://lucene.net/>> source to the
>>> Xamarin Lucene.NET <http://lucene.net/> <http://lucene.net/ =
<http://lucene.net/>> source. Catastrophe!
>>>=20
>>> It became evident that there are a lot of files in the Lucene.NET =
<http://lucene.net/>
>>> <http://lucene.net/ <http://lucene.net/>> code base that aren=E2=80=99=
t even part of the main
>>> solution. I=E2=80=99m trying to understand why this is.
>>>=20
>>> An example of such a file is StopwordAnalyzerBase.cs. It resides
>>> under src\Lucene.Net.Analysis.Common\Analysis\Util, so going by the
>>> readme it should be part of the core code base. However, it is not
>>> present in the solution.
>>>=20
>>> Can anyone tell me why this is?
>>>=20
>>> Thanks, Kent


--Apple-Mail=_0AA40C2B-68D1-4135-B268-248E4CAC8FB5--