DO NOT REPLY [Bug 36219] New: - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219

   Summary: [PATCH] Submissiom form simple Romanian Analyzer
   Product: Lucene
   Version: unspecified
  Platform: PC
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Analysis
AssignedTo: java-dev@lucene.apache.org
ReportedBy: [EMAIL PROTECTED]


this is a simple addon which does just diacritics replacement.
no actual stemming in there yet.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36219] - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219





--- Additional Comments From [EMAIL PROTECTED]  2005-08-17 11:44 ---
Created an attachment (id=16076)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16076&action=view)
based on the german analyzer files

package should be changed to package org.apache.lucene.analysis.ro;

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36219] - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219





--- Additional Comments From [EMAIL PROTECTED]  2005-08-17 11:44 ---
Created an attachment (id=16077)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16077&action=view)
based on the german analyzer files

package should be changed to package org.apache.lucene.analysis.ro;

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36219] - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219





--- Additional Comments From [EMAIL PROTECTED]  2005-08-17 11:44 ---
Created an attachment (id=16078)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16078&action=view)
based on the german analyzer files

package should be changed to package org.apache.lucene.analysis.ro;

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36219] - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #16076|based on the german analyzer|RomanianAnalyzer based on
description|files   |the german analyzer files
  Attachment #16076|text/plain  |text/x-java
  mime type||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36219] - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #16077|based on the german analyzer|RomanianStemFilter based on
description|files   |the german analyzer files
  Attachment #16077|text/plain  |text/x-java
  mime type||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36219] - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #16078|based on the german analyzer|RomanianStemmer based on the
description|files   |german analyzer files
  Attachment #16078|text/plain  |text/x-java
  mime type||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36219] - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #16076|text/x-java |text/plain
  mime type||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36219] - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #16077|text/x-java |text/plain
  mime type||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36219] - [PATCH] Submissiom form simple Romanian Analyzer

[bugzilla]

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_bug.cgi?id=36219


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #16078|text/x-java |text/plain
  mime type||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

lucene API

[Maros Ivanco]

Hi there,

   I am creating a search solution based on Lucene. A part of the solution
   is Lucene web service. Even though the Lucene API is very straitforward
   to use on a local machine, I found creation of Lucene WS to be extremely
   difficult. The problem causes the API, which very often does not obey
   even trivial coding conventions (getter and setter names, for instance).
   As a result, the jax-rpc subsystem is unable to produce correct
   serializers and deserializers. From my point of view, there are serveral
   possibilities to solve the problem:

 1., write envelopes for nonserializable objects (Document, Field, Term,
 ...)
 2., write custom serializers and deserializers
 3., change lucene API

1. requires creation of many envelopes, since most of the Lucene classes do
not obey JavaBean semantics thus, they are not serializable by jax-rpc.
Wrapping and uwrapping of Lucene objects takes extra processing. Moreover,
the un/wrapping is sometimes not possible, because some objects (Filters,
for instance) do not exhibit their full state. I am doing this right now
(and doing, and doing,... I cannot see the end :-)).

2. requires creation of de/serializer for every nonserializable class. Also
requires extra configuration + generation of factories. Twice as difficult
as solution 1. Moreover, this solution renders resulting WS as nonportable.

3. requires change of lucene API in the way that will allow either direct
de/serialization or, at least, the solution 1. As far as Lucene is open
sourced, everybody can make changes, but the real question is, whether the
changes will become part of the official distribution. If not, the overall
search solution will remain stucked with current release.

I would personally prefer the third one, but only if the changes will make
it to the official release. Our company plans to deploy several instances
of the solution. There is certain probability, that my employer will
contribute some resources (my time) to the project. The question is,
whether the contemporary development comunity is willing to accept this
kind of changes and if I can participate. So, is it?

Maros.


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

RE: lucene API

[Robert Engels]

I think you should leave the API as is, and write a custom XML writer for
lucene search results. The request is trivial since you can simple pass the
single string. I would not write wrapper beans just to use the built-in
serialization support.

The custom XML writer will be MUCH, MUCH faster, as you do not need to
create an XML document first. The XML needed to support a Lucene search
result is quite trivial.

R

-Original Message-
From: Maros Ivanco [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 17, 2005 8:27 AM
To: java-dev@lucene.apache.org
Cc: Marek Baumerth
Subject: lucene API




Hi there,

   I am creating a search solution based on Lucene. A part of the solution
   is Lucene web service. Even though the Lucene API is very straitforward
   to use on a local machine, I found creation of Lucene WS to be extremely
   difficult. The problem causes the API, which very often does not obey
   even trivial coding conventions (getter and setter names, for instance).
   As a result, the jax-rpc subsystem is unable to produce correct
   serializers and deserializers. From my point of view, there are serveral
   possibilities to solve the problem:

 1., write envelopes for nonserializable objects (Document, Field, Term,
 ...)
 2., write custom serializers and deserializers
 3., change lucene API

1. requires creation of many envelopes, since most of the Lucene classes do
not obey JavaBean semantics thus, they are not serializable by jax-rpc.
Wrapping and uwrapping of Lucene objects takes extra processing. Moreover,
the un/wrapping is sometimes not possible, because some objects (Filters,
for instance) do not exhibit their full state. I am doing this right now
(and doing, and doing,... I cannot see the end :-)).

