[jira] [Updated] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[ https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phillipe Ramalho updated LUCENE-2979: - Attachment: LUCENE-2979_phillipe_ramalho_5_3x.patch Creating a junit for attributes was a good idea, I was able to find many problems. I spent the last three weeks working on them and reviewing the code. I think this is the last patch for this jira, it should be done now. Simplify configuration API of contrib Query Parser -- Key: LUCENE-2979 URL: https://issues.apache.org/jira/browse/LUCENE-2979 Project: Lucene - Java Issue Type: Improvement Components: modules/other Affects Versions: 2.9, 3.0 Reporter: Adriano Crestani Assignee: Adriano Crestani Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 3.4, 4.0 Attachments: LUCENE-2979_phillipe_ramalho_2.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_ramalho_4_3x.patch, LUCENE-2979_phillipe_ramalho_4_trunk.patch, LUCENE-2979_phillipe_ramalho_5_3x.patch, LUCENE-2979_phillipe_reamalho.patch The current configuration API is very complicated and inherit the concept used by Attribute API to store token information in token streams. However, the requirements for both (QP config and token stream) are not the same, so they shouldn't be using the same thing. I propose to simplify QP config and make it less scary for people intending to use contrib QP. The task is not difficult, it will just require a lot of code change and figure out the best way to do it. That's why it's a good candidate for a GSoC project. I would like to hear good proposals about how to make the API more friendly and less scaring :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[ https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phillipe Ramalho updated LUCENE-2979: - Attachment: LUCENE-2979_phillipe_ramalho_4_trunk.patch LUCENE-2979_phillipe_ramalho_4_3x.patch Here is a patch that backports the new configuration API to 3.x. I did exactly as I described in my proposal and it seems to be working as expected. I changed the documentation as well (I hope I everything, can you double check that Adriano?). I also created a simple example of how to use the new API in package.html and added to both 3.x and trunk. Please, let me know if everything looks good and if I didn't break any API. Simplify configuration API of contrib Query Parser -- Key: LUCENE-2979 URL: https://issues.apache.org/jira/browse/LUCENE-2979 Project: Lucene - Java Issue Type: Improvement Components: modules/other Affects Versions: 2.9, 3.0 Reporter: Adriano Crestani Assignee: Adriano Crestani Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 3.4, 4.0 Attachments: LUCENE-2979_phillipe_ramalho_2.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_ramalho_4_3x.patch, LUCENE-2979_phillipe_ramalho_4_trunk.patch, LUCENE-2979_phillipe_reamalho.patch The current configuration API is very complicated and inherit the concept used by Attribute API to store token information in token streams. However, the requirements for both (QP config and token stream) are not the same, so they shouldn't be using the same thing. I propose to simplify QP config and make it less scary for people intending to use contrib QP. The task is not difficult, it will just require a lot of code change and figure out the best way to do it. That's why it's a good candidate for a GSoC project. I would like to hear good proposals about how to make the API more friendly and less scaring :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[ https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13075974#comment-13075974 ] Phillipe Ramalho commented on LUCENE-2979: -- Hi Uwe, Is there anything to be fixed in 3352? I see it's a new feature JIRA. Am I missing something? Currently, I am only working on migrating the old to new API and doing no changes on how the configuration is used. So nothing here changes (at least should not) how ParametricQueryNodeProcessor works. Simplify configuration API of contrib Query Parser -- Key: LUCENE-2979 URL: https://issues.apache.org/jira/browse/LUCENE-2979 Project: Lucene - Java Issue Type: Improvement Components: modules/other Affects Versions: 2.9, 3.0 Reporter: Adriano Crestani Assignee: Adriano Crestani Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 3.4, 4.0 Attachments: LUCENE-2979_phillipe_ramalho_2.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_ramalho_4_3x.patch, LUCENE-2979_phillipe_ramalho_4_trunk.patch, LUCENE-2979_phillipe_reamalho.patch The current configuration API is very complicated and inherit the concept used by Attribute API to store token information in token streams. However, the requirements for both (QP config and token stream) are not the same, so they shouldn't be using the same thing. I propose to simplify QP config and make it less scary for people intending to use contrib QP. The task is not difficult, it will just require a lot of code change and figure out the best way to do it. That's why it's a good candidate for a GSoC project. I would like to hear good proposals about how to make the API more friendly and less scaring :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[ https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phillipe Ramalho updated LUCENE-2979: - Attachment: LUCENE-2979_phillipe_ramalho_2.patch As Adriano asked me, here is the first patch ready to be committed. It includes javadoc and package.html and overview.html updated based on the changes I made to the code. I am still working on integrating the new API with the old API. Simplify configuration API of contrib Query Parser -- Key: LUCENE-2979 URL: https://issues.apache.org/jira/browse/LUCENE-2979 Project: Lucene - Java Issue Type: Improvement Components: modules/other Affects Versions: 2.9, 3.0 Reporter: Adriano Crestani Assignee: Adriano Crestani Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 3.4, 4.0 Attachments: LUCENE-2979_phillipe_ramalho_2.patch, LUCENE-2979_phillipe_reamalho.patch The current configuration API is very complicated and inherit the concept used by Attribute API to store token information in token streams. However, the requirements for both (QP config and token stream) are not the same, so they shouldn't be using the same thing. I propose to simplify QP config and make it less scary for people intending to use contrib QP. The task is not difficult, it will just require a lot of code change and figure out the best way to do it. That's why it's a good candidate for a GSoC project. I would like to hear good proposals about how to make the API more friendly and less scaring :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Solr-3.x - Build # 394 - Failure
Hi, I am having similar problems. When running ant javadocs on contrib/queryparser, I get the following error: javadoc: warning - Error fetching URL: http://java.sun.com/j2se/1.6/docs/api/package-list and the script fails. What should I do? Is there are way to fix it? Thanks, Phillipe Ramalho On Wed, Jun 29, 2011 at 2:05 PM, Robert Muir rcm...@gmail.com wrote: On Wed, Jun 29, 2011 at 2:00 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : Failure to fetch junit's package list yet again... but Hoss is working : on this I think! I posted a straw-man patch, but i haven't relaly had time to seriously test it on modules/contrib ... and i thik rmuir had some reservations about putting the stuff in dev-tools ... but if someone is itching go ahead and commit. (i'm a little swamped right now) right, if the javadocs target in lucene/build.xml has a hard dependency on dev-tools, then the lucene source release won't work. but we could do some other things to fix this: * make this a soft dependency (e.g. the javadocs task will use dev-tools/plists when they are available, otherwise it downloads) * move dev-tools under lucene/ so we don't worry about this stuff * put the package-lists somewhere other than dev-tools (even if its just on hudson) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Phillipe Ramalho
[jira] [Updated] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[ https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phillipe Ramalho updated LUCENE-2979: - Attachment: LUCENE-2979_phillipe_ramalho_3.patch Hi Adriano, Sorry for that, I forgot to add javadoc to those comments, they are pretty important. Anyway, the problem was not really the missing javadoc, but javadoc was not understanding the link to inner classes (Class.InnerClass#Constant), I had to reference the inner class directly (InnerClass#Constant). However, there is a still a javadoc warning, I just sent an email to the mailing list, I hope you saw it already, where I report the problem. Here is the third patch with javadoc fixes. Simplify configuration API of contrib Query Parser -- Key: LUCENE-2979 URL: https://issues.apache.org/jira/browse/LUCENE-2979 Project: Lucene - Java Issue Type: Improvement Components: modules/other Affects Versions: 2.9, 3.0 Reporter: Adriano Crestani Assignee: Adriano Crestani Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 3.4, 4.0 Attachments: LUCENE-2979_phillipe_ramalho_2.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_reamalho.patch The current configuration API is very complicated and inherit the concept used by Attribute API to store token information in token streams. However, the requirements for both (QP config and token stream) are not the same, so they shouldn't be using the same thing. I propose to simplify QP config and make it less scary for people intending to use contrib QP. The task is not difficult, it will just require a lot of code change and figure out the best way to do it. That's why it's a good candidate for a GSoC project. I would like to hear good proposals about how to make the API more friendly and less scaring :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[ https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phillipe Ramalho updated LUCENE-2979: - Attachment: LUCENE-2979_phillipe_ramalho_3.patch oops, I had forgotten to check the ASF license. Simplify configuration API of contrib Query Parser -- Key: LUCENE-2979 URL: https://issues.apache.org/jira/browse/LUCENE-2979 Project: Lucene - Java Issue Type: Improvement Components: modules/other Affects Versions: 2.9, 3.0 Reporter: Adriano Crestani Assignee: Adriano Crestani Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 3.4, 4.0 Attachments: LUCENE-2979_phillipe_ramalho_2.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_ramalho_3.patch, LUCENE-2979_phillipe_reamalho.patch The current configuration API is very complicated and inherit the concept used by Attribute API to store token information in token streams. However, the requirements for both (QP config and token stream) are not the same, so they shouldn't be using the same thing. I propose to simplify QP config and make it less scary for people intending to use contrib QP. The task is not difficult, it will just require a lot of code change and figure out the best way to do it. That's why it's a good candidate for a GSoC project. I would like to hear good proposals about how to make the API more friendly and less scaring :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[ https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phillipe Ramalho updated LUCENE-2979: - Attachment: LUCENE-2979_phillipe_reamalho.patch This is finally my first patch. Sorry for taking so long, but I started changing the API and it broke a lot of code, which took forever to fix. Now it's working and all junits are passing. So far, I changed the entire configuration API. Next step is to write more junits and update/write javadocs. Simplify configuration API of contrib Query Parser -- Key: LUCENE-2979 URL: https://issues.apache.org/jira/browse/LUCENE-2979 Project: Lucene - Java Issue Type: Improvement Components: modules/other Affects Versions: 2.9, 3.0 Reporter: Adriano Crestani Assignee: Adriano Crestani Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 3.3 Attachments: LUCENE-2979_phillipe_reamalho.patch The current configuration API is very complicated and inherit the concept used by Attribute API to store token information in token streams. However, the requirements for both (QP config and token stream) are not the same, so they shouldn't be using the same thing. I propose to simplify QP config and make it less scary for people intending to use contrib QP. The task is not difficult, it will just require a lot of code change and figure out the best way to do it. That's why it's a good candidate for a GSoC project. I would like to hear good proposals about how to make the API more friendly and less scaring :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Fwd: Congratulations!
Hi everyone, It seems my project was accepted, I am looking forward to start coding for Lucene. Thanks! - Phillipe Ramalho -- Forwarded message -- From: no-re...@socghop.appspotmail.com Date: Mon, Apr 25, 2011 at 2:48 PM Subject: Congratulations! To: phillipe.rama...@gmail.com Dear Phillipe, Congratulations! Your proposal Lucene-2979: Simplify configuration API of contrib Query Parser as submitted to Apache Software Foundation has been accepted for Google Summer of Code 2011. Over the next few days, we will add you to the private Google Summer of Code Student Discussion List. Over the next few weeks, we will send instructions to this list regarding turn in proof of enrollment, tax forms, etc. Now that you've been accepted, please take the opportunity to speak with your mentors about plans for the Community Bonding Period: what documentation should you be reading, what version control system will you need to set up, etc., before start of coding begins on May 23rd. Welcome to Google Summer of Code 2011! We look forward to having you with us. With best regards, The Google Summer of Code Program Administration Team -- Phillipe Ramalho
[jira] [Commented] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[ https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13014953#comment-13014953 ] Phillipe Ramalho commented on LUCENE-2979: -- Hi Adriano, I finally submitted my proposal. Comments are welcome! Note that I used the title Lucene-2979: Simplify configuration API of contrib Query Parser in the proposal. I hope you can find it, not sure how I can reference it. Simplify configuration API of contrib Query Parser -- Key: LUCENE-2979 URL: https://issues.apache.org/jira/browse/LUCENE-2979 Project: Lucene - Java Issue Type: Improvement Components: contrib/* Affects Versions: 2.9, 3.0 Reporter: Adriano Crestani Assignee: Adriano Crestani Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 3.2, 4.0 The current configuration API is very complicated and inherit the concept used by Attribute API to store token information in token streams. However, the requirements for both (QP config and token stream) are not the same, so they shouldn't be using the same thing. I propose to simplify QP config and make it less scary for people intending to use contrib QP. The task is not difficult, it will just require a lot of code change and figure out the best way to do it. That's why it's a good candidate for a GSoC project. I would like to hear good proposals about how to make the API more friendly and less scaring :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[
https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012331#comment-13012331
]
Phillipe Ramalho commented on LUCENE-2979:
--
{quote}
Don't forget to describe how you plan make the old and new API work together.
{quote}
I will do, thanks for reminding me ;)
Simplify configuration API of contrib Query Parser
--
Key: LUCENE-2979
URL: https://issues.apache.org/jira/browse/LUCENE-2979
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/*
Affects Versions: 2.9, 3.0
Reporter: Adriano Crestani
Assignee: Adriano Crestani
Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor
Fix For: 3.2, 4.0
The current configuration API is very complicated and inherit the concept
used by Attribute API to store token information in token streams. However,
the requirements for both (QP config and token stream) are not the same, so
they shouldn't be using the same thing.
I propose to simplify QP config and make it less scary for people intending
to use contrib QP. The task is not difficult, it will just require a lot of
code change and figure out the best way to do it. That's why it's a good
candidate for a GSoC project.
I would like to hear good proposals about how to make the API more friendly
and less scaring :)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[
https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011539#comment-13011539
]
Phillipe Ramalho commented on LUCENE-2979:
--
Here are my initial thoughts:
There will be two types of config classes, as there is today, one for global
configuration and other for field configuration. The global config class will
hold reference to the field configurations. The field configuration will have
the field name. They both will extend a common class, which is some kind of map.
The key will be an special type (ConfigKey). This ConfigKey class will be final
and will receive a generic argument when constructed. The user will need to
define it and always use the same constants. To make sure the user uses it
correctly, we can enforce ConfigKey.equals to only return true when the same
instance is passed to equals method, so the map will only return the object for
that key when the defined key is used. Example:
{quote}
// developer code
final public static ConfigKeyString MY_CONFIG_KEY = new ConfigKeyString();
...
String myConfig = getConfig().get(MY_CONFIG_KEY);
/
// user code
getConfig().set(MY_CONFIG_KEY, value1); // works
getConfig().set(new ConfigKeyString(), value1); // does not work, as the
developer's code will look up for the key the developer has previously defined,
any other instance passed as key won't be found when the developer's code is
executed
{quote}
I couldn't find a way to do the generic capability above with Enum. Actually, I
don't see any reason to use Enum in this case.
Thoughts?
Simplify configuration API of contrib Query Parser
--
Key: LUCENE-2979
URL: https://issues.apache.org/jira/browse/LUCENE-2979
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/*
Affects Versions: 2.9, 3.0
Reporter: Adriano Crestani
Assignee: Adriano Crestani
Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11, mentor
Fix For: 3.2, 4.0
The current configuration API is very complicated and inherit the concept
used by Attribute API to store token information in token streams. However,
the requirements for both (QP config and token stream) are not the same, so
they shouldn't be using the same thing.
I propose to simplify QP config and make it less scary for people intending
to use contrib QP. The task is not difficult, it will just require a lot of
code change and figure out the best way to do it. That's why it's a good
candidate for a GSoC project.
I would like to hear good proposals about how to make the API more friendly
and less scaring :)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
GSoC 2011
Hello, I am planning to submit a project proposal to GSoC 2011 and Lucene seems to have a lot of GSoC projects this year. Last year I did a GSoC project using Lucene for PhotArk project. This year, instead of just using Lucene, I am planning to contribute code to it. My experience with Lucene is just as a regular user, the only code I have changed/extended so far was token streams/analyzers and query parser, so I have more knowledge on this part of the code. Based on that, I'm planning to focus on query parser and analyzer/token stream projects. Does that sound reasonable? I will be studying the code and planning the proposal(s), so you should start seeing more posts from me in the next few days. -- Phillipe Ramalho
[jira] [Commented] (LUCENE-2979) Simplify configuration API of contrib Query Parser
[
https://issues.apache.org/jira/browse/LUCENE-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009972#comment-13009972
]
Phillipe Ramalho commented on LUCENE-2979:
--
Hi,
I am considering doing a gsoc proposal about this, any specific points I should
be covering on the proposal?
I saw Adriano's comment on another LUCENE-1823:
{quote}
The map idea is really good and fits well as configuration for the QP, but I
would like to restrict the key type, so the user doesn't use a String object as
key. String keys may lead to runtime errors, mainly when they are inserted
inline. I would prefer to use enums as keys, it would enforce the user to
always pass the same object as key when referencing the same configuration. It
also avoids duplicated configuration keys, once each enum type has only one
instance per JVM.
If nobody complains about using a MapEnum?, Object as configuration for QP
framework, I will start working on a new patch including these changes soon.
{quote}
I will try to initially cover how we can use Map to replace the current config
API. Also I would like to cover how/whether we can make the new API compatible
with the old one, so users can migrate from old to new slowly, deprecating the
old one of course. I will also investigate the best way to enforce the user to
always pass the same key object. Also try to suggest an API that will allow the
users to retrieve the config values without casting them from Object, maybe
Java generic capability will enable it, but I am not sure it will work with
Enum.
Anything else I should be covering on the proposal?
Simplify configuration API of contrib Query Parser
--
Key: LUCENE-2979
URL: https://issues.apache.org/jira/browse/LUCENE-2979
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/*
Affects Versions: 2.9, 3.0
Reporter: Adriano Crestani
Labels: api-change, gsoc, gsoc2011, lucene-gsoc-11
Fix For: 3.2, 4.0
The current configuration API is very complicated and inherit the concept
used by Attribute API to store token information in token streams. However,
the requirements for both (QP config and token stream) are not the same, so
they shouldn't be using the same thing.
I propose to simplify QP config and make it less scary for people intending
to use contrib QP. The task is not difficult, it will just require a lot of
code change and figure out the best way to do it. That's why it's a good
candidate for a GSoC project.
I would like to hear good proposals about how to make the API more friendly
and less scaring :)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
