On Mar 1, 2005, at 12:50 PM, Doug Cutting wrote:
Henri Yandell wrote:
Redirect of jakarta.apache.org/lucene to
lucene.apache.org/java/docs/index.html
I noticed there's a commented out redirect in the .htaccess, so after
adding my own I deleted it again and left the redirect off for the
moment.
Kevin,
Why bother arguing such petty stuff? getters/setters, as awkward and
verbose as they may be, is how its done in Java land. There is no
benefit to making it non-final over using getters/setters. The LOC
argument is silly too - we're not counting LOC or anything. Let's keep
focused on
Commits now send to [EMAIL PROTECTED] - both lucene4c and
lucene (Java) are sent to this address currently. To subscribe, mail
to:
[EMAIL PROTECTED]
Erik
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: February 27, 2005 3:22:58 PM EST
To: [EMAIL PROTECTED]
Subject: svn commit:
, but
as things progress with your lucene4c it would be great to start
fleshing out some common compatibility/performance tests and metrics.
We might want a /common/trunk for that though.
Erik
On Feb 27, 2005, at 6:39 PM, Garrett Rooney wrote:
Erik Hatcher wrote:
I'm not sure
On Feb 28, 2005, at 10:01 AM, [EMAIL PROTECTED] wrote:
Hello,
I would like to build a search engine using several different
languages -
f.e. Spanish names, French names, ...
Will your text be a mix of languages within a single field? Or would
each document (or field) be a single language?
-
I'm gun shy for forging ahead without community consensus based on me
pushing too fast earlier. I'm +1 on forging ahead with all of what
Henri brings up.
Doug? Others?
As Henri mentions, we need a mail and download page added to the Lucene
website since this will be removed from the Jakarta
There is a pending JIRA issue for Lucene e-mail lists here:
http://issues.apache.org/jira/browse/INFRA-195
Please adjust it and prod infrastructure when agreement is made on the
lists. I prefer a single commits list for now, but no problem if the
consensus is to separate them.
I'm not sure if this is the best way to do it (Garrett?), but I created
a /trunk top-level directory with svn:externals pointing to trunk of
both java and lucene4c. The drawback is that its https, which means
only committers would be able to use it. Is there a better way to do
this?
On Feb 26, 2005, at 11:56 AM, Garrett Rooney wrote:
Commit mails are currently going to [EMAIL PROTECTED]
(although the initial import mail bounced due to the size of the
mail), so we should decide if that's where they should stay (that's
what Justin recommends), or if we want separate commits
You have to use https for commits. Perhaps re-checkout completely with
https first, though an svn switch might do the trick also.
Erik
On Feb 26, 2005, at 4:13 PM, Otis Gospodnetic wrote:
Hello,
Just tried committing Paul's Javadoc changes and got this error:
svn: Commit failed
On Feb 26, 2005, at 8:26 PM, Garrett Rooney wrote:
Erik Hatcher wrote:
On Feb 26, 2005, at 11:56 AM, Garrett Rooney wrote:
Commit mails are currently going to [EMAIL PROTECTED]
(although the initial import mail bounced due to the size of the
mail), so we should decide if that's where they should
On Feb 25, 2005, at 3:21 AM, Kevin A. Burton wrote:
Yet another patch.
Please post your patches to Bugzilla once your implementation has been
agreed upon.
Erik
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
On Feb 23, 2005, at 12:06 PM, Doug Cutting wrote:
[EMAIL PROTECTED] wrote:
Log:
fix broken links to source
-nbsp;a
href=../../src/demo/org/apache/lucene/demo/
FileDocument.javaFileDocument.java/a contains
+nbsp;a
href=http://svn.apache.org/repos/asf/lucene/java/trunk/src/demo/org/
Reporter: Erik Hatcher
Priority: Minor
The Lucene team would like the issue tracker converted to JIRA
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you
Looks like the issue has been resolved with the lucene.apache.org DNS.
Erik
Begin forwarded message:
From: Ask Bjørn Hansen [EMAIL PROTECTED]
Date: February 20, 2005 9:34:50 PM EST
To: Noel J. Bergman [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], Erik Hatcher [EMAIL PROTECTED]
Subject: Re
Yes, I'm also experiencing spotty DNS issues with lucene.apache.org - I
can browse to it through the web, but my e-mail server cannot send to
the new e-mail lists (for svn commits and PMC only right now).
Shouldn't DNS updates be quicker than this? It's been a week since it
was set up.
I've forwarded this on to Apache infrastructure. I asked about this
once before and the response was to be patient and let things propagate
- though something is amiss.
Erik
On Feb 20, 2005, at 10:00 AM, John Haxby wrote:
Erik Hatcher wrote:
Yes, I'm also experiencing spotty DNS issues
it, the Incubator PMC will help you figure out exactly what
needs to be done and will then vote on graduation.
Hope that helps.
Cliff
On Monday, February 14, 2005 10:58 AM, Erik Hatcher wrote:
On Feb 14, 2005, at 12:36 PM, Geir Magnusson Jr wrote:
On Feb 14, 2005, at 10:23 AM, Jim Jagielski wrote:
All
apache sponsoring individual
Erik Hatcher, Doug Cutting, and Otis Gospodnetic.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
On Feb 17, 2005, at 5:13 PM, Mario Alejandro M. wrote:
In wonder if the .NET ports around have implemente classes that are
only mirrors of the Java and not are necesary for a sucesfully port to
.NET is this true?
I don't quite understand your question, but the dotLucene project at
Sourceforge
On Feb 13, 2005, at 11:37 PM, Otis Gospodnetic wrote:
I was going to wait a bit with inviting various Lucene ports to Lucene
until we have the mailing lists set up and at lucene.apache.org, to
make things a bit more tangible for people.
Since these codebase imports have to come through incubation,
We now have lucene.apache.org mapped, yet we don't have a site there
yet.
Doug - do you have your Forest work handy? Or has anyone else stepped
up to build the web site?
I'll try later today to get our current site up at the new domain to
have a starting point.
Erik
Begin
and
that it was easy to get up and running with it.
Erik
k
On Mon, 14 Feb 2005 07:37:38 -0500, Erik Hatcher wrote:
We now have lucene.apache.org mapped, yet we don't have a site
there yet.
Doug - do you have your Forest work handy? Or has anyone else
stepped up to build the web site
not taken effect for you.
Erik
On Feb 14, 2005, at 7:37 AM, Erik Hatcher wrote:
We now have lucene.apache.org mapped, yet we don't have a site there
yet.
Doug - do you have your Forest work handy? Or has anyone else stepped
up to build the web site?
I'll try later today to get our
On Feb 14, 2005, at 12:24 PM, Doug Cutting wrote:
Otis Gospodnetic wrote:
lucene.apache.org seems to work now.
Here is the query syntax:
http://lucene.apache.org/queryparsersyntax.html
We should be cautious in promoting lucene.apache.org urls until we
have this structured correctly. Let's
On Feb 14, 2005, at 12:39 PM, Garrett Rooney wrote:
Doug Cutting wrote:
Garrett Rooney wrote:
Agreed. Java Lucene is a subproject of the Lucene TLP, leaving the
existing Java Lucene site there for the time being seems ok, just so
we have something there, but we should endeavour to put up
On Feb 14, 2005, at 12:36 PM, Doug Cutting wrote:
Garrett Rooney wrote:
Agreed. Java Lucene is a subproject of the Lucene TLP, leaving the
existing Java Lucene site there for the time being seems ok, just so
we have something there, but we should endeavour to put up something
more permanent
I have updated the redirects a bit more and the old /docs links now
redirect to the corresponding spot on lucene.apache.org/java/docs.
Let me know if there are any old links not redirecting appropriately.
I changed things down one level from where Doug checked them out. So
its now
On Feb 14, 2005, at 1:53 PM, Doug Cutting wrote:
Erik Hatcher wrote:
I'm really at the limit of my bandwidth - I've got the sandbox
restructuring effort on my plate right now and would like it if
someone could pick up the ball on the web site side of things.
Then perhaps you shouldn't have
On Feb 14, 2005, at 2:21 PM, Doug Cutting wrote:
Doug Cutting wrote:
And we also want to try not to break URLs when we move things. For
this reason it's best to move things as few tims as possible, so that
we don't end up with a confusing set of redirects.
More to the point, we also want to try
On Feb 14, 2005, at 2:33 PM, Doug Cutting wrote:
Bernhard Messer wrote:
Doug, you placed a copy of the website in the java directory. In
both, the original and the java directory the api directory is
missing. I can't copy it into because of the access rights :-(
Argh. The group protection is
On Feb 14, 2005, at 3:10 PM, Bernhard Messer wrote:
U, the whole damed thing at http://lucene.apache.org is not
responding any longer
I've seen that too it worked fine for a while, and then no longer.
I thought it might be a temporary DNS thing.
Erik
On Feb 14, 2005, at 4:12 PM, Bernhard Messer wrote:
It seems that everything is fine now with the website :-)
I noticed the /java/docs/api area is fine too now that the DNS seems to
be working again.
Just let me know when you're ok with me turning the redirect back on
from jakarta.
On Feb 13, 2005, at 12:58 PM, Garrett Rooney wrote:
Does your code warrant incubation? Or could it go right into
Lucene's repository?
I'm not really sure what the proper course of action is, but after a
quick look at the incubator documentation, it seems like the primary
way projects are
On Feb 11, 2005, at 9:04 AM, Vanlerberghe, Luc wrote:
Here's the diff for the TestCase 'inline'.
It should be applied in
contrib\analyzers\src\test\org\apache\lucene\analysis
The failure in the Russian Analyzer is unrelated (I updated all sources
to HEAD i.e. 153399 to be sure) but you probably
On Feb 11, 2005, at 11:19 AM, Vanlerberghe, Luc wrote:
I'm suspecting subversion now: the stemsUnicode.txt and
wordsUnicode.txt
files are encoded in UTF-16 (they have the proper two byte byte-order
prefix) and have property svn:eol-style set to native.
On my (Windows :( )system the files are
On Feb 8, 2005, at 8:30 AM, HariSankar wrote:
Im using Lucene to search a Text file thats basically a database file
with @ as a separator. When i give a search for the expression $20,
it fetches me results for @20 as well. How do i supress this ?
You have a bad case of Analysis Paralysis:
On Feb 7, 2005, at 1:21 AM, David Spencer wrote:
Erik Hatcher wrote:
XML-Indexing-Demo - I propose this be moved to an examples area if
we keep it at all.
parsers - Is anyone using the PDF parser here?
taglib - my bad in committing this in the first place - its not well
implemented
I know Doug wrote Lucene with emacs. But I prefer an IDE where I can
surf around the codebase, and many of the other Lucene committers may
also. So here is your chance to get IDEA for free:
http://www.jetbrains.com/idea/opensource/
version). Those of us used to
Eclipse see no need to change, and those using IntelliJ,
well, something about ripping objects from cold dead
hands...
Jack
On Mon, 7 Feb 2005 14:30:07 -0500
Erik Hatcher [EMAIL PROTECTED] wrote:
I know Doug wrote Lucene with emacs. But I prefer an IDE
where I can
Is the SearchBean code in the Sandbox still useful now that we have
sorting in Lucene 1.4? If so, what does it offer that the core does
not provide now?
As I'm cleaning up the sandbox and migrating it to a contrib area,
I'm evaluating the pieces and making sure it makes sense to keep or if
XML-Indexing-Demo - I propose this be moved to an examples area if we
keep it at all.
parsers - Is anyone using the PDF parser here?
taglib - my bad in committing this in the first place - its not well
implemented and of marginal use. I propose to remove it entirely.
miscellaneous - I propose
+1
I volunteer to tackle the initial restructuring (piecemeal over the
next few weeks), unless someone is more eager to hop on it.
Also, we should package a lucene-XX-all.zip/.tar.gz that includes all
the contrib pieces also allowing someone to simply download Lucene and
all the packaged
On Feb 4, 2005, at 4:59 PM, Doug Cutting wrote:
Erik Hatcher wrote:
Also, we should package a lucene-XX-all.zip/.tar.gz that includes all
the contrib pieces also allowing someone to simply download Lucene
and all the packaged contrib pieces at once.
I'll go further: that should be the only
On Feb 1, 2005, at 10:43 PM, Doug Cutting wrote:
Erik Hatcher wrote:
On Feb 1, 2005, at 3:13 PM, Doug Cutting wrote:
I think we want Java Lucene to be a sub-project of Lucene. So the
repository should be something like:
https://svn.apache.org/repos/asf/lucene/java
I already put in the request
We're doing a migration from CVS to Subversion today. Please refrain
from committing to either jakarta-lucene and jakarta-lucene-sandbox.
Hopefully we'll be back in business on Subversion soon - I'll keep the
dev list posted.
Erik
The conversion to Subversion is complete. The new repository is
available to users read-only at:
http://svn.apache.org/repos/asf/lucene/java/trunk
Besides /trunk, there is also /branches and /tags. /tags contains all
the CVS tags made so that you could grab a snapshot of a previous
On Feb 1, 2005, at 3:13 PM, Doug Cutting wrote:
I propose we simply import our two CVS repositories in with all of
jakarata-lucene as the root of the repository and
jakarta-lucene-sandbox under sandbox in the root. We can shuffle
things around once we get it all into svn using svn move nicely.
On Jan 23, 2005, at 7:18 AM, Daniel Naber wrote:
On Sunday 23 January 2005 13:04, Erik Hatcher wrote:
I have gotten lucli to work fine by putting the additional JAR files
on
the CLASSPATH.
When I try to start it with java -jar lucli-dev.jar it seems to
ignore
the CLASSPATH. Also the -cp option
On Jan 23, 2005, at 6:46 AM, Daniel Naber wrote:
On Sunday 23 January 2005 12:12, [EMAIL PROTECTED] wrote:
make the jar less broken -- however, it still requires a lib dir
with lucene.jar and libreadline-java.jar
Calling ant in contributions/lucli built a jar file that didn't
work. I
tried to
Looks like we should consider alternate names. Suggestions??
Begin forwarded message:
From: Justin Erenkrantz [EMAIL PROTECTED]
Date: January 14, 2005 1:15:38 PM EST
To: [EMAIL PROTECTED], Jakarta Project Management Committee List
[EMAIL PROTECTED]
Subject: Re: [PROPOSAL] Lucene to
Can anyone comment on Joshua Bloch's involvement with Lucene's codebase
and the issue Sam brings up below??
This came up as a side topic to my proposal to the Jakarta PMC of bring
Lucene to the top-level.
Erik
Begin forwarded message:
From: Sam Ruby [EMAIL PROTECTED]
... here's a
I was e-mailed offline with a link that pointed to the Arrays.java code
in Lucene 1.3. In fact, *I'm* the one that removed that file over a
year ago because it was unused. So I think we're in good shape.
Erik
Begin forwarded message:
From: Erik Hatcher [EMAIL PROTECTED]
Date
The questions still remain, though, and lawyers do want to know the
answers:
- How did JDK code get into Lucene's codebase to begin with?
- Is there any more lingering?
Doug? Anyone?
Erik
On Jan 14, 2005, at 2:36 PM, Erik Hatcher wrote:
I was e-mailed offline with a link that pointed
Or use IndexReader and find the document id's that contain the term
you're avoiding, then access all the documents but those.
Erik
On Jan 4, 2005, at 1:39 PM, Scott Ganyo wrote:
Nope, that's the way to do it.
S
On Jan 4, 2005, at 11:53 AM, George Aroush wrote:
Hi folks,
In Lucene, how
On Dec 31, 2004, at 7:19 AM, Daniel Naber wrote:
Then basically my whole faq to wiki conversion was wasted time, as
we'll
have two FAQs again? That was the reason to move to the wiki: avoid
useless content duplication. Maybe jGuru should convert its FAQ to a
real
forum.
It wasn't wasted time at
On Dec 30, 2004, at 4:53 PM, Daniel Naber wrote:
On Tuesday 21 December 2004 21:09, Otis Gospodnetic wrote:
Hm, mailing list sw doesn't like messages 100K in size nor ZIP
attachments. I'm sending the FAQ to Daniel directly.
As all FAQ items from the jGuru FAQ are now copied to the new FAQ, is
it
On Dec 20, 2004, at 9:43 PM, Otis Gospodnetic wrote:
Sounds ok to me. There is no mention of Nutch, though. If Nutch is
going through Incubator with its own proposal, maybe we need to say
that.
Let's give time developers in other time zones to add themselves to the
list.
Sam Ruby recommended
On Dec 19, 2004, at 8:37 PM, Otis Gospodnetic wrote:
OK.
Is this _really_ what everyone's okay with? I'm asking because once we
put the FAQ onto Wiki we:
1. no longer have authoritative FAQ - anyone can write to the FAQ
2. we have to monitor the Wiki FAQ for correctness
3. we have no
,
hence my double-checking with lucene-dev people.
I'm still unsure about the best setup, so I'll wait a little longer to
hear some more opinions.
Otis
--- Erik Hatcher [EMAIL PROTECTED] wrote:
On Dec 19, 2004, at 8:37 PM, Otis Gospodnetic wrote:
OK.
Is this _really_ what everyone's okay with? I'm asking
I created a draft proposal here:
http://wiki.apache.org/jakarta-lucene/TopLevelProposal
I placed Doug as Chair and the committers I could see handy in my
Lucene e-mail folder as initial PMC members. Committers - feel free to
add or remove yourself from that list. Henri - do you want to
+1
Would we convert the jakarta-lucene-sandbox separately also? Or
Somehow merge it into a single SVN repository? We have different
committers to each repository.
Erik
On Dec 18, 2004, at 11:19 PM, Henri Yandell wrote:
(Just your friendly neighbourhood nudge)
I think it would be a
You cannot override static methods - this is how Java works. You can
override any of the non-static (and non-final) methods.
Erik
On Dec 17, 2004, at 1:02 PM, Dan Climan wrote:
Thanks for pointing out the error in my originally proposed solution
to the
question of overriding encodeNorm
A further logo request would be to chop it into L, u, and cene
with some matching left and right arrows so we can put it on a web page
like this:
L u u u u u u cene
for search results.
Erik
-
To unsubscribe,
On Dec 11, 2004, at 9:54 AM, Bernhard Messer wrote:
Currently i'm not able to see how much adminitrative work this will
raise. Are there any known apache projects already moved from a
subproject to TLP ? Maybe they could give us some important hints what
effort will come over the community.
On Dec 12, 2004, at 6:36 PM, Kevin A. Burton wrote:
Erik Hatcher wrote:
Nutch is a full-web crawler built, by Doug, using Lucene indexes
under the covers. Organizationally, Nutch is under a Apache
compatible license. I don't believe any committers, other than Doug,
overlap though. We would
The Lucene in Action e-book is now available at Manning's site:
http://www.manning.com/hatcher2
Manning also put lots of other goodies there, the table of contents,
about this book, preface, the foreward from Doug Cutting himself
(thanks Doug!!!), and a couple of sample chapters. The
The idea of creating a new top-level Apache project, namely
search.apache.org, has been floating around for a while. The idea is
to bring Lucene under this new umbrella, along with incubating Nutch
through the standard Apache incubation process with it aimed at coming
under this same
On Dec 10, 2004, at 4:10 PM, Terry Steichen wrote:
Regarding Nutch, I gather it uses the standard Lucene library? I keep
seeing references on this (or maybe it's the users') list suggesting
people might find some answers to some of their questions by examining
the Nutch code. Might there be
On Dec 10, 2004, at 3:27 PM, Terry Steichen wrote:
Forgive me for asking a stupid question, but why?
Ah, excellent question that I should have addressed in my first message.
Bringing Lucene under a top-level project would allow us to eventually
bring the other Lucene ports that choose to Apache
To address the issue Bill just brought up, I refer you to the
documentation of the Ant jar task. Check out the filesetmanifest
attribute options:
http://ant.apache.org/manual/CoreTasks/jar.html
I have not yet tried this relatively new (as of Ant 1.6, since we
didn't write about it in
First let me demonstrate an issue. I'm currently using QueryParser
with AND as the default operator for one type of user query. For
another type of user query I create an OR'd BooleanQuery
programatically.
I want all queries, regardless of how they were created, to be
converted back into a
On Dec 9, 2004, at 8:44 AM, Murray Altheim wrote:
Erik Hatcher wrote:
First let me demonstrate an issue. I'm currently using QueryParser
with AND as the default operator for one type of user query. For
another type of user query I create an OR'd BooleanQuery
programatically.
I want all
On Dec 9, 2004, at 8:34 AM, Erik Hatcher wrote:
First let me demonstrate an issue. I'm currently using QueryParser
with AND as the default operator for one type of user query. For
another type of user query I create an OR'd BooleanQuery
programatically.
I want all queries, regardless of how
On Dec 8, 2004, at 4:24 AM, John Haxby wrote:
Otis Gospodnetic wrote:
Any such custom hack requires maintenance, even
if it's auto-generated.
The corollary of which is that if the version number is in two places,
one of them will be wrong.
And this is what I've been alluding to. DRY is a
On Dec 8, 2004, at 6:58 AM, Andrzej Bialecki wrote:
Erik Hatcher wrote:
And this is what I've been alluding to. DRY is a principle I
strongly subscribe to - Don't Repeat Yourself.
You don't have to repeat yourself. You can put version numbers in only
one place - in the build.xml. Then write
On Dec 6, 2004, at 10:39 PM, Jeff Breidenbach wrote:
The first is that there is no way to tell from inside Java which
version of Lucene you have. There should be some top level class,
perhaps org.apache.lucene.VERSION, which contains at least three
variables, majorVersion, minorVersion, and
Pasha already broke the news, but here's my official announcement.
The source code distribution to the long-awaited Lucene in Action book
is now available for download. You'll find it at:
http://www.manning.com/hatcher2
Navigate to the Source Code link on the left to get to the download
On Dec 7, 2004, at 12:42 PM, Bill Janssen wrote:
We could easily store the version number in a Java static variable
somewhere, but let's first explore whether the manifest information is
sufficient.
Will this work in the face of re-packaging? For instance, suppose I
unpack the class files from
On Dec 7, 2004, at 8:02 PM, Bill Janssen wrote:
Incidentally, when I look at the 1.4.1 jarfile MANIFEST.MF, I see the
following line:
Implementation-Vemdpr: Lucene
Is that spelling of Vemdpr intentional?
I was staring at the MANIFEST.MF file all morning and missed that typo.
It is fixed in CVS
On Dec 7, 2004, at 7:42 PM, Bill Janssen wrote:
So if we keep the Lucene version in only the packaging of the jar
file, we have a source of end-user error and fragility in two ways:
(1) the manifest file may not be available (the class files may be
re-packaged in another app which didn't know to
On Dec 7, 2004, at 8:37 PM, Bill Janssen wrote:
This incredibly fragile bit of code should work for existing jar
files, but good grief!
So we hide this behind a utility method and no one needs to see any
ugliness at all :)
Erik
---
import
On Dec 1, 2004, at 5:16 AM, Christoph Goller wrote:
Doug, could you please move api/ to api.old/ and api.new/ to api/
I haven't heard back from infrastructure on this issue (did my message
make it to that list?).
Christoph - one remaining task before officially announcing Lucene
1.4.3 is to
On Dec 6, 2004, at 5:36 PM, Henri Yandell wrote:
With a developer hat on; it'd be cool to use the Wiki as a database
but write a dynamic front-end that reformatted the wiki page to put
together a much nicer interface (like the lucene.sf.net one).
I second Henri's suggestion to use the wiki -
On Dec 6, 2004, at 3:30 PM, Daniel Naber wrote:
http://jakarta.apache.org/site/binindex.cgi
http://jakarta.apache.org/site/sourceindex.cgi
I tried to update those pages but I get an pre-commit check error on
commit -- I assume I simply don't have permission to commit there. So
Infrastructure - we have an issue with directory permissions in doing a
website update to Jakarta Lucene. The details are described below.
Could you fix this so that Christoph can publish things properly? How
do we arrange the permissions so that any Lucene committer may update
the site?
On Nov 30, 2004, at 10:42 AM, Ricardo Lopes wrote:
Does the QueryParser class really uses the Analyzer passed to the
parse method ?
Absolutely.
I look at the code and i dont the object beeing used anywhere in the
class. The problem is that i am writting an application with lucene
that searches
On Nov 30, 2004, at 2:29 PM, Ricardo Lopes wrote:
My guess is that your analyzer is what did the splitting
After looker with more attetion to the code i found that the
tokenStream method in the BrazilianAnalyzer calls the
StandardTokenizer and is this the one that split the search string, is
Here is another link with more information on doing official releases.
What's the status of the 1.4.3 release?
Erik
Begin forwarded message:
From: robert burrell donkin [EMAIL PROTECTED]
Date: November 28, 2004 5:45:20 PM EST
To: Erik Hatcher [EMAIL PROTECTED]
Subject: Re: help
Yes - it should be updated.
Erik
On Nov 29, 2004, at 1:56 PM, Daniel Naber wrote:
Hi,
StandardTokenizer.jj still contains version 1.1 of the Apache license.
Is
it okay to update it to 2.0?
Regards
Daniel
--
http://www.danielnaber.de
Christoph,
Many thanks for tackling this administrative stuff.
I see the release where you put it, though I have not tried it yet.
Do you see any steps in the process that we could/should automate to
make this easier in the future?
It would be nice if we could get 1.4.1 and 1.4.2 released
the jar file copied over to the
maven repo as well. I took the liberty of doing this for 1.4.3 (hope
you don't mind!).
Thanks again for the awesome library!
-Brian
On Nov 29, 2004, at 2:06 PM, Erik Hatcher wrote:
Christoph,
Many thanks for tackling this administrative stuff.
I see the release where you
This change should be noted in the CHANGES file also, just in case
folks are actually using this key currently.
Erik
On Nov 29, 2004, at 5:38 PM, [EMAIL PROTECTED] wrote:
bmesser 2004/11/29 14:38:48
Modified:src/java/org/apache/lucene/store FSDirectory.java
Log:
change
On Nov 26, 2004, at 11:40 AM, [EMAIL PROTECTED] wrote:
-
href=http://cvs.apache.org/dist/jakarta/lucene/v1.4.2/;here/a.
+
href=http://cvs.apache.org/dist/jakarta/lucene/v1.4.3/;here/a.
Did you sign the binary files and place there where the mirrors will
pick them
On Nov 26, 2004, at 12:09 PM, Christoph Goller wrote:
The distribution will contain docs and API from branch 1.4.3.
For the web-page I plan to use docs from the CVS head, but API
Javadoc from 1.4.3 branch. Does this sound reasonable?
I think you should use everything from the 1.4.3 branch.
I did
On Nov 26, 2004, at 1:14 PM, Christoph Goller wrote:
Erik Hatcher schrieb:
On Nov 26, 2004, at 12:09 PM, Christoph Goller wrote:
The distribution will contain docs and API from branch 1.4.3.
For the web-page I plan to use docs from the CVS head, but API
Javadoc from 1.4.3 branch. Does this sound
On Nov 26, 2004, at 12:09 PM, Christoph Goller wrote:
Erik Hatcher schrieb:
On Nov 26, 2004, at 11:40 AM, [EMAIL PROTECTED] wrote:
-
href=http://cvs.apache.org/dist/jakarta/lucene/v1.4.2/;here/a.
+
href=http://cvs.apache.org/dist/jakarta/lucene/v1.4.3/;here/a.
Did
On Nov 26, 2004, at 1:40 PM, Christoph Goller wrote:
So why not merge these changes back to 1.4.3 and keep the site purely
at that branch?
Well, it seems that the Lucene website is something that changes more
often
than releases. So I don't see much sense in using the outdated 1.4.3
branch
releases
Joshua Slive wrote:
Erik Hatcher wrote:
Are the instructions for doing a binary, signed, mirrored release
available somewhere on the new wiki or web site? If so, where?
Henk P. keeps a collection of useful links at the bottom of this page:
http://www.apache.org/~henkp/
Ask on infrastructure
On Nov 23, 2004, at 6:14 PM, [EMAIL PROTECTED] wrote:
dnaber 2004/11/23 15:14:31
Modified:src/test/org/apache/lucene/queryParser
TestQueryParser.java
Log:
adapt to new typesafe API
-qp.setOperator(QueryParser.DEFAULT_OPERATOR_OR);
+
1 - 100 of 382 matches
Mail list logo
