at the DISABLE_LOCKS flag).
IMHO, a change that would make applet use much easier would be to add
another open method to IndexReader that takes an URL to the location
containing the index files. Given the URL, you can create a RAMDirectory and
populate it with the files in the index directory.
--Jo
encoding
shouldn't be an issue during compile.
--Jon
-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 17, 2004 7:18 AM
To: Lucene Developers List
Subject: Re: moving the analyzers into sandbox
On Aug 17, 2004, at 10:11 AM, Daniel Naber wrote:
eliminate the System.getProperty call (as in
IndexWriter). The System.getProperty calls prevent the use of Lucene as a
search engine in an unsigned applet.
Thanks,
Jon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional co
Hi folks,
This might be more apt for the User list, but here goes.
I've been trying out the new sorting capabilities from the latest CVS
build. I'm really impressed with the performance (over a single index
and multiple indices) and how easy it is to use.
But, I find when I do a sorted search
Hey all,
In the process of trying to put together a simple query rewriting
facility I came across the need to access a PrefixQuery's prefix term,
as well as a RangeQuery's field name, lower and upper terms, and
inclusivity status. Unfortunately the appropriate get methods are not
available.
Hey all,
When I switched over to Lucene 1.3 RC2 I found that a user of my
application could create an unhandled exception, just by entering in a
wild card query. (There was a post today about this [1]).
The exception being thrown when a wildcard query causes a BooleanQuery
to grow too large,
ome other
subset of HTML to get HTML?
Grrr...
> This is done by the build system, Forrest is the doc system.
Maven is both and, IMHO, that is what projects really need. It puts
everything in one place and makes things easy.
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Fol
purpose which is to enclose blocks of data. You went and
removed that and now the enclosure isn't there. Go look at Scarab and then
compare that with what you have.
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
to be built, it should be built with Maven, not
Forrest. IMHO, all Nicola is doing is trying to push his stuff in even
though it doesn't do things that are useful, like what Maven does. I'm also
pissed off that someone changed the UI. There is specific reasons why that
UI was developed and wh
or that
edge being there.
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
text search engine written in Java.
>
> Best regards,
> Feodor Fitsner
Sucks balls that your implementation is GPL.
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
See: http://www.cs.columbia.edu/~pirot/cs6111/Readings/zobel98.pdf
>
> Doug
Wow! Great response Doug. =) Learn something new every day!
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
have been thinking about lately and was
> wondering why nobody wrote it already.
>
> Otis
I think you guys are missing the point of the idea with integrating Nilsimsa
and Lucene.
Imagine that the index will be a constant size and much smaller (and faster
to search) if you simply save
Adding support to Lucene for Nilsimsa seems like a cool idea...
http://ixazon.dynip.com/~cmeclax/nilsimsa.html
The index would be the hash and one could use Lucene to rank searches based
on the Nilsimsa rating of the results...
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]&g
on 6/11/02 8:05 AM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote:
> it would be good to add that version to
> Bugzilla:
Done
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
on 6/11/02 8:05 AM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote:
> With Lucene 1.2 being out
Why isn't it on this page?
<http://jakarta.apache.org/site/binindex.html>
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
on 5/16/02 2:04 PM, "Brian Goetz" <[EMAIL PROTECTED]> wrote:
> The majority of sites have moved to 1.3, but the differences in coding
> between 1.2 and 1.3 are minor. I would suggest 1.2.
+1.2
;-)
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For
have more random/unstable development than Lucene which makes
it more of a candidate for branching.
All in all, branches with CVS are a pain in the ass. Try to avoid them.
-jon
(who works with Karl Fogel)
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
tion you get.
It is 100% valid for Lucene to create
jakarta-lucene-foo
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
user, but others are definitely questionable. I would also suggest
modifying the javacc.* properties to be a single property...the location of
the JavaCC.zip file (relative or absolute). There is really no need to have
three properties like that.
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Hey all, after all of the discussion that went on, I just want to confirm
that the build file changes that I made with regards to the properties
settings are indeed cool with everyone and that no one was overly put out by
those changes.
Any real/major complaints?
thanks,
-jon
--
To
y on Scarab...
Out of curiosity, I'm curious who that is. :-) Feel free to respond
privately.
> I can't wait to see it (I haven't yet).
Feel free to play with...
http://scarab.whichever.com
It is a runbox that is re-built from CVS head nightly.
> Better yet, when
..
> I apologize folks. I'm a firm
> believer in getting Ant usage more standardized, its just there is a lot of
> competing ways of such "standardization". Thank you Jon for enlightening me
> a bit into your reasons - it has been helpful for my own views. I actuall
jon 02/02/27 14:20:06
Removed: .build.properties
Log:
no longer needed.
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
jon 02/02/27 14:18:28
Modified:.CHANGES.txt BUILD.txt build.xml
Added: .default.properties
Log:
implemented what i proposed on the mailing list with regards
to having a default.properties define the properties and
allow people to define their own
her. I gave my response to Dmitry's posting, lets wait for
his response.
p.s. Double negatives are not very clear. Either vote +1 or -1.
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
ined. I also already voted -1 towards having a
build.properties.sample as well as storing default properties in the
build.xml. Are people overlooking that vote now? Yes, I'm more than happy to
also provide a patch and do the
on 2/26/02 8:23 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
> The argument of needing both a build.xml and default.properties doesn't
> really fly with me. The user shouldn't even have to look at the build.xml
> *ever*.
>
> -jon
I liken reading
le.
The argument of needing both a build.xml and default.properties doesn't
really fly with me. The user shouldn't even have to look at the build.xml
*ever*.
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
If you have the properties both in build.properties.sample and build.xml,
then it is two places that you have to maintain them in.
-jon
on 2/26/02 6:02 PM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote:
> They would not have to rename files to make things work... all the
> p
les in order to make things work
and the 'default' properties don't clutter up the build.xml file.
Thanks,
-jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
on 10/22/01 10:51 AM, "Doug Cutting" <[EMAIL PROTECTED]> wrote:
>> From: Jon Stevens [mailto:[EMAIL PROTECTED]]
>>
>>> -version=1.2-rc1
>>> +version=1.2-dev
>>
>> I don't think that you should go back a version. It can
>> c
on 10/19/01 10:15 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> -version=1.2-rc1
> +version=1.2-dev
Doug,
I don't think that you should go back a version. It can confuse people. It
should be 1.2.1-dev.
-jon
on 10/1/01 5:54 PM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote:
> Except for Cc cases which forces you to create two filters when you use
> some email readers, of course. :)
> I'd +1 it.
>
> Otis
Not unless you have a decent email client that will filter on both at the
same time. :-)
-jon
much better to filter on the To: line.
-jon
on 9/28/01 1:47 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> - removed ego-boosting 'backgrond' section
Funny. I didn't mind that...
Credit for your hard work is most important.
-jon
on 9/27/01 2:22 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:
> http://nagoya.apache.org/bugzilla/
>
> We need to get Pier to set that up.
Nope. I can do it.
Done.
-jon
on 9/27/01 1:46 PM, "Scott Ganyo" <[EMAIL PROTECTED]> wrote:
> Sorry about the HTML. It seems to be the default in Outlook. I'll try to
> remember to post without it...
You are still doing it.
Please read:
<http://jakarta.apache.org/site/mail.html>
-jon
on 9/24/01 2:52 PM, "Doug Cutting" <[EMAIL PROTECTED]> wrote:
> I think we should 'cvs rm' all of the files, and change the README to point
> to Jakarta. Does that sound reasonable?
>
> Doug
Don't do that. It will serve as the repo for the old history of the changes.
-jon
39 matches
Mail list logo
