[jira] Commented: (LUCENE-1439) Inconsistent API

2008-11-07 Thread Mark Miller (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645778#action_12645778
 ] 

Mark Miller commented on LUCENE-1439:
-

Patch coming?

I'd classify as improvement rather than bug to start. Also, keep in mind that 
everything will have to be backward compatible (though that gets fuzzier as we 
approach version 3)

> Inconsistent API 
> -
>
> Key: LUCENE-1439
> URL: https://issues.apache.org/jira/browse/LUCENE-1439
> Project: Lucene - Java
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: any
>Reporter: Ivan.S
>
> The API of Lucene is totally inconsistent:
> 1)
> There are a lot of containers which don't implement an interface which 
> indicates this fact
> (for pre-java-1.5 Lucene it could be Collection, for post-ajva-1.5 Lucene it 
> could be more general Iterable)
> Example:
>  IndexSearcher: "int maxDoc()" and "doc(int i)"
> 2)
> There are a lot of classes having non-final public accessible fields.
> 3)
> Some methods which return values are named something() others are named 
> getSomething()
> Best one is: Fieldable:
> without get: String stringValue(), Reader readerValue(), byte[] 
> binaryValue(), ...
> with get: byte[] getBinaryValue(), int getBinaryLength(), ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-1439) Inconsistent API

2008-11-07 Thread Mark Miller (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LUCENE-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated LUCENE-1439:


Priority: Minor  (was: Major)

> Inconsistent API 
> -
>
> Key: LUCENE-1439
> URL: https://issues.apache.org/jira/browse/LUCENE-1439
> Project: Lucene - Java
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: any
>Reporter: Ivan.S
>Priority: Minor
>
> The API of Lucene is totally inconsistent:
> 1)
> There are a lot of containers which don't implement an interface which 
> indicates this fact
> (for pre-java-1.5 Lucene it could be Collection, for post-ajva-1.5 Lucene it 
> could be more general Iterable)
> Example:
>  IndexSearcher: "int maxDoc()" and "doc(int i)"
> 2)
> There are a lot of classes having non-final public accessible fields.
> 3)
> Some methods which return values are named something() others are named 
> getSomething()
> Best one is: Fieldable:
> without get: String stringValue(), Reader readerValue(), byte[] 
> binaryValue(), ...
> with get: byte[] getBinaryValue(), int getBinaryLength(), ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Closed: (LUCENE-1439) Inconsistent API

2008-11-07 Thread Michael Busch (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LUCENE-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Busch closed LUCENE-1439.
-

Resolution: Incomplete

I agree that there are several APIs that could be improved in Lucene. However, 
opening an issue like this is not very helpful.

Please open a more specific issue for a particular API you'd like to fix, 
attach a patch that deprecates the old one, introduces a new one, maintains 
backwards-compatibility and provides unit tests. (see LUCENE-1422 as a current 
example).

If you don't want to provide such a patch then you can also start a discussion 
on the mailinglists and suggest API improvements.

> Inconsistent API 
> -
>
> Key: LUCENE-1439
> URL: https://issues.apache.org/jira/browse/LUCENE-1439
> Project: Lucene - Java
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: any
>Reporter: Ivan.S
>Priority: Minor
>
> The API of Lucene is totally inconsistent:
> 1)
> There are a lot of containers which don't implement an interface which 
> indicates this fact
> (for pre-java-1.5 Lucene it could be Collection, for post-ajva-1.5 Lucene it 
> could be more general Iterable)
> Example:
>  IndexSearcher: "int maxDoc()" and "doc(int i)"
> 2)
> There are a lot of classes having non-final public accessible fields.
> 3)
> Some methods which return values are named something() others are named 
> getSomething()
> Best one is: Fieldable:
> without get: String stringValue(), Reader readerValue(), byte[] 
> binaryValue(), ...
> with get: byte[] getBinaryValue(), int getBinaryLength(), ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-1439) Inconsistent API

