Re: Back Compatibility
> Examples of the former issue include things like removing > deprecations sooner and the ability to add new methods to interfaces > (both of these are not to be done ad-hoc) What would be the difference between ad-hoc and non-ad-hoc? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The JDK 1.5 Can o' Worms
> Frankly, I am amazed at the pace of GCJ, but it is hard to imagine that > with so much free code out there doing what they need, that it could > take much longer to get 1.5 support. Just guessing, but could it be that the features in 1.5 and 1.6 are just not compelling enough to motivate many contributors to add them to gcj? Or maybe the plethora of various FOSS Java VMs is confusing the issue. > If they don't have Java 1.5 support in another 6-12 months (with so many > shortcuts available), why let such a laggard in the java community hold > back Lucene? Presumably because what's being done with gcj and Lucene is also an important use of Lucene that the Lucene developers don't wish to gratuitously cripple. > And if they are going to support Java 1.5 within the next > 6-18 months, what is so bad about a short gap time where you are stuck > with Lucene 2.9? No one seems so upset at being stuck with Java 1.4 for > years -- will there really be an uproar if some legacy systems need to > stay with 2.9 for 6 months? It would be sad to expect that Java 1.5 will > not be coming to GCJ soon. And it would seem to be poor engineering, given the past history of gcj development, to predict a time-frame for the emergence of full 1.5 support. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The JDK 1.5 Can o' Worms
> As I said > before, people who can't migrate, can stay on the 2.9. It will be > fast and pretty darn stable, so you won't lose that much. Hmmm... :-). If you won't lose that much by staying on 2.9, that means that the developers who forge ahead with 1.5 would also not *gain* that much by doing so. Might as well stay at java 1.4.2, no? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The JDK 1.5 Can o' Worms
Grant Ingersoll writes: > I also believe all committers and > all contributors are using 1.5 already for there environment. I > would also _guess_ the large majority of our users are on 1.5. Now, > I know, it isn't a big deal to run 1.4 code in 1.5, but it is > annoying for development and that is a big enough motivator for me. The big issue wasn't whether developers and application users were using Sun's Java 1.5, it was gcj and where it was. Several of the downstream packages of Lucene involves gcj instead of Sun Java, because gcj provides different functionality. I believe that any 1.5 features used in Lucene should be carefully chosen to be compatible with stable versions of gcj, so that PyLucene, for instance, will be able to use it. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
exposing addClause in the query parser?
I'd like to suggest a minor change in the QueryParser.jj. I thought
I'd describe it here and get some feedback before posting a patch.
The issue is that I can't get my hands on some clauses (typically
PhraseQuery instances) in my subclass of MultiFieldQueryParser, which
I'd like to do to implement some tricks. I could do if I could
usefully subclass "addClause", but that breaks for some very specific
instances. If you look at the code below (from QueryParser.jj), you
see that in a certain common case (one search term without modifiers),
any work done by addClause() is ignored.
For instances, if you use the search 'foo:"bar"', addClause will be
called, the clauses vector will be updated, but it will then be
ignored.
I'd like to suggest that the pertinent code be re-written to always
use the contents of the clauses vector. My rewrite is the second
piece of code I've appended here. As you can see, the function is
smaller and simpler, but returns the same clauses in the un-subclassed
case. It also lets us override "addClause()" and use it to examine
and possibly modify each clause that's encountered by the parser.
Comments?
Bill
Current version (from SVN):
Query Query(String field) :
{
Vector clauses = new Vector();
Query q, firstQuery=null;
int conj, mods;
}
{
mods=Modifiers() q=Clause(field)
{
addClause(clauses, CONJ_NONE, mods, q);
if (mods == MOD_NONE)
firstQuery=q;
}
(
conj=Conjunction() mods=Modifiers() q=Clause(field)
{ addClause(clauses, conj, mods, q); }
)*
{
if (clauses.size() == 1 && firstQuery != null)
return firstQuery;
else {
return getBooleanQuery(clauses);
}
}
}
---
New version:
Query Query(String field) :
{
Vector clauses = new Vector();
Query q;
int conj, mods;
}
{
mods=Modifiers() q=Clause(field)
{
addClause(clauses, CONJ_NONE, mods, q);
}
(
conj=Conjunction() mods=Modifiers() q=Clause(field)
{ addClause(clauses, conj, mods, q); }
)*
{
if (clauses.size() == 1)
return (Query) (clauses.get(0));
else {
return getBooleanQuery(clauses);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
> A clear majority has voted. Why can't we > listen to them and move forward??? Just to be clear: a (badly designed) poll was taken. No one "voted". Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
> I think Chuck's suggestion was the best one so far: > - allow 1.5 in trunk > - those who want/need 1.4 can back-port it Hmmm, seems a lot like just kissing off 1.4 users. Just-an-interested-bystander-here, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene and Java 1.5
My concern is really with the use of GCJ with Lucene. I'd hate to see Lucene core releases that couldn't be used with the latest "stable" release of GCJ. Unfortunately, it's very hard to know what that means. What's the latest version of GCJ? What Java language features are supported in it? It's impossible to tell from the GCJ home page. Bill > : Boy, I'd sure like to see at least one bug-fix release for 2.0 > : maintain java 1.4 compatibility. Would that be 2.1? > > : Could be 2.0.*. I think that is what Hoss was saying, too. > > Yes, that was my point ... as far as i can tell, Lucene bug fix releases > have historically been at the "third level" of the release number: 1.4.1, > 1.4.2, and 1.4.3 were all bug fixes on the 1.4 release branch. 1.9.1 was > a bug fix on the 1.9 release branch. > > I'm suggesting there may be any number of 2.0.X bug fixing releases on the > 2.0 branch which will all be java1.4 compatible. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene and Java 1.5
Boy, I'd sure like to see at least one bug-fix release for 2.0 maintain java 1.4 compatibility. Would that be 2.1? Bill > This sounds reasonable to me. I feel bad about Andi and PyLucene, but it > sounds like GCJ(X) will soon be up-to-date (the link Andi sent was from early > February). Discussion done or? > > Otis > > - Original Message > From: Chris Hostetter <[EMAIL PROTECTED]> > To: java-dev@lucene.apache.org > Sent: Saturday, May 27, 2006 7:12:15 PM > Subject: Re: Lucene and Java 1.5 > > : important new facilities. Repeating my earlier question, why should a > : platform that is 2 years behind for java expect to be at the latest and > : greatest level for lucene? I'd propose 2.0 (+ branched patches) be the > : 1.4 release distribution, with 2.1 free to move up to 1.5. > > I would ammend that proposal slightly... > > 1a) Lucene Core 2.0.* releases garuntee java1.4 compatibility > 1b) Lucene Contrib modules in 2.0.* releases are free to require any java > version they choose. > > 2a) Lucene Core 2.1.* release garuntee java1.5 compatibility. > 2b) Lucene Contrib modules in 2.1.* releases are free to require any java > version they choose. > > -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Taking a step back
> File formats are back-compatible between major versions. Version X.N > should be able to read indexes generated by any version after and > including version X-1.0, but may-or-may-not be able to read indexes > generated by version X-2.N. > > Note that older releases are never guaranteed to be able to read indexes > generated by newer releases. When this is attempted, a predictable > error should be generated. > > Does that sound reasonable? Have you put a field in the file format yet that gives its version? Alternatively, is there a way to find out which version of Lucene needs to be used with a given index? Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compatibility of Lucene 1.9
Thanks, I'll try it. Bill > mkdir -p lucene/java/trunk > svn checkout http://svn.apache.org/repos/asf/lucene/java/trunk > lucene/java/trunk > cd lucene/java/trunk; ant > > The parser generator (JavaCC) is only needed if you change the grammar file= > . > > -Yonik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compatibility of Lucene 1.9
> No, not officially. Checking out from Subversion and running "ant" > is all that is needed to get the latest JAR though. Somehow I doubt that. Isn't there some parser generator that has to be installed? And what's the command line to do the svn checkout? It's not apparent from the Lucene web site. I have the svn client installed. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compatibility of Lucene 1.9
Is the 1.9 jar file available somewhere as an alpha for download? I'd like to try my app with it. Bill > Hi, > > I added this to our CHANGES file: > > Note that this realease is mostly but not 100% source compatible with the > latest release of Lucene (1.4.3). In other words, you should make sure > your application compiles with this version of Lucene before you replace > the old Lucene JAR with the new one. > > This refers to the fact that for example some methods in Query now throw an > IOException that didn't throw this exception before. Everyone feel free to > modify this warning, as I'm not sure if it's worded correctly. > > Regards > Daniel > > -- > http://www.danielnaber.de > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
