DO NOT REPLY [Bug 32580] - Submissiom of my Tswana Analyzer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 32580] New: - Submissiom of my Tswana Analyzer

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: two versioning problems with Lucene

I don't think we need to support cases where people open a Jar - I've never seen a case where this was needed. Expanded WARs and EARs I've seen, but not Jars. I'm for relying on the information in MANIFEST.MF, and there must be tools for parsing that. If I needed Lucene's version number, I'd get

Re: two versioning problems with Lucene

What about the other issue: storing version information with the Lucene index data? Cheers, Jeff PS. I looked up the relevant documentation on manifest versioning. http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html#PackageVersioning http://java.sun.com/j2se/1.

Re: two versioning problems with Lucene

On Tuesday 07 December 2004 18:53, Erik Hatcher wrote: > On Dec 7, 2004, at 7:42 PM, Bill Janssen wrote: ... > JAR manifests, while certainly not leveraged this way by most, were > designed to contain versioning information. ... > I'm merely discussing the options. We've had the version informatio

Re: two versioning problems with Lucene

(1) the manifest file may not be available (the class files may be re-packaged in another app which didn't know to copy the Lucene manifest stuff, or unpacked) I'd like to hear others weigh in on this repackaging issue. Is this a common practice? There is one area where this is very common pract

Re: two versioning problems with Lucene

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 j

Re: two versioning problems with Lucene

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 co

Re: two versioning problems with Lucene

This incredibly fragile bit of code should work for existing jar files, but good grief! Bill --- import java.util.jar.*; import java.io.*; import java.net.*; class test { public static void main (String[] argv) { int major_version = 0

Re: two versioning problems with Lucene

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

cvs commit: jakarta-lucene build.xml

ehatcher2004/12/07 17:19:51 Modified:.Tag: lucene_1_4_2_dev build.xml Log: fix manifest misspelling Revision ChangesPath No revision No revision 1.65.2.1 +1 -1 jakarta-lucene/build.xml Index: build.xml =

Re: two versioning problems with Lucene

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? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional comma

Re: two versioning problems with Lucene

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 copy the Lucene manifest stuff, or unpacked), and

[ANNOUNCE] Lucene 1.4.3 released

I'd like to officially announce Lucene 1.4.3. This release fixes two bugs, the list of changes is so short that I will simply paste it here: 1. The JSP demo page (src/jsp/results.jsp) now properly escapes error messages which might contain user input (e.g. error messages about query pa

HTMLParser.jj still has ASL 1.1

Just wanted to note that the \src\demo\org\apache\lucene\demo\html\HTMLParser.jj file was missed in the license upgrade. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

RE: two versioning problems with Lucene

Here is the API you should be using to fetch the version: public static void main(String[] args) throws ClassNotFoundException { // make sure the class loader knows about a lucene package Package lucenePackage = Class.forName("org.apache.lucene.util.Constants")

Re: two versioning problems with Lucene

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 the

Re: two versioning problems with Lucene

> 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 the jar file and use them directly? Or the

Lucene in Action source code

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 downloa

Re: two versioning problems with Lucene

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