2008-11-07 Thread Uwe Schindler (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645787#action_12645787
 ] 

Uwe Schindler commented on LUCENE-1439:
---

In my opinion, these are things that are really not nice currently. The next 
major version of Lucene should really fix these annoying inconsistencies 
(especially for beginners).

I would be happy to help cleaning the API through 2.9 / 3.0 after some 
discussion about this!

> Inconsistent API 
> -
>
> Key: LUCENE-1439
> URL: https://issues.apache.org/jira/browse/LUCENE-1439
> Project: Lucene - Java
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: any
>Reporter: Ivan.S
>Priority: Minor
>
> The API of Lucene is totally inconsistent:
> 1)
> There are a lot of containers which don't implement an interface which 
> indicates this fact
> (for pre-java-1.5 Lucene it could be Collection, for post-ajva-1.5 Lucene it 
> could be more general Iterable)
> Example:
>  IndexSearcher: "int maxDoc()" and "doc(int i)"
> 2)
> There are a lot of classes having non-final public accessible fields.
> 3)
> Some methods which return values are named something() others are named 
> getSomething()
> Best one is: Fieldable:
> without get: String stringValue(), Reader readerValue(), byte[] 
> binaryValue(), ...
> with get: byte[] getBinaryValue(), int getBinaryLength(), ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-1424) Change all mutli term querys so that they extend MultiTermQuery and allow for a constant score mode

2008-11-07 Thread Mark Miller (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LUCENE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated LUCENE-1424:


Attachment: LUCENE-1424.patch

> Change all mutli term querys so that they extend MultiTermQuery and allow for 
> a constant score mode
> ---
>
> Key: LUCENE-1424
> URL: https://issues.apache.org/jira/browse/LUCENE-1424
> Project: Lucene - Java
>  Issue Type: New Feature
>Reporter: Mark Miller
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-1424.patch, LUCENE-1424.patch, LUCENE-1424.patch, 
> LUCENE-1424.patch, LUCENE-1424.patch, LUCENE-1424.patch, LUCENE-1424.patch, 
> LUCENE-1424.patch
>
>
> Cleans up a bunch of code duplication, closer to how things should be - 
> design wise, gives us constant score for all the multi term queries, and 
> allows us at least the option of highlighting the constant score queries 
> without much further work.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (LUCENE-1439) Inconsistent API

2008-11-07 Thread Ivan.S (JIRA) 
Inconsistent API 
-

 Key: LUCENE-1439
 URL: https://issues.apache.org/jira/browse/LUCENE-1439
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 3.0
 Environment: any
Reporter: Ivan.S


The API of Lucene is totally inconsistent:

1)
There are a lot of containers which don't implement an interface which 
indicates this fact
(for pre-java-1.5 Lucene it could be Collection, for post-ajva-1.5 Lucene it 
could be more general Iterable)

Example:
 IndexSearcher: "int maxDoc()" and "doc(int i)"

2)
There are a lot of classes having non-final public accessible fields.

3)
Some methods which return values are named something() others are named 
getSomething()

Best one is: Fieldable:
without get: String stringValue(), Reader readerValue(), byte[] binaryValue(), 
...
with get: byte[] getBinaryValue(), int getBinaryLength(), ...


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Adding dependency to servlet-api

2008-11-07 Thread Erik Hatcher 

Mark - I've done a quick implementation here:

  

I'm not familiar, yet, with what it takes (haven't read your  
contribution to LIA2 yet, bad, Erik, bad) to configure it - so any  
feedback you have on what might be needed beyond this is welcome:


  public Query parse() throws ParseException {
CorePlusExtensionsParser parser = new  
CorePlusExtensionsParser(getReq().getSchema().getQueryAnalyzer(),  
getReq().getSchema().getSolrQueryParser(null));

try {
  return parser.parse(new  
ByteArrayInputStream(getString().getBytes()));

} catch (ParserException e) {
  throw new ParseException(e.getMessage());
}
  }