2. requires creation of de/serializer for every nonserializable class. Also
requires extra configuration + generation of factories. Twice as difficult
as solution 1. Moreover, this solution renders resulting WS as nonportable.

3. requires change of lucene API in the way that will allow either direct
de/serialization or, at least, the solution 1. As far as Lucene is open
sourced, everybody can make changes, but the real question is, whether the
changes will become part of the official distribution. If not, the overall
search solution will remain stucked with current release.

I would personally prefer the third one, but only if the changes will make
it to the official release. Our company plans to deploy several instances
of the solution. There is certain probability, that my employer will
contribute some resources (my time) to the project. The question is,
whether the contemporary development comunity is willing to accept this
kind of changes and if I can participate. So, is it?

Maros.


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

Re: lucene API

[Daniel Naber]

On Wednesday 17 August 2005 15:26, Maros Ivanco wrote:

> I would personally prefer the third one, but only if the changes will
> make it to the official release.

Whether a patch is accepted can obviously only be decided when we see the 
patch, so no promises can be made.

Regards
 Daniel

-- 
http://www.danielnaber.de

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

[ANN] Lucene "Did You Mean" article on java.net

[Tom White]

In case subscribers to this list missed it, my article on how to add a
"did you mean" facility to Lucene searches was published last week:
http://today.java.net/pub/a/today/2005/08/09/didyoumean.html.

Regards,

Tom

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

Re: [ANN] Lucene "Did You Mean" article on java.net

[Erik Hatcher]

Great article, Tom!   Thanks - I had meant to post it to the list  
myself.  You ought to post it on [EMAIL PROTECTED] as well, as most  
folks are there instead of here.


Erik


On Aug 17, 2005, at 5:58 PM, Tom White wrote:


In case subscribers to this list missed it, my article on how to add a
"did you mean" facility to Lucene searches was published last week:
http://today.java.net/pub/a/today/2005/08/09/didyoumean.html.

Regards,

Tom

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

Re: lucene API

[Erik Hatcher]

When I first started digging into the Lucene codebase, I felt  
similarly - the coding convention rule breaking drove me nuts.   
Lucene grew on me and I've changed my take on "conventions"  
dramatically thanks to Doug's explanations and the flavor he has  
imparted onto the codebase.  His "conventions" have changed how I code.


If JAX-RPC has issues with Lucene, it is more an issue with JAX-RPC  
than with Lucene.  There are sound reasons for the design of Lucene's  
API and the (non)serializability of most pieces of it.  What about  
the Sourceforge Lucene web service project?  Would using that rather  
than creating your own solution be reasonable?


Erik


On Aug 17, 2005, at 9:26 AM, Maros Ivanco wrote:




Hi there,

   I am creating a search solution based on Lucene. A part of the  
solution
   is Lucene web service. Even though the Lucene API is very  
straitforward
   to use on a local machine, I found creation of Lucene WS to be  
extremely
   difficult. The problem causes the API, which very often does not  
obey
   even trivial coding conventions (getter and setter names, for  
instance).

   As a result, the jax-rpc subsystem is unable to produce correct
   serializers and deserializers. From my point of view, there are  
serveral

   possibilities to solve the problem:

 1., write envelopes for nonserializable objects (Document, Field,  
Term,

 ...)
 2., write custom serializers and deserializers
 3., change lucene API

1. requires creation of many envelopes, since most of the Lucene  
classes do
not obey JavaBean semantics thus, they are not serializable by jax- 
rpc.
Wrapping and uwrapping of Lucene objects takes extra processing.  
Moreover,
the un/wrapping is sometimes not possible, because some objects  
(Filters,
for instance) do not exhibit their full state. I am doing this  
right now

(and doing, and doing,... I cannot see the end :-)).

2. requires creation of de/serializer for every nonserializable  
class. Also
requires extra configuration + generation of factories. Twice as  
difficult
as solution 1. Moreover, this solution renders resulting WS as  
nonportable.


3. requires change of lucene API in the way that will allow either  
direct
de/serialization or, at least, the solution 1. As far as Lucene is  
open
sourced, everybody can make changes, but the real question is,  
whether the
changes will become part of the official distribution. If not, the  
overall

search solution will remain stucked with current release.

I would personally prefer the third one, but only if the changes  
will make
it to the official release. Our company plans to deploy several  
instances

of the solution. There is certain probability, that my employer will
contribute some resources (my time) to the project. The question is,
whether the contemporary development comunity is willing to accept  
this

kind of changes and if I can participate. So, is it?

Maros.


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