[jira] Updated: (LUCENE-2957) generate-maven-artifacts target should include all non-Mavenized Lucene & Solr dependencies
[
https://issues.apache.org/jira/browse/LUCENE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-2957:
Description:
Currently, in addition to deploying artifacts for all of the Lucene and Solr
modules to a repository (by default local), the {{generate-maven-artifacts}}
target also deploys artifacts for the following non-Mavenized Solr dependencies
(lucene_solr_3_1 version given here):
# {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
org.apache.solr:solr-commons-csv:3.1
# {{solr/lib/apache-solr-noggit-r944541.jar}} as org.apache.solr:solr-noggit:3.1
\\ \\
The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
version given here):
\\ \\
# {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
# {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
# {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
# {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
# {{solr/contrib/uima/lib/uima-an-calais.jar}}
# {{solr/contrib/uima/lib/uima-an-tagger.jar}}
# {{solr/contrib/uima/lib/uima-an-wst.jar}}
# {{solr/contrib/uima/lib/uima-core.jar}}
\\ \\
I think it makes sense to follow the same model as the current non-Mavenized
dependencies:
\\ \\
* {{groupId}} = {{org.apache.solr/.lucene}}
* {{artifactId}} = {{solr-/lucene-}},
* {{version}} = .
**The carrot2-core jar doesn't need to be included in trunk's release
artifacts, since there already is a Mavenized Java6-compiled jar. branch_3x
and lucene_solr_3_1 will need this Solr-specific Java5-compiled maven artifact,
though.
was:
Currently, in addition to deploying artifacts for all of the Lucene and Solr
modules to a repository (by default local), the {{generate-maven-artifacts}}
target also deploys artifacts for the following non-Mavenized Solr dependencies
(lucene_solr_3_1 version given here):
# {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
org.apache.solr:solr-commons-csv:3.1
# {{solr/lib/apache-solr-noggit-r944541.jar}} as org.apache.solr:solr-noggit:3.1
\\ \\
The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
version given here):
\\ \\
# {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
# {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
# {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
# {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
# {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
# {{solr/contrib/uima/lib/uima-an-calais.jar}}
# {{solr/contrib/uima/lib/uima-an-tagger.jar}}
# {{solr/contrib/uima/lib/uima-an-wst.jar}}
# {{solr/contrib/uima/lib/uima-core.jar}}
\\ \\
I think it makes sense to follow the same model as the current non-Mavenized
dependencies:
\\ \\
* {{groupId}} = {{org.apache.solr/.lucene}}
* {{artifactId}} = {{solr-/lucene-}},
* {{version}} = .
**The carrot2-core jar doesn't need to be included in trunk's release
artifacts, since there already is a Mavenized Java6-compiled jar. branch_3x
and lucene_solr_3_1 will need this Solr-specific Java5-compiled maven artifact,
though.
Removed {{xml-apis-2.9.0.jar}} from the list of publishable dependencies
because it's being removed by LUCENE-2961
> generate-maven-artifacts target should include all non-Mavenized Lucene &
> Solr dependencies
> ---
>
> Key: LUCENE-2957
> URL: https://issues.apache.org/jira/browse/LUCENE-2957
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Build
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
>
> Currently, in addition to deploying artifacts for all of the Lucene and Solr
> modules to a repository (by default local), the {{generate-maven-artifacts}}
> target also deploys artifacts for the following non-Mavenized Solr
> dependencies (lucene_solr_3_1 version given here):
> # {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
> org.apache.solr:solr-commons-csv:3.1
> # {{solr/lib/apache-solr-noggit-r944541.jar}} as
> org.apache.solr:solr-noggit:3.1
> \\ \\
> The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
> version given here):
> \\ \\
> # {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
> #
> {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
> # {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
> # {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
> # {{solr/contrib/uima/lib/uima-an-calais.jar}}
> # {{solr/contrib/uima/lib/uima-an-tagger.jar}}
> # {{solr/contrib/uima/lib/uima-an-wst.jar}}
> # {{solr/contrib/uima/lib/uima-core.jar}}
> \\ \\
> I think it makes sense to follow the same model as the current non-Mavenized
> dependencies:
> \\ \\
> * {{groupId}} = {{org.apache.solr/.lucene}}
> * {{artifactId}} = {{solr-/lucene-}},
> * {{version}} = .
Re: Participation
On Mar 10, 2011, at 10:49 AM, Elmar Pitschke wrote: > Hi all, > i am using Lucene for quite some time now at my work and it is a > quite amazing software. As i have now submitted my PhD, i am searching > for a new things i could do in my spare time. So as i am frequently > using the software and i am an experiences Java programmer i would > like to make my contributions. So my question now is, where to start. > Could you give me a hint for example to an Jira issue which needs to > be fixed? > I hope i can be of some help :) Sounds great! The best way to get started is to start looking at open issues in JIRA and tackling any that scratch your fancy. https://issues.apache.org/jira/browse/LUCENE#selectedTab=com.atlassian.jira.plugin.system.project%3Asummary-panel For some suggestions, you might cheat by first taking a look at the issues that have been labeled as good candidates for Google Summer of Code. Any of those might be a good way to get started. https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+12310110+AND+labels+%3D+gsoc2011 The best advice is to just start communicating on the list, following JIRA issues you are interested in, and contributing patches/discussion where it makes sense. You will quickly get a sense of which issues might make sense to work on. It's also a good idea to follow and participate in the user lists. Good luck and welcome to the Lucene community! > Regards > Elmar > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - Mark Miller lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-2961) Remove benchmark/lib/xml-apis.jar - JVM 1.5 already contains the required JAXP 1.3 implementation
[
https://issues.apache.org/jira/browse/LUCENE-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-2961:
Lucene Fields: [New, Patch Available] (was: [New])
> Remove benchmark/lib/xml-apis.jar - JVM 1.5 already contains the required
> JAXP 1.3 implementation
> -
>
> Key: LUCENE-2961
> URL: https://issues.apache.org/jira/browse/LUCENE-2961
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/benchmark
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
> Attachments: LUCENE-2961.patch
>
>
> On
> [LUCENE-2957|https://issues.apache.org/jira/browse/LUCENE-2957?focusedCommentId=13004991&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004991],
> Uwe wrote:
> {quote}
> xml-apis.jar is not needed with xerces-2.9 and Java 5, as Java 5 already has
> these interface classes (JAXP 1.3). Xerces 2.11 needs it, because it ships
> with Java 6's JAXP release (containing STAX & Co. not available in Java 5).
> {quote}
> On the #lucene IRC channel, Uwe also wrote:
> {noformat}
> since we are on java 5 since 3.0
> we have the javax APIs already available in the JVM
> xerces until 2.9.x only needs JAXP 1.3
> so the only thing you need is xercesImpl.jar
> and serializer.jar
> serializer.jar is shared between all apache xml projects, dont know the exact
> version number
> ok you dont need it whan you only parse xml
> as soon as you want to serialize a dom tree or result of an xsl
> transformation you need it
> [...]
> but if we upgrade to latest xerces we need it [the xml-apis jar] again unless
> we are on java 6
> so the one shipped with xerces 2.11 is the 1.4 one
> because xerces 2.11 supports Stax
> {noformat}
--
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] Assigned: (LUCENE-2961) Remove benchmark/lib/xml-apis.jar - JVM 1.5 already contains the required JAXP 1.3 implementation
[
https://issues.apache.org/jira/browse/LUCENE-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe reassigned LUCENE-2961:
---
Assignee: Steven Rowe
> Remove benchmark/lib/xml-apis.jar - JVM 1.5 already contains the required
> JAXP 1.3 implementation
> -
>
> Key: LUCENE-2961
> URL: https://issues.apache.org/jira/browse/LUCENE-2961
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/benchmark
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
> Attachments: LUCENE-2961.patch
>
>
> On
> [LUCENE-2957|https://issues.apache.org/jira/browse/LUCENE-2957?focusedCommentId=13004991&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004991],
> Uwe wrote:
> {quote}
> xml-apis.jar is not needed with xerces-2.9 and Java 5, as Java 5 already has
> these interface classes (JAXP 1.3). Xerces 2.11 needs it, because it ships
> with Java 6's JAXP release (containing STAX & Co. not available in Java 5).
> {quote}
> On the #lucene IRC channel, Uwe also wrote:
> {noformat}
> since we are on java 5 since 3.0
> we have the javax APIs already available in the JVM
> xerces until 2.9.x only needs JAXP 1.3
> so the only thing you need is xercesImpl.jar
> and serializer.jar
> serializer.jar is shared between all apache xml projects, dont know the exact
> version number
> ok you dont need it whan you only parse xml
> as soon as you want to serialize a dom tree or result of an xsl
> transformation you need it
> [...]
> but if we upgrade to latest xerces we need it [the xml-apis jar] again unless
> we are on java 6
> so the one shipped with xerces 2.11 is the 1.4 one
> because xerces 2.11 supports Stax
> {noformat}
--
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
Participation
Hi all, i am using Lucene for quite some time now at my work and it is a quite amazing software. As i have now submitted my PhD, i am searching for a new things i could do in my spare time. So as i am frequently using the software and i am an experiences Java programmer i would like to make my contributions. So my question now is, where to start. Could you give me a hint for example to an Jira issue which needs to be fixed? I hope i can be of some help :) Regards Elmar - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-2961) Remove benchmark/lib/xml-apis.jar - JVM 1.5 already contains the required JAXP 1.3 implementation
[
https://issues.apache.org/jira/browse/LUCENE-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-2961:
Attachment: LUCENE-2961.patch
Patch against trunk removing xml-apis-2.9.0.jar.
/lucene and /modules compile and successfully pass all tests under Java 1.5.
All tests (including Solr) pass under Java 1.6.
I plan on committing shortly.
> Remove benchmark/lib/xml-apis.jar - JVM 1.5 already contains the required
> JAXP 1.3 implementation
> -
>
> Key: LUCENE-2961
> URL: https://issues.apache.org/jira/browse/LUCENE-2961
> Project: Lucene - Java
> Issue Type: Improvement
> Components: contrib/benchmark
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
> Attachments: LUCENE-2961.patch
>
>
> On
> [LUCENE-2957|https://issues.apache.org/jira/browse/LUCENE-2957?focusedCommentId=13004991&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004991],
> Uwe wrote:
> {quote}
> xml-apis.jar is not needed with xerces-2.9 and Java 5, as Java 5 already has
> these interface classes (JAXP 1.3). Xerces 2.11 needs it, because it ships
> with Java 6's JAXP release (containing STAX & Co. not available in Java 5).
> {quote}
> On the #lucene IRC channel, Uwe also wrote:
> {noformat}
> since we are on java 5 since 3.0
> we have the javax APIs already available in the JVM
> xerces until 2.9.x only needs JAXP 1.3
> so the only thing you need is xercesImpl.jar
> and serializer.jar
> serializer.jar is shared between all apache xml projects, dont know the exact
> version number
> ok you dont need it whan you only parse xml
> as soon as you want to serialize a dom tree or result of an xsl
> transformation you need it
> [...]
> but if we upgrade to latest xerces we need it [the xml-apis jar] again unless
> we are on java 6
> so the one shipped with xerces 2.11 is the 1.4 one
> because xerces 2.11 supports Stax
> {noformat}
--
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] Created: (LUCENE-2961) Remove benchmark/lib/xml-apis.jar - JVM 1.5 already contains the required JAXP 1.3 implementation
Remove benchmark/lib/xml-apis.jar - JVM 1.5 already contains the required JAXP
1.3 implementation
-
Key: LUCENE-2961
URL: https://issues.apache.org/jira/browse/LUCENE-2961
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/benchmark
Affects Versions: 3.1, 3.2, 4.0
Reporter: Steven Rowe
Priority: Minor
Fix For: 3.1, 3.2, 4.0
On
[LUCENE-2957|https://issues.apache.org/jira/browse/LUCENE-2957?focusedCommentId=13004991&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13004991],
Uwe wrote:
{quote}
xml-apis.jar is not needed with xerces-2.9 and Java 5, as Java 5 already has
these interface classes (JAXP 1.3). Xerces 2.11 needs it, because it ships with
Java 6's JAXP release (containing STAX & Co. not available in Java 5).
{quote}
On the #lucene IRC channel, Uwe also wrote:
{noformat}
since we are on java 5 since 3.0
we have the javax APIs already available in the JVM
xerces until 2.9.x only needs JAXP 1.3
so the only thing you need is xercesImpl.jar
and serializer.jar
serializer.jar is shared between all apache xml projects, dont know the exact
version number
ok you dont need it whan you only parse xml
as soon as you want to serialize a dom tree or result of an xsl transformation
you need it
[...]
but if we upgrade to latest xerces we need it [the xml-apis jar] again unless
we are on java 6
so the one shipped with xerces 2.11 is the 1.4 one
because xerces 2.11 supports Stax
{noformat}
--
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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5773 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5773/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8447 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2562) Make Luke a Lucene/Solr Module
[ https://issues.apache.org/jira/browse/LUCENE-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005069#comment-13005069 ] Mark Miller commented on LUCENE-2562: - Yeah, that would be great! Either way, I have def not abandoned this - just don't know when it will get more love... > Make Luke a Lucene/Solr Module > -- > > Key: LUCENE-2562 > URL: https://issues.apache.org/jira/browse/LUCENE-2562 > Project: Lucene - Java > Issue Type: Task >Reporter: Mark Miller > Labels: gsoc2011, lucene-gsoc-11 > Attachments: luke1.jpg, luke2.jpg, luke3.jpg > > > see > http://search.lucidimagination.com/search/document/ee0e048c6b56ee2/luke_in_need_of_maintainer > http://search.lucidimagination.com/search/document/5e53136b7dcb609b/web_based_luke > I think it would be great if there was a version of Luke that always worked > with trunk - and it would also be great if it was easier to match Luke jars > with Lucene versions. > While I'd like to get GWT Luke into the mix as well, I think the easiest > starting point is to straight port Luke to another UI toolkit before > abstracting out DTO objects that both GWT Luke and Pivot Luke could share. > I've started slowly converting Luke's use of thinlet to Apache Pivot. I > haven't/don't have a lot of time for this at the moment, but I've plugged > away here and there over the past work or two. There is still a *lot* to do. -- 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-2952) Make license checking/maintenance easier/automated
[ https://issues.apache.org/jira/browse/LUCENE-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated LUCENE-2952: Attachment: LUCENE-2952.patch No where near being ready, but putting up something to flesh this out a little bit. I don't think it even compiles yet. Idea: Add dev-tools/validation and hook in code into it that does work to validate our systems for things like licenses, etc. It will then be hooked in at compile time for both Lucene and Solr. In this particular case, it will look for license files for each jar file and fail if one is missing. This requires there to be, for every JAR file, a file with the same name and the name of the license.txt appended to it, as in foo.jar.BSD.txt or something like that (still being worked out) > Make license checking/maintenance easier/automated > -- > > Key: LUCENE-2952 > URL: https://issues.apache.org/jira/browse/LUCENE-2952 > Project: Lucene - Java > Issue Type: Improvement >Reporter: Grant Ingersoll >Priority: Minor > Attachments: LUCENE-2952.patch > > > Instead of waiting until release to check licenses are valid, we should make > it a part of our build process to ensure that all dependencies have proper > licenses, etc. -- 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-2957) generate-maven-artifacts target should include all non-Mavenized Lucene & Solr dependencies
[
https://issues.apache.org/jira/browse/LUCENE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005057#comment-13005057
]
Steven Rowe commented on LUCENE-2957:
-
{quote}
Hi Steven. Would it help a lot if we released a Java 1.5 version of Carrot2
3.4.3? I would have to try to retrotranslate it manually, but I guess it'd be
possible – we don't use that many Java 1.6 specific methods.
{quote}
Dawid, Solr 3.x requires Java 1.5. For Solr 3.1, we will not be upgrading the
Carrot2 library, since it's so close to the release, so it would not help for
the release.
But for Solr 3.2, which will very likely be the next release, and which will
still require Java 1.5, a Mavenized (i.e. published in a Maven repository) Java
1.5 version of Carrot2 3.4.3 would definitely be useful.
A Mavenized Java 1.5-compiled 3.4.2 version would be useful for the 3.1
release, but it's understandable if you don't want to do this work for an older
version.
> generate-maven-artifacts target should include all non-Mavenized Lucene &
> Solr dependencies
> ---
>
> Key: LUCENE-2957
> URL: https://issues.apache.org/jira/browse/LUCENE-2957
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Build
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
>
> Currently, in addition to deploying artifacts for all of the Lucene and Solr
> modules to a repository (by default local), the {{generate-maven-artifacts}}
> target also deploys artifacts for the following non-Mavenized Solr
> dependencies (lucene_solr_3_1 version given here):
> # {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
> org.apache.solr:solr-commons-csv:3.1
> # {{solr/lib/apache-solr-noggit-r944541.jar}} as
> org.apache.solr:solr-noggit:3.1
> \\ \\
> The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
> version given here):
> \\ \\
> # {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
> #
> {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
> # {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
> # {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
> # {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
> # {{solr/contrib/uima/lib/uima-an-calais.jar}}
> # {{solr/contrib/uima/lib/uima-an-tagger.jar}}
> # {{solr/contrib/uima/lib/uima-an-wst.jar}}
> # {{solr/contrib/uima/lib/uima-core.jar}}
> \\ \\
> I think it makes sense to follow the same model as the current non-Mavenized
> dependencies:
> \\ \\
> * {{groupId}} = {{org.apache.solr/.lucene}}
> * {{artifactId}} = {{solr-/lucene-}},
> * {{version}} = .
> **The carrot2-core jar doesn't need to be included in trunk's release
> artifacts, since there already is a Mavenized Java6-compiled jar. branch_3x
> and lucene_solr_3_1 will need this Solr-specific Java5-compiled maven
> artifact, though.
--
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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5772 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5772/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8477 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-2958) WriteLineDocTask improvements
[ https://issues.apache.org/jira/browse/LUCENE-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-2958: Attachment: LUCENE-2958.patch Updated patch (for 3x): - from 3x root (previous patch was from benchmark by mistake) - fixed typos in javadoc - simplified loop over the fields in WriteLineDocTask - removed *volatile* but added *final* for *fields/ToWrite*. Without volatile one test was failing: TestPerfTasksLogic.testParallelDocMaker() but then I was unable to fail it again even after removing volatile. Once marking these fields *final* definitely volatile is not required. But I don't understand why was it needed in the first place - ParallelTask in TaskSequence clones the tasks, and since WriteLineDocTask does not implement clone() all (parallel) tasks will have a reference to same array... which in fact can be copied into a local copy by the JVM for efficiency.. but since the clone must take place only after the constructor is done, the array is initialized already... If I could fail this again I would investigate it but now it always passes even without final/volatile. So keeping the final, as this is safe, but I don't like the voodooism of it and if anyone has a better explanation it would be appreciated. > WriteLineDocTask improvements > - > > Key: LUCENE-2958 > URL: https://issues.apache.org/jira/browse/LUCENE-2958 > Project: Lucene - Java > Issue Type: Improvement > Components: contrib/benchmark >Reporter: Doron Cohen >Assignee: Doron Cohen >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: LUCENE-2958.patch, LUCENE-2958.patch > > > Make WriteLineDocTask and LineDocSource more flexible/extendable: > * allow to emit lines also for empty docs (keep current behavior as default) > * allow more/less/other fields -- 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: IndexWriter#setRAMBufferSizeMB removed in trunk
IWC simplified IW creation - now there is only one ctor, where before there were multiple ones, and some settings could only be changed after IW was created. With IWC, our code is (can become) simpler -- e.g. RAM buffer size, if specified up front is one thing, but if it's dynamic, we need to have code which dynamically increases or decreases it. Increasing is not the problem, but decreasing requires special code that flushes and discards the extra memory. Maybe the code already exists, I haven't checked. I don't like setters that are all over the place either. Having said that though, today the setters are inconsistent -- some are 'static' (meaning, cannot change after IW created) while some are dynamic, such as the MergePolicy settings. Because MP responds to those setters. One thing we can do is keep all the setters in IWC and have IW pass itself to IWC after creation. Then, we can modify certain settings in IWC to notify IW of these changes. But it's complicated. Another thing is separate some runtime settings from IWC and include them in IW, like we do for MP ... that's what's been suggested. But then, what is a 'runtime' setting? Someone can decide to have IndexDeletionPolicy change 'on-the-fly' in his app -- does it make sense that we make IDP a runtime setting? I don't think so. In fact, I don't think RAM buffer is changed that dynamically by applications (or any other setter). Elastic search may have a use case where it's needed, that's ok. If this setting does not change very often, it can still close IW and reopen it with the new settings, right? A third solution is to keep IWC for construction time, but introduce the setters back on IW for runtime changes.That way we keep IW ctor simple but still allow apps to change on-the-fly settings. We'll dup setters which I don't like ... Shai On Thu, Mar 10, 2011 at 2:47 PM, Robert Muir wrote: > On Thu, Mar 10, 2011 at 7:41 AM, Shay Banon wrote: > > I am not sure that IndexWriterConfig is bad. Its nice to be able to set > all > > the upfront configurations in a single object and pass it to the > > IndexWriter. And, have the IndexWriter allow for specific setters > allowing > > for real time changes (those should not be done through the > > IndexWriterConfig). > > The question is which real time changes are allowed or not. The fact that > > they are separated (IndexWriterConfig, and real time setters) is good > since > > it allows to distinguish between what can be set when setting up an > > IndexWriter, compared to what can be set in real time. We did not have > this > > distinction before the IndexWriterConfig was introduced. > > This open the door for optimizations for things that can only be set when > > constructing an IndexWriter. Usually, supporting real time changes can > > hinder concurrency, while having parameters that are basically immutable > > allows to optimize in this case. > > -shay.banon > > > > I disagree that its good if things are separate... Instead of API > confusion I think I would prefer a single method on IW that "best > effort" tries to apply any "realtime" setters > > This way we can avoid constant deprecation and undeprecation between > these APIs. Instead, whether something can be changed on the fly is > only a documentation issue. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5771 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5771/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8483 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: IndexWriter#setRAMBufferSizeMB removed in trunk
On Thu, Mar 10, 2011 at 7:41 AM, Shay Banon wrote: > I am not sure that IndexWriterConfig is bad. Its nice to be able to set all > the upfront configurations in a single object and pass it to the > IndexWriter. And, have the IndexWriter allow for specific setters allowing > for real time changes (those should not be done through the > IndexWriterConfig). > The question is which real time changes are allowed or not. The fact that > they are separated (IndexWriterConfig, and real time setters) is good since > it allows to distinguish between what can be set when setting up an > IndexWriter, compared to what can be set in real time. We did not have this > distinction before the IndexWriterConfig was introduced. > This open the door for optimizations for things that can only be set when > constructing an IndexWriter. Usually, supporting real time changes can > hinder concurrency, while having parameters that are basically immutable > allows to optimize in this case. > -shay.banon > I disagree that its good if things are separate... Instead of API confusion I think I would prefer a single method on IW that "best effort" tries to apply any "realtime" setters This way we can avoid constant deprecation and undeprecation between these APIs. Instead, whether something can be changed on the fly is only a documentation issue. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: IndexWriter#setRAMBufferSizeMB removed in trunk
I am not sure that IndexWriterConfig is bad. Its nice to be able to set all the upfront configurations in a single object and pass it to the IndexWriter. And, have the IndexWriter allow for specific setters allowing for real time changes (those should not be done through the IndexWriterConfig). The question is which real time changes are allowed or not. The fact that they are separated (IndexWriterConfig, and real time setters) is good since it allows to distinguish between what can be set when setting up an IndexWriter, compared to what can be set in real time. We did not have this distinction before the IndexWriterConfig was introduced. This open the door for optimizations for things that can only be set when constructing an IndexWriter. Usually, supporting real time changes can hinder concurrency, while having parameters that are basically immutable allows to optimize in this case. -shay.banon On Thursday, March 10, 2011 at 2:28 PM, Robert Muir wrote: On Thu, Mar 10, 2011 at 6:49 AM, Michael McCandless > wrote: > > > Can you open an issue? Make sure it's marked fix 4.0/3.2! Thanks. > > I'm not sure we should handle it this way: I really don't like > deprecation in one release and undeprecation in another. > So, I think we should open an issue for 3.1 and figure out if we want > to do this for setters at all. > If we decide to start moving setters out of IndexWriterConfig, then we > need to start asking very hard questions about IndexWriterConfig as a > whole, because I think it will be confusing if IndexWriter has two > separate configuration APIs. > This should block the release: if IndexWriterConfig is a broken design > then we need to revert this now before its released, not make users > switch over and then undeprecate/revert in a future release. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5770 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5770/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8466 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: IndexWriter#setRAMBufferSizeMB removed in trunk
Hi, On Thursday, March 10, 2011 at 1:49 PM, Michael McCandless wrote: > Hi Shay, > > It sounds like we should put this (ability to change RAM buffer on the > fly) back. > > But, can you describe how/why you need this? Is it because you have > many IWs open at once and you want to dynamically change which gets to > use RAM? Exactly. In elasticsearch, there can be several shards (each a Lucene index) running in the same VM. You can configure that you want 10% of the heap to be allocated to indexing, and it will automatically distribute it between all the shards by dynamically changing that value on each IndexWriter. > > > Are there other settings that were moved to IWC that you also > dynamically change today...? I think most can, and should, be set on the MergePolicy itself. The two that I miss as well are settings the term index interval, and reader terms divisor. > > > Can you open an issue? Make sure it's marked fix 4.0/3.2! Thanks. Done: https://issues.apache.org/jira/browse/LUCENE-2960. > > > Mike > > On Wed, Mar 9, 2011 at 1:01 AM, Shay Banon wrote: > > Heya, > > I think the ability to change the RAMBufferSizeMB on a live IndexWriter > > (without the need to close and open it) is an important one, and it seems > > like tis deprecated on 3.1 and removed in trunk. Is there a chance to get it > > back? > > -shay.banon > > > > -- > Mike > > http://blog.mikemccandless.com >
Re: IndexWriter#setRAMBufferSizeMB removed in trunk
On Thu, Mar 10, 2011 at 6:49 AM, Michael McCandless wrote: > Can you open an issue? Make sure it's marked fix 4.0/3.2! Thanks. > I'm not sure we should handle it this way: I really don't like deprecation in one release and undeprecation in another. So, I think we should open an issue for 3.1 and figure out if we want to do this for setters at all. If we decide to start moving setters out of IndexWriterConfig, then we need to start asking very hard questions about IndexWriterConfig as a whole, because I think it will be confusing if IndexWriter has two separate configuration APIs. This should block the release: if IndexWriterConfig is a broken design then we need to revert this now before its released, not make users switch over and then undeprecate/revert in a future release. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (LUCENE-2960) Allow (or bring back) the ability to setRAMBufferSizeMB on an open IndexWriter
Allow (or bring back) the ability to setRAMBufferSizeMB on an open IndexWriter -- Key: LUCENE-2960 URL: https://issues.apache.org/jira/browse/LUCENE-2960 Project: Lucene - Java Issue Type: Improvement Components: Index Reporter: Shay Banon Fix For: 3.2, 4.0 In 3.1 the ability to setRAMBufferSizeMB is deprecated, and removed in trunk. It would be great to be able to control that on a live IndexWriter. Other possible two methods that would be great to bring back are setTermIndexInterval and setReaderTermsIndexDivisor. Most of the other setters can actually be set on the MergePolicy itself, so no need for setters for those (I think). -- 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: GSoC
awesome thanks! simon On Thu, Mar 10, 2011 at 11:54 AM, David Nemeskey wrote: > Ok, I have created a new issue, LUCENE-2959 for this project. I have uploaded > the pdfs and added the gsoc2011 and lucene-gsoc-2011 labels as well. > > David > > On 2011 March 09, Wednesday 21:58:53 Simon Willnauer wrote: >> On Wed, Mar 9, 2011 at 5:48 PM, Grant Ingersoll wrote: >> > I think we, Lucene committers, need to identify who is willing to mentor. >> > In my experience, it is less than 5 hours a week. Most of the work >> > is done as part of the community. Sometimes you have to be tough and >> > fail someone (I did last year) but most of the time, if you take the >> > time to interview the candidates up front, it is a good experience for >> > everyone. >> >> count me in >> >> > I'd add it would be useful to have everyone put the lucene-gsoc-11 label >> > on their issues too, that way we can quickly find the Lucene ones. >> >> done on at least one ;) >> >> simon >> >> > Also, feel free to label existing bugs. >> > >> > On Mar 9, 2011, at 2:11 AM, Simon Willnauer wrote: >> >> Hey David and all others who want to contribute to GSoC, >> >> >> >> the ASF has applied for GSoC 2011 as a mentoring organization. As a >> >> ASF project we don't need to apply directly though but we need to >> >> register our ideas now. This works like almost anything in the ASF >> >> through JIRA. All ideas should be recorded as JIRA tickets labeled >> >> with "gsoc2011". Once this is done it will show up here: >> >> http://s.apache.org/gsoc2011tasks >> >> >> >> Everybody who is interested in GSoC as a mentor or student should now >> >> read this too http://community.apache.org/gsoc.html >> >> >> >> >> >> Thanks, >> >> >> >> Simon >> >> >> >> >> >> >> >> >> >> On Thu, Feb 24, 2011 at 12:14 PM, David Nemeskey >> >> >> >> wrote: >> >>> Please find the implementation plan attached. The word "soon" gets a >> >>> new meaning when power outages are taken into account. :) >> >>> >> >>> As before, comments are welcome. >> >>> >> >>> David >> >>> >> >>> On Tuesday, February 22, 2011 15:22:57 Simon Willnauer wrote: >> I think that is good for now. I should get started on codeawards and >> wrap up our proposals. I hope I can do that this week. >> >> simon >> >> On Tue, Feb 22, 2011 at 3:16 PM, David Nemeskey >> >> wrote: >> > Hey, >> > >> > I have written the proposal. Please let me know if you want more / >> > less of certain parts. Should I upload it somewhere? >> > >> > Implementation plan soon to follow. >> > >> > Sorry for the late reply; I have been rather busy these past few >> > weeks. >> > >> > David >> > >> > On Wednesday, February 02, 2011 10:35:55 Simon Willnauer wrote: >> >> Hey David, >> >> >> >> I saw that you added a tiny line to the GSoC Lucene wiki - thanks >> >> for that. >> >> >> >> On Wed, Feb 2, 2011 at 10:10 AM, David Nemeskey >> >> >> >> wrote: >> >>> Hi guys, >> >>> >> >>> Mark, Robert, Simon: thanks for the support! I really hope we can >> >>> work together this summer (and before that, obviously). >> >> >> >> Same here! >> >> >> >>> According to http://www.google- >> >>> melange.com/document/show/gsoc_program/google/gsoc2011/timeline , >> >>> there's still some time until the application period. So let me use >> >>> this week to finish my PhD research plan, and get back to you next >> >>> week. >> >>> >> >>> I am not really familiar with how the program works, i.e. how >> >>> detailed the application description should be, when mentorship is >> >>> decided, etc. so I guess we will have a lot to talk about. :) >> >> >> >> so from a 1ft view it work like this: >> >> >> >> 1. Write up a short proposal what your idea is about >> >> 2. make it public! and publish a implementation plan - how you would >> >> want to realize your proposal. If you don't follow that 100% in the >> >> actual impl. don't worry. Its just mean to give us an idea that you >> >> know what you are doing and where you want to go. something like a 1 >> >> A4 rough design doc. >> >> 3. give other people the change to apply for the same suggestion >> >> (this is how it works though) >> >> 4 Let the ASF / us assign one or more possible mentors to it >> >> 5. let us apply for a slot in GSoC (those are limited for >> >> organizations) 6. get accepted >> >> 7. rock it! >> >> >> >>> (Actually, should we move this discussion private?) >> >> >> >> no - we usually do everything in public except of discussion within >> >> the PMC that are meant to be private for legal reasons or similar >> >> things. Lets stick to the mailing list for all communication except >> >> you have something that should clearly not be public. This also give >> >> other contributors a chance to help and get in
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5769 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5769/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8475 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: IndexWriter#setRAMBufferSizeMB removed in trunk
Hi Shay, It sounds like we should put this (ability to change RAM buffer on the fly) back. But, can you describe how/why you need this? Is it because you have many IWs open at once and you want to dynamically change which gets to use RAM? Are there other settings that were moved to IWC that you also dynamically change today...? Can you open an issue? Make sure it's marked fix 4.0/3.2! Thanks. Mike On Wed, Mar 9, 2011 at 1:01 AM, Shay Banon wrote: > Heya, > I think the ability to change the RAMBufferSizeMB on a live IndexWriter > (without the need to close and open it) is an important one, and it seems > like tis deprecated on 3.1 and removed in trunk. Is there a chance to get it > back? > -shay.banon -- Mike http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5768 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5768/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8460 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
disquery - difference qf qs / pf ps
Hi i understand what qf and qs parameters are but i can't understand what pf and ps are exactly. someone can explain it to me?? for example qf=title^2 name^1.2 surname^1 qs=3 it means i search in title field with boost 2 or in name field with boost 1.2 or in surname field with boost 1 and the maximum slop beetween term to match is 3. right?? and the ps? pf? (phrase filter and phrase slop)? can i use all 4 parameters together?? Thanx -- Gastone Penzo
Re: real reason for java.lang.NoClassDefFoundError ?
On Mar 10, 2011, at 11:23, "Anton Korosov" wrote:
> Thank you very much, Andi, for the prompt reply!
> Can I torture you with questions a bit more?
>
> Now I tried to build it the following way:
> python -m jcc.__init__ \
> --python testjava \
> --build \
> --install \
> --jar /host/local/beam-4.8/modules/beam-core-4.8.2.jar \
> --classpath /host/local/beam-4.8/lib/clibwrapper-jiio-1.2-20090918.jar \
> --classpath /host/local/beam-4.8/lib/commons-beanutils-1.7.0.jar \
> ... + 100 more JARs in classpath.
>
> and it worked perfectly! CPP and Py code was generated, built, and
> installed. I even managed to
> import testjava
> However, when I do
> testjava.initVM(testjava.CLASSPATH)
> it gives error that looks familiar:
The jars you list with --classpath must also be on the classpath at runtime.
Either put them on the CLASSPATH env var or list them in your initVM() call's
classpath argument.
Andi..
> ---
> JavaError Traceback (most recent call last)
>
> /home/antonk/ in ()
>
> JavaError: java.lang.NoClassDefFoundError: javax/media/jai/OpImage
>Java stacktrace:
> java.lang.NoClassDefFoundError: javax/media/jai/OpImage
> Caused by: java.lang.ClassNotFoundException: javax.media.jai.OpImage
>at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
>at java.security.AccessController.doPrivileged(Native Method)
>at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
>
> Does that simply mean that I should find a JAR that contains
> javax/media/jai/OpImage and include it as --jar while building?
>
> When I try that
> --jar /host/local/beam-4.8/lib/jai_core-1.1.3.jar \
> and add more required classpathes required by jai
> --classpath /host/local/beam-4.8/jre/lib/alt-rt.jar \
> --classpath /host/local/beam-4.8/jre/lib/charsets.jar \
> --classpath /host/local/beam-4.8/jre/lib/deploy.jar \
> --classpath /host/local/beam-4.8/jre/lib/jce.jar \
> --classpath /host/local/beam-4.8/jre/lib/jsse.jar \
> --classpath /host/local/beam-4.8/jre/lib/management-agent.jar \
> --classpath /host/local/beam-4.8/jre/lib/plugin.jar \
> --classpath /host/local/beam-4.8/jre/lib/resources.jar \
> --classpath /host/local/beam-4.8/jre/lib/rt.jar \
>
> it again gives error while generating the code by JCC:
> While loading com/sun/media/jai/tilecodec/JPEGTileEncoder
> Traceback (most recent call last):
> File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
>"__main__", fname, loader, pkg_name)
> File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
>exec code in run_globals
> File
> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__init__.py",
> line 32, in
>import jcc.__main__
> File
> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/__main__.py",
> line 98, in
>cpp.jcc(sys.argv)
> File
> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> line 501, in jcc
>cls = findClass(className.replace('.', '/'), iii)
> File
> "/usr/local/lib/python2.6/dist-packages/JCC-2.7-py2.6-linux-x86_64.egg/jcc/cpp.py",
> line 73, in findClass
>cls = _findClass(className)
> jcc.cpp.JavaError: java.lang.IncompatibleClassChangeError: Implementing class
> Java stacktrace:
> java.lang.IncompatibleClassChangeError: Implementing class
>at java.lang.ClassLoader.defineClass1(Native Method)
>at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
>at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
>at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
>at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
>at java.security.AccessController.doPrivileged(Native Method)
>at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
>
> But here I'm stuck. What means java.lang.IncompatibleClassChangeError? How
> should I cope with that problem now? Can you please suggest something?
>
> All the best!
> Anton
>
> ps. It's quite useful to write you: I try 3-5 solutions while just
> describing the problem ;)
> pps. JCC is absolutely fantastic! What I luck is a bit of experience in
> Java :(
>
>>
>> On Wed, 9 Mar 2011, Anton Korosov wrote:
>>
>>> I'm trying to use BEAM/Visat software in Python. It is a large project
>>> with > 100 JARs. I try to 'convert' these JARs into Python specifying
>>> each
>>> after --jar option:
>>> python -m jcc.__init__ \
>>> --python testbeam \
>>> --jar /host/
Re: GSoC
Ok, I have created a new issue, LUCENE-2959 for this project. I have uploaded the pdfs and added the gsoc2011 and lucene-gsoc-2011 labels as well. David On 2011 March 09, Wednesday 21:58:53 Simon Willnauer wrote: > On Wed, Mar 9, 2011 at 5:48 PM, Grant Ingersoll wrote: > > I think we, Lucene committers, need to identify who is willing to mentor. > >In my experience, it is less than 5 hours a week. Most of the work > > is done as part of the community. Sometimes you have to be tough and > > fail someone (I did last year) but most of the time, if you take the > > time to interview the candidates up front, it is a good experience for > > everyone. > > count me in > > > I'd add it would be useful to have everyone put the lucene-gsoc-11 label > > on their issues too, that way we can quickly find the Lucene ones. > > done on at least one ;) > > simon > > > Also, feel free to label existing bugs. > > > > On Mar 9, 2011, at 2:11 AM, Simon Willnauer wrote: > >> Hey David and all others who want to contribute to GSoC, > >> > >> the ASF has applied for GSoC 2011 as a mentoring organization. As a > >> ASF project we don't need to apply directly though but we need to > >> register our ideas now. This works like almost anything in the ASF > >> through JIRA. All ideas should be recorded as JIRA tickets labeled > >> with "gsoc2011". Once this is done it will show up here: > >> http://s.apache.org/gsoc2011tasks > >> > >> Everybody who is interested in GSoC as a mentor or student should now > >> read this too http://community.apache.org/gsoc.html > >> > >> > >> Thanks, > >> > >> Simon > >> > >> > >> > >> > >> On Thu, Feb 24, 2011 at 12:14 PM, David Nemeskey > >> > >> wrote: > >>> Please find the implementation plan attached. The word "soon" gets a > >>> new meaning when power outages are taken into account. :) > >>> > >>> As before, comments are welcome. > >>> > >>> David > >>> > >>> On Tuesday, February 22, 2011 15:22:57 Simon Willnauer wrote: > I think that is good for now. I should get started on codeawards and > wrap up our proposals. I hope I can do that this week. > > simon > > On Tue, Feb 22, 2011 at 3:16 PM, David Nemeskey > > wrote: > > Hey, > > > > I have written the proposal. Please let me know if you want more / > > less of certain parts. Should I upload it somewhere? > > > > Implementation plan soon to follow. > > > > Sorry for the late reply; I have been rather busy these past few > > weeks. > > > > David > > > > On Wednesday, February 02, 2011 10:35:55 Simon Willnauer wrote: > >> Hey David, > >> > >> I saw that you added a tiny line to the GSoC Lucene wiki - thanks > >> for that. > >> > >> On Wed, Feb 2, 2011 at 10:10 AM, David Nemeskey > >> > >> wrote: > >>> Hi guys, > >>> > >>> Mark, Robert, Simon: thanks for the support! I really hope we can > >>> work together this summer (and before that, obviously). > >> > >> Same here! > >> > >>> According to http://www.google- > >>> melange.com/document/show/gsoc_program/google/gsoc2011/timeline , > >>> there's still some time until the application period. So let me use > >>> this week to finish my PhD research plan, and get back to you next > >>> week. > >>> > >>> I am not really familiar with how the program works, i.e. how > >>> detailed the application description should be, when mentorship is > >>> decided, etc. so I guess we will have a lot to talk about. :) > >> > >> so from a 1ft view it work like this: > >> > >> 1. Write up a short proposal what your idea is about > >> 2. make it public! and publish a implementation plan - how you would > >> want to realize your proposal. If you don't follow that 100% in the > >> actual impl. don't worry. Its just mean to give us an idea that you > >> know what you are doing and where you want to go. something like a 1 > >> A4 rough design doc. > >> 3. give other people the change to apply for the same suggestion > >> (this is how it works though) > >> 4 Let the ASF / us assign one or more possible mentors to it > >> 5. let us apply for a slot in GSoC (those are limited for > >> organizations) 6. get accepted > >> 7. rock it! > >> > >>> (Actually, should we move this discussion private?) > >> > >> no - we usually do everything in public except of discussion within > >> the PMC that are meant to be private for legal reasons or similar > >> things. Lets stick to the mailing list for all communication except > >> you have something that should clearly not be public. This also give > >> other contributors a chance to help and get interested in your > >> work!! > >> > >> simon > >> > >>> David > >>> > Hi David, honestly this sounds fantastic. > >
[jira] Updated: (LUCENE-2959) [GSoC] Implementing State of the Art Ranking for Lucene
[ https://issues.apache.org/jira/browse/LUCENE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mark Nemeskey updated LUCENE-2959: Comment: was deleted (was: The implementation plan.) > [GSoC] Implementing State of the Art Ranking for Lucene > --- > > Key: LUCENE-2959 > URL: https://issues.apache.org/jira/browse/LUCENE-2959 > Project: Lucene - Java > Issue Type: New Feature > Components: Examples, Javadocs, Query/Scoring >Reporter: David Mark Nemeskey > Labels: gsoc2011, lucene-gsoc-11 > Attachments: implementation_plan.pdf, proposal.pdf > > > Lucene employs the Vector Space Model (VSM) to rank documents, which compares > unfavorably to state of the art algorithms, such as BM25. Moreover, the > architecture is > tailored specically to VSM, which makes the addition of new ranking functions > a non- > trivial task. > This project aims to bring state of the art ranking methods to Lucene and to > implement a > query architecture with pluggable ranking functions. -- 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-2959) [GSoC] Implementing State of the Art Ranking for Lucene
[ https://issues.apache.org/jira/browse/LUCENE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mark Nemeskey updated LUCENE-2959: Comment: was deleted (was: The proposal originally sent to the mailing list.) > [GSoC] Implementing State of the Art Ranking for Lucene > --- > > Key: LUCENE-2959 > URL: https://issues.apache.org/jira/browse/LUCENE-2959 > Project: Lucene - Java > Issue Type: New Feature > Components: Examples, Javadocs, Query/Scoring >Reporter: David Mark Nemeskey > Labels: gsoc2011, lucene-gsoc-11 > Attachments: implementation_plan.pdf, proposal.pdf > > > Lucene employs the Vector Space Model (VSM) to rank documents, which compares > unfavorably to state of the art algorithms, such as BM25. Moreover, the > architecture is > tailored specically to VSM, which makes the addition of new ranking functions > a non- > trivial task. > This project aims to bring state of the art ranking methods to Lucene and to > implement a > query architecture with pluggable ranking functions. -- 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-2959) [GSoC] Implementing State of the Art Ranking for Lucene
[ https://issues.apache.org/jira/browse/LUCENE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mark Nemeskey updated LUCENE-2959: Attachment: implementation_plan.pdf The implementation plan. > [GSoC] Implementing State of the Art Ranking for Lucene > --- > > Key: LUCENE-2959 > URL: https://issues.apache.org/jira/browse/LUCENE-2959 > Project: Lucene - Java > Issue Type: New Feature > Components: Examples, Javadocs, Query/Scoring >Reporter: David Mark Nemeskey > Labels: gsoc2011, lucene-gsoc-11 > Attachments: implementation_plan.pdf, proposal.pdf > > > Lucene employs the Vector Space Model (VSM) to rank documents, which compares > unfavorably to state of the art algorithms, such as BM25. Moreover, the > architecture is > tailored specically to VSM, which makes the addition of new ranking functions > a non- > trivial task. > This project aims to bring state of the art ranking methods to Lucene and to > implement a > query architecture with pluggable ranking functions. -- 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-2959) [GSoC] Implementing State of the Art Ranking for Lucene
[ https://issues.apache.org/jira/browse/LUCENE-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mark Nemeskey updated LUCENE-2959: Attachment: proposal.pdf The proposal originally sent to the mailing list. > [GSoC] Implementing State of the Art Ranking for Lucene > --- > > Key: LUCENE-2959 > URL: https://issues.apache.org/jira/browse/LUCENE-2959 > Project: Lucene - Java > Issue Type: New Feature > Components: Examples, Javadocs, Query/Scoring >Reporter: David Mark Nemeskey > Labels: gsoc2011, lucene-gsoc-11 > Attachments: proposal.pdf > > > Lucene employs the Vector Space Model (VSM) to rank documents, which compares > unfavorably to state of the art algorithms, such as BM25. Moreover, the > architecture is > tailored specically to VSM, which makes the addition of new ranking functions > a non- > trivial task. > This project aims to bring state of the art ranking methods to Lucene and to > implement a > query architecture with pluggable ranking functions. -- 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] Created: (LUCENE-2959) [GSoC] Implementing State of the Art Ranking for Lucene
[GSoC] Implementing State of the Art Ranking for Lucene --- Key: LUCENE-2959 URL: https://issues.apache.org/jira/browse/LUCENE-2959 Project: Lucene - Java Issue Type: New Feature Components: Examples, Javadocs, Query/Scoring Reporter: David Mark Nemeskey Attachments: proposal.pdf Lucene employs the Vector Space Model (VSM) to rank documents, which compares unfavorably to state of the art algorithms, such as BM25. Moreover, the architecture is tailored specically to VSM, which makes the addition of new ranking functions a non- trivial task. This project aims to bring state of the art ranking methods to Lucene and to implement a query architecture with pluggable ranking functions. -- 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5767 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5767/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8465 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-2958) WriteLineDocTask improvements
[ https://issues.apache.org/jira/browse/LUCENE-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-2958: Attachment: LUCENE-2958.patch Attached patch modifies LineDocSource and WriteLineDocTask to allow the described extensions. By default there are no modifications and behavior is as before. > WriteLineDocTask improvements > - > > Key: LUCENE-2958 > URL: https://issues.apache.org/jira/browse/LUCENE-2958 > Project: Lucene - Java > Issue Type: Improvement > Components: contrib/benchmark >Reporter: Doron Cohen >Assignee: Doron Cohen >Priority: Minor > Fix For: 3.2, 4.0 > > Attachments: LUCENE-2958.patch > > > Make WriteLineDocTask and LineDocSource more flexible/extendable: > * allow to emit lines also for empty docs (keep current behavior as default) > * allow more/less/other fields -- 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] Created: (LUCENE-2958) WriteLineDocTask improvements
WriteLineDocTask improvements - Key: LUCENE-2958 URL: https://issues.apache.org/jira/browse/LUCENE-2958 Project: Lucene - Java Issue Type: Improvement Components: contrib/benchmark Reporter: Doron Cohen Assignee: Doron Cohen Priority: Minor Fix For: 3.2, 4.0 Make WriteLineDocTask and LineDocSource more flexible/extendable: * allow to emit lines also for empty docs (keep current behavior as default) * allow more/less/other fields -- 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5766 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5766/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8487 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5765 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5765/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8485 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 5764 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/5764/ 2 tests failed. FAILED: org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testWatchChildren Error Message: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. Stack Trace: junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit. at java.lang.Thread.run(Thread.java:636) FAILED: TEST-org.apache.solr.cloud.ZkSolrClientTest.xml. Error Message: Stack Trace: Test report file /home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/test-results/TEST-org.apache.solr.cloud.ZkSolrClientTest.xml was length 0 Build Log (for compile errors): [...truncated 8482 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2412) Multipath hierarchical faceting
[ https://issues.apache.org/jira/browse/SOLR-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005001#comment-13005001 ] Lance Norskog commented on SOLR-2412: - This is very nice. Great work! > Multipath hierarchical faceting > --- > > Key: SOLR-2412 > URL: https://issues.apache.org/jira/browse/SOLR-2412 > Project: Solr > Issue Type: New Feature > Components: SearchComponents - other >Affects Versions: 4.0 > Environment: Fast IO when huge hierarchies are used >Reporter: Toke Eskildsen > Labels: contrib, patch > Attachments: SOLR-2412.patch > > > Hierarchical faceting with slow startup, low memory overhead and fast > response. Distinguishing features as compared to SOLR-64 and SOLR-792 are > * Multiple paths per document > * Query-time analysis of the facet-field; no special requirements for > indexing besides retaining separator characters in the terms used for faceting > * Optional custom sorting of tag values > * Recursive counting of references to tags at all levels of the output > This is a shell around LUCENE-2369, making it work with the Solr API. The > underlying principle is to reference terms by their ordinals and create an > index wide documents to tags map, augmented with a compressed representation > of hierarchical levels. -- 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: (SOLR-2399) Solr Admin Interface, reworked
[ https://issues.apache.org/jira/browse/SOLR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005000#comment-13005000 ] Lance Norskog commented on SOLR-2399: - bq. RED for prod, YELLOW for test and GREEN for dev. About 5% of men are dichromats: they have red/green color-blindness.Thus, production and dev will look the same (: I would reserve red for actual problem indicators.Maybe locked and unlocked icons? > Solr Admin Interface, reworked > -- > > Key: SOLR-2399 > URL: https://issues.apache.org/jira/browse/SOLR-2399 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Stefan Matheis (steffkes) >Priority: Minor > > *The idea was to create a new, fresh (and hopefully clean) Solr Admin > Interface.* [Based on this > [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]] > I've quickly created a Github-Repository (Just for me, to keep track of the > changes) > » https://github.com/steffkes/solr-admin > [This commit shows the > differences|https://github.com/steffkes/solr-admin/commit/5f80bb0ea9deb4b94162632912fe63386f869e0d] > between old/existing index.jsp and my new one (which is could > copy-cut/paste'd from the existing one). > Main Action takes place in > [js/script.js|https://github.com/steffkes/solr-admin/blob/master/js/script.js] > which is actually neither clean nor pretty .. just work-in-progress. > Actually it's Work in Progress, so ... give it a try. It's developed with > Firefox as Browser, so, for a first impression .. please don't use _things_ > like Internet Explorer or so ;o > Jan already suggested a bunch of good things, i'm sure there are more ideas > over there :) -- 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
[HUDSON] Solr-trunk - Build # 1438 - Failure
Build: https://hudson.apache.org/hudson/job/Solr-trunk/1438/ All tests passed Build Log (for compile errors): [...truncated 11456 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2957) generate-maven-artifacts target should include all non-Mavenized Lucene & Solr dependencies
[
https://issues.apache.org/jira/browse/LUCENE-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004993#comment-13004993
]
Tommaso Teofili commented on LUCENE-2957:
-
Regarding UIMA artifacts (items 7-11) they can be found on Apache repository at:
7 :
https://repository.apache.org/content/groups/snapshots-group/org/apache/uima/alchemy-annotator/2.3.1-SNAPSHOT/
8 :
https://repository.apache.org/content/groups/snapshots-group/org/apache/uima/OpenCalaisAnnotator/2.3.1-SNAPSHOT/
9 :
https://repository.apache.org/content/groups/snapshots-group/org/apache/uima/Tagger/2.3.1-SNAPSHOT/
10 :
https://repository.apache.org/content/groups/snapshots-group/org/apache/uima/WhitespaceTokenizer/2.3.1-SNAPSHOT/
11 :
https://repository.apache.org/content/groups/public/org/apache/uima/uimaj-core/2.3.1/
Note that 7-10 are snapshots I've deployed on saturday (latest revision) while
11 is released (UIMA core 2.3.1).
Hope this helps.
Tommaso
> generate-maven-artifacts target should include all non-Mavenized Lucene &
> Solr dependencies
> ---
>
> Key: LUCENE-2957
> URL: https://issues.apache.org/jira/browse/LUCENE-2957
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Build
>Affects Versions: 3.1, 3.2, 4.0
>Reporter: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 3.2, 4.0
>
>
> Currently, in addition to deploying artifacts for all of the Lucene and Solr
> modules to a repository (by default local), the {{generate-maven-artifacts}}
> target also deploys artifacts for the following non-Mavenized Solr
> dependencies (lucene_solr_3_1 version given here):
> # {{solr/lib/commons-csv-1.0-SNAPSHOT-r966014.jar}} as
> org.apache.solr:solr-commons-csv:3.1
> # {{solr/lib/apache-solr-noggit-r944541.jar}} as
> org.apache.solr:solr-noggit:3.1
> \\ \\
> The following {{.jar}}'s should be added to the above list (lucene_solr_3_1
> version given here):
> \\ \\
> # {{lucene/contrib/icu/lib/icu4j-4_6.jar}}
> #
> {{lucene/contrib/benchmark/lib/xercesImpl-2.9.1-patched-XERCESJ}}{{-1257.jar}}
> # {{lucene/contrib/benchmark/lib/xml-apis-2.9.0.jar}}
> # {{solr/contrib/clustering/lib/carrot2-core-3.4.2.jar}}**
> # {{solr/contrib/uima/lib/uima-an-alchemy.jar}}
> # {{solr/contrib/uima/lib/uima-an-calais.jar}}
> # {{solr/contrib/uima/lib/uima-an-tagger.jar}}
> # {{solr/contrib/uima/lib/uima-an-wst.jar}}
> # {{solr/contrib/uima/lib/uima-core.jar}}
> \\ \\
> I think it makes sense to follow the same model as the current non-Mavenized
> dependencies:
> \\ \\
> * {{groupId}} = {{org.apache.solr/.lucene}}
> * {{artifactId}} = {{solr-/lucene-}},
> * {{version}} = .
> **The carrot2-core jar doesn't need to be included in trunk's release
> artifacts, since there already is a Mavenized Java6-compiled jar. branch_3x
> and lucene_solr_3_1 will need this Solr-specific Java5-compiled maven
> artifact, though.
--
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