Erik



On Nov 5, 2008, at 5:31 AM, mark harwood wrote:

How about simply adding a query parser plugin to Solr using the  
XML query parser?


My initial concern is to make public in Lucene/contrib the demo web  
app I have just written up for Lucene In Action 2. I wanted to put  
this in Lucene/contrib rather than limit it to being code  
distributed with the book.
This aside, I think it's generally important to maintain  
documentation/demos/code and other useful resources under the core  
Lucene project for those people where Solr might not necessarily be  
the answer.


I'd be happy to help or to even go the full distance and implement  
it myself.


Adding XML query support to Solr certainly sounds like it would be a  
sensible idea. I think applications with advanced query criteria  
struggle with the constraints of standard Lucene QueryParser syntax  
or passing "flat" parameters in Solr urls.
Not sure I can commit any time to extending Solr myself but happy to  
support you with any guidance you may need on this.


Cheers,
Mark








- Original Message 
From: Erik Hatcher <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Wednesday, 5 November, 2008 10:48:48
Subject: Re: Adding dependency to servlet-api

Mark,

How about simply adding a query parser plugin to Solr using the XML  
query parser?   It'd be pretty short, sweet, easy, and a real value- 
add to Solr too!   I'd be happy to help or to even go the full  
distance and implement it myself.  I've considered it often, as it  
would be great to provide the breadth of query types that your  
parser can create.


   Erik




On Nov 5, 2008, at 4:16 AM, mark harwood wrote:

Just checked Solr (forgot about that obvious precedent!) and they  
have it in trunk/lib and an entry in trunk/notice.txt which reads:


"  Includes software from other Apache Software Foundation  
projects, including, but not limited to:

   
- Apache Tomcat (lib/servlet-api-2.4.jar)

"
I thought the servlet api was Sun's to be honest so not sure why it  
is credited to Tomcat.


I could just follow this precedent. Anyone from the Solr camp care  
to comment?





- Original Message 
From: Uwe Schindler <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org; [EMAIL PROTECTED]
Sent: Wednesday, 5 November, 2008 9:53:51
Subject: RE: Adding dependency to servlet-api

E.g. Jetty webserver (Apache 2.0 License) ships the servlet 2.5 API  
in

source (SVN) and binary form along with its web container server.

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [EMAIL PROTECTED]


From: Konstantin Priblouda [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2008 10:42 AM
To: java-dev@lucene.apache.org
Subject: Re: Adding dependency to servlet-api



[ Konstantin Pribluda http://www.pribluda.de ]
JTec quality components: http://www.pribluda.de/projects/


--- On Tue, 11/4/08, markharw00d <[EMAIL PROTECTED]> wrote:


From: markharw00d <[EMAIL PROTECTED]>
Subject: Adding dependency to servlet-api
To: java-dev@lucene.apache.org
Date: Tuesday, November 4, 2008, 11:09 PM
I'd like to add a web-based demo for the XML QueryParser
but unlike the existing web demo I'd prefer to use some
Java code that gets compiled rather than doing it all in JSP
files that aren't part of the build. Doing it this way
will add a dependency on servlet-api.jar which will need to
be added to the build somehow.
Has anyone done this before on an Apache project before and
know what the license implications are? Tomcat/Struts must
do this already but I'm not sure what is involved.


Geronimo project provides servlet api declarations in m2  
repository on

apache.
Usually this is agood choice.




-
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]




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

[jira] Commented: (LUCENE-1439) Inconsistent API

2008-11-07 Thread Ivan.S (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645826#action_12645826
 ] 

Ivan.S commented on LUCENE-1439:


I was thinking about this issue as a "request". Sadly, I currently don't have 
time to crawl through an unknown API and search for all inconsistencies.
The comments imply, that other people know what I'm talking about. So perhaps, 
instead of closing the issue as 'incomplete', someone (who already KNOWS this 
API) could list most frequent 'inconsistent' classes?
The fact that I'm new to Lucene makes it very probable that my proposed patches 
will be rejected anyway (because they would just "not fit" somehow).
Second thing is: I read few comments about java-1.5-only vs not-java-1.5-only 
policy for future Lucene. It seems that even the developers can't agree on this 
issue. How could I?

> Inconsistent API 
> -
>
> Key: LUCENE-1439
> URL: https://issues.apache.org/jira/browse/LUCENE-1439
> Project: Lucene - Java
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: any
>Reporter: Ivan.S
>Priority: Minor
>
> The API of Lucene is totally inconsistent:
> 1)
> There are a lot of containers which don't implement an interface which 
> indicates this fact
> (for pre-java-1.5 Lucene it could be Collection, for post-ajva-1.5 Lucene it 
> could be more general Iterable)
> Example:
>  IndexSearcher: "int maxDoc()" and "doc(int i)"
> 2)
> There are a lot of classes having non-final public accessible fields.
> 3)
> Some methods which return values are named something() others are named 
> getSomething()
> Best one is: Fieldable:
> without get: String stringValue(), Reader readerValue(), byte[] 
> binaryValue(), ...
> with get: byte[] getBinaryValue(), int getBinaryLength(), ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-1439) Inconsistent API

