Re: 1.9 RC1

2006-02-17 Thread Jeff Breidenbach
This week is pretty booked for me, so, barring major objections, I will 
make a 1.9 RC1 release next Monday, February 20th.  If there are no 
problems discovered, I'll aim to make a 1.9 final release a week later, 
around the 27th.


Has anyone tested if 1.9 can build with a Free Software toolchain? (e.g. 
kaffe)


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[EMAIL PROTECTED]: Project lucene-java (in module lucene-java) failed

2006-02-17 Thread Jason van Zyl
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project lucene-java has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 3 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-lucene :  Java Based Search Engine
- lucene-java :  Java Based Search Engine


Full details are available at:
http://vmgump.apache.org/gump/public/lucene-java/lucene-java/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [lucene-core-17022006.jar] identifier set to project name
 -DEBUG- Dependency on javacc exists, no need to add for property javacc.home.
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/lucene-java/lucene-java/gump_work/build_lucene-java_lucene-java.html
Work Name: build_lucene-java_lucene-java (Type: Build)
Work ended in a state of : Failed
Elapsed: 20 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=17022006 
-Djavacc.home=/usr/local/gump/packages/javacc-3.1 package 
[Working Directory: /usr/local/gump/public/workspace/lucene-java]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/lucene-java/build/classes/java:/usr/local/gump/public/workspace/lucene-java/build/classes/demo:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:junit-gump-15022006.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/packages/je-1.7.1/lib/je.jar:/usr/local/gump/packages/javacc-3.1/bin/lib/javacc.jar:/usr/local/gump/public/workspace/httpunit/jars/Tidy.jar
-
[javac] location: class 
org.apache.lucene.queryParser.TestMultiFieldQueryParser
[javac] public class TestMultiFieldQueryParser extends TestCase {
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/queryParser/TestQueryParser.java:19:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/queryParser/TestQueryParser.java:53:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.lucene.queryParser.TestQueryParser
[javac] public class TestQueryParser extends TestCase {
[javac]  ^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/BaseTestRangeFilter.java:21:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/BaseTestRangeFilter.java:29:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.lucene.search.BaseTestRangeFilter
[javac] public class BaseTestRangeFilter extends TestCase {
[javac]  ^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/CheckHits.java:19:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/QueryUtils.java:3:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/TestBoolean2.java:33:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/TestBoolean2.java:40:
 cannot resolve symbol
[javac] symbol  : 

[EMAIL PROTECTED]: Project lucene-java (in module lucene-java) failed

2006-02-17 Thread Jason van Zyl
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project lucene-java has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 3 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-lucene :  Java Based Search Engine
- lucene-java :  Java Based Search Engine


Full details are available at:
http://vmgump.apache.org/gump/public/lucene-java/lucene-java/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [lucene-core-17022006.jar] identifier set to project name
 -DEBUG- Dependency on javacc exists, no need to add for property javacc.home.
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/lucene-java/lucene-java/gump_work/build_lucene-java_lucene-java.html
Work Name: build_lucene-java_lucene-java (Type: Build)
Work ended in a state of : Failed
Elapsed: 20 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/build/xercesImpl.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=17022006 
-Djavacc.home=/usr/local/gump/packages/javacc-3.1 package 
[Working Directory: /usr/local/gump/public/workspace/lucene-java]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/lucene-java/build/classes/java:/usr/local/gump/public/workspace/lucene-java/build/classes/demo:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:junit-gump-15022006.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/packages/je-1.7.1/lib/je.jar:/usr/local/gump/packages/javacc-3.1/bin/lib/javacc.jar:/usr/local/gump/public/workspace/httpunit/jars/Tidy.jar
-
[javac] location: class 
org.apache.lucene.queryParser.TestMultiFieldQueryParser
[javac] public class TestMultiFieldQueryParser extends TestCase {
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/queryParser/TestQueryParser.java:19:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/queryParser/TestQueryParser.java:53:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.lucene.queryParser.TestQueryParser
[javac] public class TestQueryParser extends TestCase {
[javac]  ^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/BaseTestRangeFilter.java:21:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/BaseTestRangeFilter.java:29:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.lucene.search.BaseTestRangeFilter
[javac] public class BaseTestRangeFilter extends TestCase {
[javac]  ^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/CheckHits.java:19:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/QueryUtils.java:3:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/TestBoolean2.java:33:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/x1/gump/public/workspace/lucene-java/src/test/org/apache/lucene/search/TestBoolean2.java:40:
 cannot resolve symbol
[javac] symbol  : 

Re: 1.9 RC1

2006-02-17 Thread Dan Armbrust
I'd like to see this improvement request implemented - but I'm not sure 
if 1.9 or 2.0 would be a better place to do it:


http://issues.apache.org/jira/browse/LUCENE-301

Short summary - The Constructor for IndexWriter currently will only 
create an index in a folder if you set the boolean create flag to true. 
 But then, if you want to append to that index, you have to set the 
create flag to false (otherwise it overwrites)


In my use cases, I seldom want to overwrite an index - but I often 
create new ones, and append to existing ones.  Forgetting to switch the 
boolean flag between the initial create and the append causes data loss.


To me, a better, safer API would be to change the parameter named 
create into clear - and then change the behavior so that is always 
creates a new index at the specified location if one doesn't already exist.


If clear is false - it would append (same as current behavior) - and if 
clear is true is would clear first, and then create a new index.  So 
nobody using the API should break.


Dan

--

Daniel Armbrust
Biomedical Informatics
Mayo Clinic Rochester
daniel.armbrust(at)mayo.edu
http://informatics.mayo.edu/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



[jira] Commented: (LUCENE-301) Index Writer constructor flags unclear - and annoying in certain cases

2006-02-17 Thread Hoss Man (JIRA)
[ 
http://issues.apache.org/jira/browse/LUCENE-301?page=comments#action_12366834 ] 

Hoss Man commented on LUCENE-301:
-


The only change (and I consider it an improvment, and unlikely to break anyones
code) is that if it is set to false, and no index exists yet, then it will
create a new empty index at the specified location.

...that could be very bad for tools/apps that wantto update an existing index 
after reading the directory path from user input or configs when the user makes 
a typo.  In the past new IndexWriter(d,a,false) would throw an Exception 
indicating a problem, with the change you describe it would happily make a new 
index.


I'd be happy to see a more explict API with more options about what you want 
IndexWRiter to do if/when the directory does'doesn't exist ... but it should be 
100% backwards compatible.  deprecating this constructor but leaving it alone 
and adding a new one with more options seems like a much safer approach.

 Index Writer constructor flags unclear - and annoying in certain cases
 --

  Key: LUCENE-301
  URL: http://issues.apache.org/jira/browse/LUCENE-301
  Project: Lucene - Java
 Type: Improvement
   Components: Index
 Versions: 1.4
  Environment: Operating System: other
 Platform: Other
 Reporter: Dan Armbrust
 Assignee: Lucene Developers
 Priority: Minor


 Wouldn't it make more sense if the constructor for the IndexWriter always
 created an index if it doesn't exist - and the boolean parameter should be
 clear (instead of create)
 So instead of this (from javadoc):
 IndexWriter
 public IndexWriter(Directory d,
Analyzer a,
boolean create)
 throws IOException
 Constructs an IndexWriter for the index in d. Text will be analyzed with 
 a.
 If create is true, then a new, empty index will be created in d, replacing the
 index already there, if any.
 Parameters:
 d - the index directory
 a - the analyzer to use
 create - true to create the index or overwrite the existing one; false to
 append to the existing index 
 Throws:
 IOException - if the directory cannot be read/written to, or if it does 
 not
 exist, and create is false
 We would have this:
 IndexWriter
 public IndexWriter(Directory d,
Analyzer a,
boolean clear)
 throws IOException
 Constructs an IndexWriter for the index in d. Text will be analyzed with 
 a.
 If clear is true, and a index exists at location d, then it will be erased, 
 and
 a new, empty index will be created in d.
 Parameters:
 d - the index directory
 a - the analyzer to use
 clear - true to overwrite the existing one; false to append to the 
 existing
 index 
 Throws:
 IOException - if the directory cannot be read/written to, or if it does 
 not
 exist.
 Its current behavior is kind of annoying, because I have an app that should
 never clear an existing index, it should always append.  So I want create set 
 to
 false.  But when I am starting a brand new index, then I have to change the
 create flag to keep it from throwing an exception...  I guess for now I will
 have to write code to check if a index actually has content yet, and if it
 doesn't, change the flag on the fly.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Implementing new scoring algorithms in lucene

2006-02-17 Thread Shailesh Kochhar
Hi,

I'm interested in implementing a few new scoring algorithms in Lucene
and I was wondering if anyone had attempted this in the past and how
successful they had been. If there are any resources that someone
could point me to that would be great, Googling and searching the
mailing-list archives didn't turn up anything.

After looking over the current implementation of tf-idf scoring, I
concluded that the  weighting and scoring framework is mostly
implemented in TermQuery and TermScorer classes. I am thinking of
extending these classes and replacing a few others to implement the
new algorithm. Am I heading in the right direction? Does it make sense
to try and extend these classes or should I try building a parallel
heirarchy to do this?

Thank you for your time,
  - Shailesh