2008-11-07 Thread Steven Rowe (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645829#action_12645829
 ] 

Steven Rowe commented on LUCENE-1439:
-

Ivan,

I'm sorry to hear that you don't have time to devote to this issue.  Patches 
regularly go through a vetting process, so don't assume that yours would be 
rejected, as long as you are willing to accept guidance concerning the "not 
fitting".  In fact, you are in a perfect position to help, since your fresh 
take on the issues reflect a very common user experience.  Please don't give 
up.  

My suggestion, like Michael's: open a new issue with a focused suggestion, and 
provide a patch.

> Inconsistent API 
> -
>
> Key: LUCENE-1439
> URL: https://issues.apache.org/jira/browse/LUCENE-1439
> Project: Lucene - Java
>  Issue Type: Bug
>Affects Versions: 3.0
> Environment: any
>Reporter: Ivan.S
>Priority: Minor
>
> The API of Lucene is totally inconsistent:
> 1)
> There are a lot of containers which don't implement an interface which 
> indicates this fact
> (for pre-java-1.5 Lucene it could be Collection, for post-ajva-1.5 Lucene it 
> could be more general Iterable)
> Example:
>  IndexSearcher: "int maxDoc()" and "doc(int i)"
> 2)
> There are a lot of classes having non-final public accessible fields.
> 3)
> Some methods which return values are named something() others are named 
> getSomething()
> Best one is: Fieldable:
> without get: String stringValue(), Reader readerValue(), byte[] 
> binaryValue(), ...
> with get: byte[] getBinaryValue(), int getBinaryLength(), ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (LUCENE-1422) New TokenStream API

2008-11-07 Thread Michael Busch (JIRA) 

[ 
https://issues.apache.org/jira/browse/LUCENE-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645836#action_12645836
 ] 

Michael Busch commented on LUCENE-1422:
---

{quote}
Perhaps we could formalize this. We could specify a subversion URL in build.xml 
that points to a release tag, the tag of the oldest release we need to be 
compatible with. We add a test that retrieves the tests from this tag and 
compiles and runs them.
{quote}

I like this approach too. The only concern I have is about the package-private 
APIs. As we recently discussed they can always change, so if any test cases use 
package-private APIs that changed in trunk since the last release, then the old 
testcases would not even compile.

However, I worked on a patch for this and will open a new issue soon.

> New TokenStream API
> ---
>
> Key: LUCENE-1422
> URL: https://issues.apache.org/jira/browse/LUCENE-1422
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: Analysis
>Reporter: Michael Busch
>Assignee: Michael Busch
>Priority: Minor
> Fix For: 2.9
>
> Attachments: lucene-1422-take4.patch, lucene-1422.patch, 
> lucene-1422.take2.patch, lucene-1422.take3.patch, lucene-1422.take3.patch
>
>
> This is a very early version of the new TokenStream API that 
> we started to discuss here:
> http://www.gossamer-threads.com/lists/lucene/java-dev/66227
> This implementation is a bit different from what I initially
> proposed in the thread above. I introduced a new class called
> AttributedToken, which contains the same termBuffer logic 
> from Token. In addition it has a lazily-initialized map of
> Class -> Attribute. Attribute is also a
> new class in a new package, plus several implementations like
> PositionIncrementAttribute, PayloadAttribute, etc.
> Similar to my initial proposal is the prototypeToken() method
> which the consumer (e. g. DocumentsWriter) needs to call.
> The token is created by the tokenizer at the end of the chain
> and pushed through all filters to the end consumer. The 
> tokenizer and also all filters can add Attributes to the 
> token and can keep references to the actual types of the
> attributes that they need to read of modify. This way, when
> boolean nextToken() is called, no casting is necessary.
> I added a class called TestNewTokenStreamAPI which is not 
> really a test case yet, but has a static demo() method, which
> demonstrates how to use the new API.
> The reason to not merge Token and TokenStream into one class 
> is that we might have caching (or tee/sink) filters in the 
> chain that might want to store cloned copies of the tokens
> in a cache. I added a new class NewCachingTokenStream that
> shows how such a class could work. I also implemented a deep
> clone method in AttributedToken and a 
> copyFrom(AttributedToken) method, which is needed for the 
> caching. Both methods have to iterate over the list of 
> attributes. The Attribute subclasses itself also have a
> copyFrom(Attribute) method, which unfortunately has to down-
> cast to the actual type. I first thought that might be very
> inefficient, but it's not so bad. Well, if you add all
> Attributes to the AttributedToken that our old Token class
> had (like offsets, payload, posIncr), then the performance
> of the caching is somewhat slower (~40%). However, if you 
> add less attributes, because not all might be needed, then
> the performance is even slightly faster than with the old API.
> Also the new API is flexible enough so that someone could
> implement a custom caching filter that knows all attributes
> the token can have, then the caching should be just as 
> fast as with the old API.
> This patch is not nearly ready, there are lot's of things 
> missing:
> - unit tests
> - change DocumentsWriter to use new API 
>   (in backwards-compatible fashion)
> - patch is currently java 1.5; need to change before 
>   commiting to 2.9
> - all TokenStreams and -Filters should be changed to use 
>   new API
> - javadocs incorrect or missing
> - hashcode and equals methods missing in Attributes and 
>   AttributedToken
>   
> I wanted to submit it already for brave people to give me 
> early feedback before I spend more time working on this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (LUCENE-1440) Add ability to run backwards-compatibility tests automatically

2008-11-07 Thread Michael Busch (JIRA) 
Add ability to run backwards-compatibility tests automatically
--

 Key: LUCENE-1440
 URL: https://issues.apache.org/jira/browse/LUCENE-1440
 Project: Lucene - Java
  Issue Type: New Feature
  Components: Build
Reporter: Michael Busch
Assignee: Michael Busch
Priority: Minor
 Fix For: 2.9


This is an idea Doug mentioned on LUCENE-1422.

This patch adds new targets to build.xml to automatically download the junit 
tests from a previous Lucene release and run them against the current core.
Execute tests like this:
ant -Dtag=lucene_2_4_0 test-tag

It will create a new directory tags/lucene_2_4_0 and fetch the tests from the 
svn repository and run them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Re: Broken javadocs->site docs links

2008-11-07 Thread Doug Cutting 

Steven A Rowe wrote:
This would not entirely fix the issue; each version's javadocs should link to the same version of the site docs, rather than to the latest version (which is what I assume you mean here).  


Right.  The javadocs should use a relative link to point to versioned 
docs.  But, if releases have been made and broken links to absolute urls 
are in the wild, we can patch that with .htaccess.



Are you arguing that the trunk javadocs should not be published anywhere at all?


I've mostly given up on that battle...  Developers by definition can 
build their own javadocs, and a link, even from the developer part of 
the site, gives nightly builds more legitimacy.  If folks really want, 
they can find and bookmark the nightly link on Hudson.


But, back to the issue at hand, fixing broken links in the javadocs on 
Hudson seems like a low priority.


Doug

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

[jira] Updated: (LUCENE-1440) Add ability to run backwards-compatibility tests automatically

2008-11-07 Thread Michael Busch (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LUCENE-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Busch updated LUCENE-1440:
--

Attachment: lucene-1440.patch

Here's the patch.

It adds the targets 'test-tag' and 'clean-tags'.
In common-build.xml I added 'test-macro' and 'compile-test-macro' that are 
shared between the standard 'test' and new 'test-tag' targets.

Currently all tests from Lucene 2.4 pass with trunk.

> Add ability to run backwards-compatibility tests automatically
> --
>
> Key: LUCENE-1440
> URL: https://issues.apache.org/jira/browse/LUCENE-1440
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: Build
>Reporter: Michael Busch
>Assignee: Michael Busch
>Priority: Minor
> Fix For: 2.9
>
> Attachments: lucene-1440.patch
>
>
> This is an idea Doug mentioned on LUCENE-1422.
> This patch adds new targets to build.xml to automatically download the junit 
> tests from a previous Lucene release and run them against the current core.
> Execute tests like this:
> ant -Dtag=lucene_2_4_0 test-tag
> It will create a new directory tags/lucene_2_4_0 and fetch the tests from the 
> svn repository and run them.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (LUCENE-1441) KeywordTokenizer does not set start/end offset of the Token it produces

2008-11-07 Thread Michael McCandless (JIRA) 
KeywordTokenizer does not set start/end offset of the Token it produces
---

 Key: LUCENE-1441
 URL: https://issues.apache.org/jira/browse/LUCENE-1441
 Project: Lucene - Java
  Issue Type: Bug
  Components: Analysis
Affects Versions: 2.4, 2.3.2, 2.3.1, 2.3
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Minor


I think just adding these two lines in the next(Token) method is the right fix:

   reusableToken.setStartOffset(0);
   reusableToken.setEndOffset(upto);

I don't think this is a back compat issue because the start/end offset are now 
meaningless since they will inherit whatever the reusable token had previously 
been used for.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-1441) KeywordTokenizer does not set start/end offset of the Token it produces

2008-11-07 Thread Michael McCandless (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LUCENE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-1441:
---

Attachment: LUCENE-1441.patch

Attached patch.  I plan to commit shortly.

> KeywordTokenizer does not set start/end offset of the Token it produces
> ---
>
> Key: LUCENE-1441
> URL: https://issues.apache.org/jira/browse/LUCENE-1441
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: Analysis
>Affects Versions: 2.3, 2.3.1, 2.3.2, 2.4
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-1441.patch
>
>
> I think just adding these two lines in the next(Token) method is the right 
> fix:
>reusableToken.setStartOffset(0);
>reusableToken.setEndOffset(upto);
> I don't think this is a back compat issue because the start/end offset are 
> now meaningless since they will inherit whatever the reusable token had 
> previously been used for.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (LUCENE-1442) NOT_ANALYZED fields can double-count offsets

2008-11-07 Thread Michael McCandless (JIRA) 
NOT_ANALYZED fields can double-count offsets


 Key: LUCENE-1442
 URL: https://issues.apache.org/jira/browse/LUCENE-1442
 Project: Lucene - Java
  Issue Type: Bug
  Components: Index
Affects Versions: 2.4
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Minor


If the same field name has 2 NOT_ANALYZED field instances then the offsets are 
double-counted.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (LUCENE-1442) NOT_ANALYZED fields can double-count offsets

2008-11-07 Thread Michael McCandless (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LUCENE-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-1442:
---

Attachment: LUCENE-1442.patch

Attached patch.  I plan to commit shortly.

> NOT_ANALYZED fields can double-count offsets
> 
>
> Key: LUCENE-1442
> URL: https://issues.apache.org/jira/browse/LUCENE-1442
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: Index
>Affects Versions: 2.4
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Attachments: LUCENE-1442.patch
>
>
> If the same field name has 2 NOT_ANALYZED field instances then the offsets 
> are double-counted.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (LUCENE-1441) KeywordTokenizer does not set start/end offset of the Token it produces

2008-11-07 Thread Michael McCandless (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LUCENE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless resolved LUCENE-1441.


   Resolution: Fixed
Fix Version/s: 2.9

Committed revision 712232.

> KeywordTokenizer does not set start/end offset of the Token it produces
> ---
>
> Key: LUCENE-1441
> URL: https://issues.apache.org/jira/browse/LUCENE-1441
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: Analysis
>Affects Versions: 2.3, 2.3.1, 2.3.2, 2.4
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1441.patch
>
>
> I think just adding these two lines in the next(Token) method is the right 
> fix:
>reusableToken.setStartOffset(0);
>reusableToken.setEndOffset(upto);
> I don't think this is a back compat issue because the start/end offset are 
> now meaningless since they will inherit whatever the reusable token had 
> previously been used for.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (LUCENE-1442) NOT_ANALYZED fields can double-count offsets

2008-11-07 Thread Michael McCandless (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LUCENE-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless resolved LUCENE-1442.


   Resolution: Fixed
Fix Version/s: 2.9

Committed revision 712233.

> NOT_ANALYZED fields can double-count offsets
> 
>
> Key: LUCENE-1442
> URL: https://issues.apache.org/jira/browse/LUCENE-1442
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: Index
>Affects Versions: 2.4
>Reporter: Michael McCandless
>Assignee: Michael McCandless
>Priority: Minor
> Fix For: 2.9
>
> Attachments: LUCENE-1442.patch
>
>
> If the same field name has 2 NOT_ANALYZED field instances then the offsets 
> are double-counted.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

RE: Broken javadocs->site docs links

2008-11-07 Thread Steven A Rowe 
On 11/07/2008 at 1:35 PM, Doug Cutting wrote:
> Steven A Rowe wrote:
> > This would not entirely fix the issue; each version's
> > javadocs should link to the same version of the site docs,
> > rather than to the latest version (which is what I assume you
> > mean here).
> 
> Right.  The javadocs should use a relative link to point to versioned
> docs.

I just discovered that simply changing the URLs to be relative won't do the 
trick either, since the javadocs exist in two forms: combined core+contrib, and 
separate core and contrib.  

The javadocs for o.a.l.search.Similarity has a working link to link to 
queryparsersyntax.html (link text: "query syntax"), as a result of using a 
relative URL, in the combined core+contrib form (the first URL below); however, 
the link is broken in the separate core form (the second URL below), because 
the number of parent path elements differs between the two:



 

Similarly, the MemoryIndex javadocs (which contain a link to 
queryparsersyntax.html) would have a broken link in one or the other of the two 
forms, if the absolute URL were changed to a relative URL:




A possible fix: the core+combined javadocs could add another path element, 
resulting in URLs like:




That way relative URLs would work for both the combined and separated forms, 
since they would have the same number of parent path elements.

> But, back to the issue at hand, fixing broken links in the
> javadocs on Hudson seems like a low priority.

Makes sense.  Perhaps a rewriting strategy similar to the .htaccess technique 
you mentioned earlier could eventually be employed.

Steve

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