[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256741#comment-13256741
]
Steven Rowe commented on SOLR-3358:
---
bq. The problem with idea build is that it includes everything in lib. The
options I see are to either list the jars explicitly (leaving out -over-slf4j)
or make a new lib folder under webapp. Thoughts?
I'd rather not list the jars explicitly - IntelliJ dependency configuration has
been quite stable because whole directories are specified, and I'd rather not
change that if possible.
So my vote is to make a new lib folder under webapp.
(I can confirm, though, that explicitly listing all jars except
{{log4j-over-slf4j}} allows compilation and testing to succeed.)
> Capture Logging Events from JUL and Log4j
> -
>
> Key: SOLR-3358
> URL: https://issues.apache.org/jira/browse/SOLR-3358
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch,
> SOLR-3358-logging.patch
>
>
> The UI should be able to show the last few log messages. To support this, we
> will need to register an Appender (log4j) or Handler
> (JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256717#comment-13256717
]
Steven Rowe commented on SOLR-3358:
---
bq. Steven, do these .pom changes make sense to you?
Yes, but there is a syntax issue - all of these:
{code:xml}
optional
{code}
should instead be:
{code:xml}
true
{code}
> Capture Logging Events from JUL and Log4j
> -
>
> Key: SOLR-3358
> URL: https://issues.apache.org/jira/browse/SOLR-3358
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch,
> SOLR-3358-logging.patch
>
>
> The UI should be able to show the last few log messages. To support this, we
> will need to register an Appender (log4j) or Handler
> (JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256708#comment-13256708
]
Steven Rowe commented on SOLR-3358:
---
bq. So I think with the above change, log4j-over-slf4j will continue to be
included in the .war.
Confirmed - after running {{ant dist}} from {{solr/webapp/}} with the above
change in {{solr/common-build.xml}}, I can see from running {{tar tvf
solr/dist/*.war}}:
{noformat}
...
481535 Wed Mar 31 00:25:34 EDT 2010 WEB-INF/lib/log4j-1.2.16.jar
20639 Mon Oct 31 18:46:50 EDT 2011 WEB-INF/lib/log4j-over-slf4j-1.6.4.jar
...
{noformat}
But as you can see, {{log4j}} is still there - is that intentional, Ryan?
> Capture Logging Events from JUL and Log4j
> -
>
> Key: SOLR-3358
> URL: https://issues.apache.org/jira/browse/SOLR-3358
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch
>
>
> The UI should be able to show the last few log messages. To support this, we
> will need to register an Appender (log4j) or Handler
> (JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256704#comment-13256704
]
Steven Rowe commented on SOLR-3358:
---
bq. For the ant build path, any suggestions?
All {{solr/lib/}} jars are put on the compilation classpath via the
{{additional.dependencies}} path. I added {{log4j-over-slf4j}} to the exclude
list and compile/test for all solr+contribs succeeds:
{code:xml}
-
+
{code}
bq. we can exclude it from core, and then add it back to the .war file. I'm not
sure how to get the ivy stuff setup to have .war dependencies though.
{{ant dist}} under {{solr/webapp/}}, which produces the .war, doesn't use
{{additional.dependencies}} - instead it uses {{common.classpath.excludes}}.
So I think with the above change, {{log4j-over-slf4j}} will continue to be
included in the .war.
> Capture Logging Events from JUL and Log4j
> -
>
> Key: SOLR-3358
> URL: https://issues.apache.org/jira/browse/SOLR-3358
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch
>
>
> The UI should be able to show the last few log messages. To support this, we
> will need to register an Appender (log4j) or Handler
> (JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256689#comment-13256689
]
Steven Rowe commented on SOLR-3358:
---
{quote}
My IntelliJ is complaining about compiling Log4jWatcher. I think its because of
the classpath collision of the log4j and log4j-over-slf4j jars. Both include a
org.apache.log4j.LogManager and org.apache.log4j.spi.LoggingEvent, yet they
aren't the same classes. Any thoughts here? I'm not sure we can have the jars
as they are.
{quote}
Ant compilation succeeds only because {{log4j}} is ordered before
{{log4j-over-slf4j}} in the classpath. This is bad.
> Capture Logging Events from JUL and Log4j
> -
>
> Key: SOLR-3358
> URL: https://issues.apache.org/jira/browse/SOLR-3358
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch
>
>
> The UI should be able to show the last few log messages. To support this, we
> will need to register an Appender (log4j) or Handler
> (JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256675#comment-13256675
]
Steven Rowe commented on SOLR-3358:
---
bq. Ryan, Maven compile is failing, AFAICT as a result of your commit:
https://builds.apache.org/job/Lucene-Solr-Maven-trunk/459/consoleText
I just committed a fix: from solr-core POM, exclude {{log4j-over-slf4j}}
transitive dependency from solrj dependency. Compile/test works locally for me.
> Capture Logging Events from JUL and Log4j
> -
>
> Key: SOLR-3358
> URL: https://issues.apache.org/jira/browse/SOLR-3358
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch
>
>
> The UI should be able to show the last few log messages. To support this, we
> will need to register an Appender (log4j) or Handler
> (JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256632#comment-13256632 ] Steven Rowe commented on SOLR-3358: --- Ryan, Maven compile is failing, AFAICT as a result of your commit: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/459/consoleText > Capture Logging Events from JUL and Log4j > - > > Key: SOLR-3358 > URL: https://issues.apache.org/jira/browse/SOLR-3358 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch > > > The UI should be able to show the last few log messages. To support this, we > will need to register an Appender (log4j) or Handler > (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255520#comment-13255520
]
Steven Rowe commented on LUCENE-3965:
-
+1 to commit - good progress!
Tests work from the top level, and I tried {{ant test}} in a couple of modules'
directories, which also worked. Build output all seems to be going to the
right place (under {{lucene/build/}}).
I scanned the changed build files, and I didn't see any problems.
I searched {{\*build.xml}} for "modules/" and "contrib". "modules/" seems to
be gone, but there are several names that still have "contrib" in them (e.g.
{{test-contrib}}) in {{lucene/build.xml}} and {{lucene/common-build.xml}}.
These names can be fixed later.
I didn't look at javadocs or packaging - I assume anything you've done there
will be better than it was :).
> consolidate all api modules in one place and un!@$# packaging for 4.0
> -
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
> Attachments: LUCENE-3965.patch, LUCENE-3965.patch, LUCENE-3965.patch,
> LUCENE-3965.patch, LUCENE-3965_module_build.patch,
> LUCENE-3965_module_build_pname.patch
>
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254225#comment-13254225
]
Steven Rowe commented on LUCENE-3965:
-
{quote}
we could also just rename contrib-build to that, but keep its 'project name'
the same so that its just a filesystem
thing but all tasks still work.
here's the patch.
first you must 'svn move lucene/contrib/contrib-build.xml
lucene/module-build.xml'
{quote}
+1 - ant test from the top level works, as does ant dist from both lucene and
solr.
> consolidate all api modules in one place and un!@$# packaging for 4.0
> -
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
> Attachments: LUCENE-3965_module_build.patch
>
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3356) Logging UI (and LogLevelHandler) should support Log4j
[
https://issues.apache.org/jira/browse/SOLR-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254160#comment-13254160
]
Steven Rowe commented on SOLR-3356:
---
I got the wrong jar: {{slf4j-jdk14}} contains package {{org.slf4j.impl}}, not
{{log4j-over-slf4j}}; this is the one I think the Maven solr-core module should
have a compile scope dependency on.
> Logging UI (and LogLevelHandler) should support Log4j
> -
>
> Key: SOLR-3356
> URL: https://issues.apache.org/jira/browse/SOLR-3356
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-3356-log4j.patch
>
>
> The Logging UI and LogLevelHandler can work using Log4j rather then just JUL
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3356) Logging UI (and LogLevelHandler) should support Log4j
[
https://issues.apache.org/jira/browse/SOLR-3356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254158#comment-13254158
]
Steven Rowe commented on SOLR-3356:
---
Ryan,
Under the maven build, all solr modules have {{log4j-over-slf4j}} as a *test*
scope dependency, but the solr-core module doesn't have it as a compile scope
dependency. As a result of this missing dependency, [compilation failures
ensue|https://builds.apache.org/job/Lucene-Solr-Maven-trunk/455/consoleText].
Shouldn't the Maven solr-core module have a compile scope dependency on
{{log4j-over-slf4j}}?
> Logging UI (and LogLevelHandler) should support Log4j
> -
>
> Key: SOLR-3356
> URL: https://issues.apache.org/jira/browse/SOLR-3356
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-3356-log4j.patch
>
>
> The Logging UI and LogLevelHandler can work using Log4j rather then just JUL
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3983) HTMLCharacterEntities.jflex uses String.toUpperCase without Locale
[
https://issues.apache.org/jira/browse/LUCENE-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254144#comment-13254144
]
Steven Rowe commented on LUCENE-3983:
-
Maybe a better idea would be to convert {{upperCaseVariantsAccepted}} into a
map, so that runtime uppercasing isn't required:
{code:java}
private static final Map upperCaseVariantsAccepted
= new HashMap();
static {
upperCaseVariantsAccepted.put("quot", "QUOT");
upperCaseVariantsAccepted.put("copy", "COPY");
upperCaseVariantsAccepted.put("gt", "GT");
upperCaseVariantsAccepted.put("lt", "LT");
upperCaseVariantsAccepted.put("reg", "REG");
upperCaseVariantsAccepted.put("amp", "AMP");
}
[...]
for (int i = 0 ; i < entities.length ; i += 2) {
Character value = entities[i + 1].charAt(0);
entityValues.put(entities[i], value);
String upperCaseVariant = upperCaseVariantsAccepted.get(entities[i]);
if (upperCaseVariant != null) {
entityValues.put(upperCaseVariant, value);
}
}
{code}
> HTMLCharacterEntities.jflex uses String.toUpperCase without Locale
> --
>
> Key: LUCENE-3983
> URL: https://issues.apache.org/jira/browse/LUCENE-3983
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Uwe Schindler
>Assignee: Steven Rowe
>
> Is this expected?
> {code:java}
> "xi", "\u03BE", "yacute", "\u00FD", "yen", "\u00A5", "yuml", "\u00FF",
> "zeta", "\u03B6", "zwj", "\u200D", "zwnj", "\u200C"
> };
> for (int i = 0 ; i < entities.length ; i += 2) {
> Character value = entities[i + 1].charAt(0);
> entityValues.put(entities[i], value);
> if (upperCaseVariantsAccepted.contains(entities[i])) {
> entityValues.put(entities[i].toUpperCase(), value);
> }
> }
> {code}
> In my opinion, this should look like:
> {code:java}
> "xi", "\u03BE", "yacute", "\u00FD", "yen", "\u00A5", "yuml", "\u00FF",
> "zeta", "\u03B6", "zwj", "\u200D", "zwnj", "\u200C"
> };
> for (int i = 0 ; i < entities.length ; i += 2) {
> Character value = entities[i + 1].charAt(0);
> entityValues.put(entities[i], value);
> if (upperCaseVariantsAccepted.contains(entities[i])) {
> entityValues.put(entities[i].toUpperCase(Locale.ENGLISH), value);
> }
> }
> {code}
> (otherwise in the Turkish locale, the entities containing "i" (like "xi" ->
> '\u03BE') will not be detected correctly).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3983) HTMLCharacterEntities.jflex uses String.toUpperCase without Locale
[
https://issues.apache.org/jira/browse/LUCENE-3983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13254143#comment-13254143
]
Steven Rowe commented on LUCENE-3983:
-
Since {{upperCaseVariantsAccepted}} entries don't include an "i", and this set
will likely never grow, this isn't really a problem?:
{code:java}
private static final Set upperCaseVariantsAccepted
= new
HashSet(Arrays.asList("quot","copy","gt","lt","reg","amp"));{code}
However, it's definitely a good idea in general.
+1
> HTMLCharacterEntities.jflex uses String.toUpperCase without Locale
> --
>
> Key: LUCENE-3983
> URL: https://issues.apache.org/jira/browse/LUCENE-3983
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Uwe Schindler
>Assignee: Steven Rowe
>
> Is this expected?
> {code:java}
> "xi", "\u03BE", "yacute", "\u00FD", "yen", "\u00A5", "yuml", "\u00FF",
> "zeta", "\u03B6", "zwj", "\u200D", "zwnj", "\u200C"
> };
> for (int i = 0 ; i < entities.length ; i += 2) {
> Character value = entities[i + 1].charAt(0);
> entityValues.put(entities[i], value);
> if (upperCaseVariantsAccepted.contains(entities[i])) {
> entityValues.put(entities[i].toUpperCase(), value);
> }
> }
> {code}
> In my opinion, this should look like:
> {code:java}
> "xi", "\u03BE", "yacute", "\u00FD", "yen", "\u00A5", "yuml", "\u00FF",
> "zeta", "\u03B6", "zwj", "\u200D", "zwnj", "\u200C"
> };
> for (int i = 0 ; i < entities.length ; i += 2) {
> Character value = entities[i + 1].charAt(0);
> entityValues.put(entities[i], value);
> if (upperCaseVariantsAccepted.contains(entities[i])) {
> entityValues.put(entities[i].toUpperCase(Locale.ENGLISH), value);
> }
> }
> {code}
> (otherwise in the Turkish locale, the entities containing "i" (like "xi" ->
> '\u03BE') will not be detected correctly).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253582#comment-13253582
]
Steven Rowe commented on LUCENE-3965:
-
A good first step would be to bring all Lucene contribs down to the same level
as {{core/}} and {{test-framework/}}; make a new {{module-build.xml}} that's
basically a copy of {{contrib-build.xml}}, and then make all the "internal"
modules switch to {{module-build.xml}}.
Moving {{modules/*}} and getting rid of {{contrib-build.xml}} could come later.
> consolidate all api modules in one place and un!@$# packaging for 4.0
> -
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3347) deleteByQuery failing with SolrCloud without _version_ in schema.xml
[
https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13251790#comment-13251790
]
Steven Rowe commented on SOLR-3347:
---
git patches can be applied to svn checkouts with {{patch -p1}}, instead of the
usual {{patch -p0}} used with svn-generated patches.
> deleteByQuery failing with SolrCloud without _version_ in schema.xml
>
>
> Key: SOLR-3347
> URL: https://issues.apache.org/jira/browse/SOLR-3347
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Reporter: Benson Margulies
> Fix For: 4.0
>
> Attachments:
> 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch,
> provision-and-start.sh, schema.xml, solrconfig.xml
>
>
> Distributed execution of deleteByQuery("\*:\*") depends on the existence of a
> field \_version\_ in the schema. The default schema has no comment on this
> field to indicate its important or relevance to SolrCloud, and no message is
> logged nor error status returned when there is no such field. The code in
> DistributedUpdateProcessor just has an if statement that never ever does any
> local deleting without it.
> I don't know whether the intention was that this should work or not. If
> someone would clue me in, I'd make a patch for schema.xml to add comments, or
> a patch to D-U-P to add logging. If it was supposed to work, I'm probably not
> qualified to make the fix to make it work.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250753#comment-13250753
]
Steven Rowe commented on SOLR-3344:
---
bq. I like the optional dependencies alternative better: add optional jetty
dependencies to Solr test-framework, and change the javadoc for
BaseDistributedSearchTestCase to note this requirement.
Thinking about this more, the rationale I would ordinarily use to justify
making a dependency optional involves minimizing *runtime* dependencies. But
the Solr test-framework is a test-only module, and requiring *test*
dependencies that won't be used by all consumers should not cause any undue
hardship.
So I've changed my mind. I'll put up a superset of your patch, Benson, that
removes the dataimporthandler and clustering POMs' jetty dependencies. I'll
leave solr-core's optional dependency as-is.
> POM dependencies not all there yet for solr-test-framework
> --
>
> Key: SOLR-3344
> URL: https://issues.apache.org/jira/browse/SOLR-3344
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: 4.0
>Reporter: Benson Margulies
> Attachments: 0001-Add-jetty-deps.patch
>
>
> The pom for solr-test-framework does not mention jetty, so a test case that
> doesn't get jetty into it's classpath otherwise fails with:
> {noformat}
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250733#comment-13250733
]
Steven Rowe commented on SOLR-3344:
---
bq. I think that it's reasonable for the test framework jar to list it as a
required dependency, since tests in there depend on it. However, there is an
alternative (other than nothing): list it again as an optional dependency in
test-framework, just to give people a hint, and/or change the javadoc for the
BaseDistributedTestCase to note this requirement.
I assume you're referring to {{BaseDistributed*Search*TestCase}}, which depends
on solr-core's {{oas.client.solrj.embedded.JettySolrRunner}}?
I like the optional dependencies alternative better: add optional jetty
dependencies to Solr test-framework, and change the javadoc for
BaseDistributedSearchTestCase to note this requirement.
> POM dependencies not all there yet for solr-test-framework
> --
>
> Key: SOLR-3344
> URL: https://issues.apache.org/jira/browse/SOLR-3344
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: 4.0
>Reporter: Benson Margulies
> Attachments: 0001-Add-jetty-deps.patch
>
>
> The pom for solr-test-framework does not mention jetty, so a test case that
> doesn't get jetty into it's classpath otherwise fails with:
> {noformat}
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250649#comment-13250649
]
Steven Rowe commented on SOLR-3344:
---
Benson, where are you seeing these failures? Why hasn't Jenkins unearthed them?
Why should Solr test-framework declare these dependencies at all? That is, why
can't modules with Jetty test dependencies simply declare the dependency there
(with scope=test)? This is already the case for the following Solr modules:
solr-core, clustering, and dataimporthandler.
If it does turn out that Solr test-framework is the right place for these
dependencies, it doesn't require Jetty to compile, so at a minimum, I would
argue that the default compile scope you've used is inappropriate. Maybe
scope=runtime?
> POM dependencies not all there yet for solr-test-framework
> --
>
> Key: SOLR-3344
> URL: https://issues.apache.org/jira/browse/SOLR-3344
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: 4.0
>Reporter: Benson Margulies
> Attachments: 0001-Add-jetty-deps.patch
>
>
> The pom for solr-test-framework does not mention jetty, so a test case that
> doesn't get jetty into it's classpath otherwise fails with:
> {noformat}
> java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249110#comment-13249110
]
Steven Rowe commented on LUCENE-3959:
-
bq. I don't know how to disable these 3.x tasks in jenkins completely or i
would.
I think you got it - thanks!
bq. so I think its ok to disable the 3.x tasks and dedicate them towards trunk?
+1
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Trivial
> Fix For: 4.0
>
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3959) Remove @author tags in Lucene/Solr sources
[
https://issues.apache.org/jira/browse/LUCENE-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248938#comment-13248938
]
Steven Rowe commented on LUCENE-3959:
-
Hossman's Solr commit removing @author tags in July 2007:
http://svn.apache.org/viewvc?view=revision&revision=555343
> Remove @author tags in Lucene/Solr sources
> --
>
> Key: LUCENE-3959
> URL: https://issues.apache.org/jira/browse/LUCENE-3959
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/javadocs
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Priority: Trivial
> Attachments: LUCENE-3959.patch
>
>
> Lucene/Solr sources should not include {{@author}} tags. See the
> [solr-dev@l.a.o|http://lucene.markmail.org/thread/bbcbnfdssi3ir5sg] and
> [java-dev@l.a.o|http://lucene.markmail.org/thread/g6meuxgs34goy373] threads
> in which this was discussed.
> The Jenkins builds should fail if they are found, in the same way that
> {{nocommit}}'s are currently handled
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3965) consolidate all api modules in one place and un!@$# packaging for 4.0
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248775#comment-13248775 ] Steven Rowe commented on LUCENE-3965: - bq. I don't like the separation between Solr and Lucene, in my opinion, Solr should also be a module and the lucene dir vanished. Solr contribs should also be modules. I agree with Robert: one top-level dir per "product" makes sense to me. > consolidate all api modules in one place and un!@$# packaging for 4.0 > - > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248763#comment-13248763 ] Steven Rowe commented on LUCENE-3965: - bq. If the products are still going to be lucene/ and solr/ (and i think for simplicity for 4.0, that's really what it should be) +1 > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248758#comment-13248758
]
Steven Rowe commented on LUCENE-3965:
-
Do you think we should keep one {{build/}} directory per new-style module? I
rather like the current {{ant clean}} under {{lucene/}} - boom, one directory,
done.
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248750#comment-13248750
]
Steven Rowe commented on LUCENE-3965:
-
{quote}
another idea: instead of having analysis/ with "submodules" underneath it,
we could flatten that too (like solr-dataimporthandler and
dataimporthandler-extras)
so we would have analysis-common, analysis-kuromoji, analysis-phonetic, etc.
Not sure if this really makes things simpler, but its flat. We don't have to do
it,
but maybe it could simplify the build and such to have this easy flat structure.
{quote}
+0 - while the current analysis sub-module structure only serves to
conceptually group them, rather than provide any technical benefit, I think we
may want sub-modules in the future, perhaps for technical reasons, but also to
get a handle on the [human chunking
limit|http://www.chambers.com.au/glossary/chunking_principle.php]: more than
5-9 or so "things" in one "place" and people's eyes glaze over...
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248720#comment-13248720
]
Steven Rowe commented on LUCENE-3965:
-
{quote}
bq. Like this? (i.e. everything under modules/, but modules/ under lucene/:
If we put it under lucene/ I would propose we wouldnt move core at all.
* lucene/
** core/
** demo/
** highlighter/
** analyzers/
** grouping/
** test-framework
...
{quote}
+1
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248688#comment-13248688
]
Steven Rowe commented on LUCENE-3965:
-
bq. an alternative thats still the same basic proposal is to move the current
modules/ underneath lucene/ (maybe thats less confusing? as then you see our
two "products" lucene/ and solr/ from the svn-tree).
Like this? (i.e. everything under {{modules/}}, but {{modules/}} under
{{lucene/}}:
* {{lucene/}}
** {{modules/}}
*** {{core/}}
*** {{sandbox/}}
*** {{test-framework}}
*** ...
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248681#comment-13248681
]
Steven Rowe commented on LUCENE-3965:
-
bq. btw: I'm just bringing this up as an idea to go towards addressing the 4.0
packaging, in my opinion it makes sense and is simple. There might be other
solutions too though.
I guess it's simpler because instead {{lucene/}} and its denizens (which we
already know and love), as well as {{modules/}} (no packaging clue, thank you
very much), the problem is reduced to the one single great unknown.
bq. But truth be told, now is a GREAT time to figure this out as we look at
putting 3.x in bugfix mode. because we can fix this layout to be organized the
way we want and not pay the price of difficult svn merging.
Yes, if we are going to restructure, we should do it now.
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3965) Move lucene/core to modules/core, same with test-framework, etc
[ https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248673#comment-13248673 ] Steven Rowe commented on LUCENE-3965: - and what about lucene contribs? all promoted to be modules? > Move lucene/core to modules/core, same with test-framework, etc > --- > > Key: LUCENE-3965 > URL: https://issues.apache.org/jira/browse/LUCENE-3965 > Project: Lucene - Java > Issue Type: Task > Components: general/build >Affects Versions: 4.0 >Reporter: Robert Muir > > I think users get confused about how svn/source is structured, > when in fact we are just producing a modular build. > I think it would be more clear if the lucene stuff was underneath > modules/, thats where our modular API is. > we could still package this up as lucene.tar.gz if we want, and even name > modules/core lucene-core.jar, but i think this would be a lot better > organized than the current: > * lucene > * lucene/contrib > * modules > confusion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3965) Move lucene/core to modules/core, same with test-framework, etc
[
https://issues.apache.org/jira/browse/LUCENE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248668#comment-13248668
]
Steven Rowe commented on LUCENE-3965:
-
So top-level {{lucene/}} directory would vanish?
Solr would not be affected?
> Move lucene/core to modules/core, same with test-framework, etc
> ---
>
> Key: LUCENE-3965
> URL: https://issues.apache.org/jira/browse/LUCENE-3965
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Affects Versions: 4.0
>Reporter: Robert Muir
>
> I think users get confused about how svn/source is structured,
> when in fact we are just producing a modular build.
> I think it would be more clear if the lucene stuff was underneath
> modules/, thats where our modular API is.
> we could still package this up as lucene.tar.gz if we want, and even name
> modules/core lucene-core.jar, but i think this would be a lot better
> organized than the current:
> * lucene
> * lucene/contrib
> * modules
> confusion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3964) Stage Maven release artifacts
[ https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248434#comment-13248434 ] Steven Rowe commented on LUCENE-3964: - bq. Confused about the component: build. Feel free to change it to a more appropriate component (not sure what that would be). bq. I certainily hope the build need not be changed to do this (certainly not for 3.6) No, it does not. As I mentioned in my previous post on this issue, the patch is against trunk, and it works against your 3.6.0 RC0 (Lucene only at this point; Solr still needs to be tested.) bq. I think we should generate an RC like we do now, putting it on p.a.o, vote on it, and this is merely a deployment issue. +1 bq. If there are any scripts involved in this, i think they should go in dev-tools instead, (like other release deployment scripts)? Yup, that's what I've done. This is a work in progress - please review if you're interested! > Stage Maven release artifacts > - > > Key: LUCENE-3964 > URL: https://issues.apache.org/jira/browse/LUCENE-3964 > Project: Lucene - Java > Issue Type: New Feature > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Critical > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3964.patch > > > We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3964) Stage Maven release artifacts
[ https://issues.apache.org/jira/browse/LUCENE-3964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248438#comment-13248438 ] Steven Rowe commented on LUCENE-3964: - bq. But again: this is for deployment correct? Yes. bq. I don't want to change our release process for 3.6 +1 > Stage Maven release artifacts > - > > Key: LUCENE-3964 > URL: https://issues.apache.org/jira/browse/LUCENE-3964 > Project: Lucene - Java > Issue Type: New Feature > Components: general/build >Affects Versions: 3.6, 4.0 >Reporter: Steven Rowe >Assignee: Steven Rowe >Priority: Critical > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3964.patch > > > We need a way to stage Maven artifacts to the Apache release repository. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3323) fix solr javadocs to link to local lucene javadocs w/relative links when users build locally
[
https://issues.apache.org/jira/browse/SOLR-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247607#comment-13247607
]
Steven Rowe commented on SOLR-3323:
---
This:
{noformat}
+ value="${common-solr.dir}/../lucene/build/docs/api/all/"/>
{noformat}
might be better as:
{noformat}
+ value="${common.dir}/build/docs/api/all/"/>
{noformat}
> fix solr javadocs to link to local lucene javadocs w/relative links when
> users build locally
>
>
> Key: SOLR-3323
> URL: https://issues.apache.org/jira/browse/SOLR-3323
> Project: Solr
> Issue Type: Task
> Components: documentation
>Reporter: Hoss Man
>Assignee: Steven Rowe
> Fix For: 4.0
>
> Attachments: SOLR-3323.patch
>
>
> SOLR-2439 changed how javadoc linkages are handled between solr javadocs and
> lucene javadocs -- but i think there is still an improvement to be made.
> currently if you are building a "SNAPSHOT" of solr, it links to
> builds.apache.org for the lucene docs -- but if you are building solr from
> src, you must have a full copy of the entire lucene+solr tree, so we should
> just use a relative link up to the local copy of the lucene javadocs (if you
> are compiling your own solr, you are probably not using precompiled lucene
> jars, so you may want to update the lucene javadocs as well)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3323) fix solr javadocs to link to local lucene javadocs w/relative links when users build locally
[
https://issues.apache.org/jira/browse/SOLR-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13247585#comment-13247585
]
Steven Rowe commented on SOLR-3323:
---
bq. i'm pretty sure this is as simple as changing the default value of
lucene.javadoc.url set in target "define-lucene-javadoc-url-SNAPSHOT" to
something like "../lucene/build/docs/api/all/"
+1.
Separately, in trunk right now:
{code:xml}
https://builds.apache.org/job/Lucene-3.x/javadoc/all/"/>
{code}
That is, Solr trunk javadocs point to the branch_3x Lucene javadocs :(.
> fix solr javadocs to link to local lucene javadocs w/relative links when
> users build locally
>
>
> Key: SOLR-3323
> URL: https://issues.apache.org/jira/browse/SOLR-3323
> Project: Solr
> Issue Type: Task
> Components: documentation
>Reporter: Hoss Man
>Assignee: Steven Rowe
> Fix For: 4.0
>
>
> SOLR-2439 changed how javadoc linkages are handled between solr javadocs and
> lucene javadocs -- but i think there is still an improvement to be made.
> currently if you are building a "SNAPSHOT" of solr, it links to
> builds.apache.org for the lucene docs -- but if you are building solr from
> src, you must have a full copy of the entire lucene+solr tree, so we should
> just use a relative link up to the local copy of the lucene javadocs (if you
> are compiling your own solr, you are probably not using precompiled lucene
> jars, so you may want to update the lucene javadocs as well)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3948) Experiment with placing poms outside of src
[
https://issues.apache.org/jira/browse/LUCENE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246767#comment-13246767
]
Steven Rowe commented on LUCENE-3948:
-
I applied the patch, ran {{ant filter-pom-templates}} under lucene, {{chdir}}'d
to {{lucene/build/poms/}}, and successfully ran the following:
* {{mvn -N -P bootstrap install}}
* {{mvn -DskipTests install}}
* {{mvn test}}
I think two things should change:
# {{ant get-maven-poms}}, the user-level POM acquisition target, should place
the POMs in a directory at the same level as {{lucene/}} and {{solr/}} - it
could be named {{maven-build/}} or something like that. (Mixing Lucene and
Solr build stuff together under {{lucene/}} is bad.)
# The build output directory should be under {{maven-build/}}, rather than the
same dirs as those used by the Ant build.
> Experiment with placing poms outside of src
> ---
>
> Key: LUCENE-3948
> URL: https://issues.apache.org/jira/browse/LUCENE-3948
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Minor
> Attachments: LUCENE-3948.patch, LUCENE-3948.patch
>
>
> Recent work in LUCENE-3944 has changed how our generated pom.xml files are
> handled during release preparation, placing them in build/ instead. However
> get-maven-poms still places the poms inside src/ so you can use them to drive
> a build. What I think would be ideal is if we could unify the release
> handling of the poms and the normal building handling, so that the poms can
> sit outside of src and serve both purposes.
> Some time ago I investigated how the ANT project handles its own Maven
> integration and it has its poms sitting in their own directory. They then
> reference the actual src locations inside the poms. This works for ANT but
> with a warning since some of their tests don't work due to how the Maven
> surefire plugin works, so they skip their tests.
> I have done some quick testing of my own and this process does seem to work
> for our poms and tests. I now want to take this to a full scale POC and see
> if it works fully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3948) Experiment with placing poms outside of src
[
https://issues.apache.org/jira/browse/LUCENE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246739#comment-13246739
]
Steven Rowe commented on LUCENE-3948:
-
Hi Chris,
I applied the patch, ran {{ant filter-pom-templates}} under lucene, {{chdir}}'d
to {{lucene/build/poms/}}, and tried the following:
* {{
> Experiment with placing poms outside of src
> ---
>
> Key: LUCENE-3948
> URL: https://issues.apache.org/jira/browse/LUCENE-3948
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Minor
> Attachments: LUCENE-3948.patch
>
>
> Recent work in LUCENE-3944 has changed how our generated pom.xml files are
> handled during release preparation, placing them in build/ instead. However
> get-maven-poms still places the poms inside src/ so you can use them to drive
> a build. What I think would be ideal is if we could unify the release
> handling of the poms and the normal building handling, so that the poms can
> sit outside of src and serve both purposes.
> Some time ago I investigated how the ANT project handles its own Maven
> integration and it has its poms sitting in their own directory. They then
> reference the actual src locations inside the poms. This works for ANT but
> with a warning since some of their tests don't work due to how the Maven
> surefire plugin works, so they skip their tests.
> I have done some quick testing of my own and this process does seem to work
> for our poms and tests. I now want to take this to a full scale POC and see
> if it works fully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[
https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246426#comment-13246426
]
Steven Rowe commented on LUCENE-3951:
-
{quote}
bq. 'The maven build' doesn't require generate-maven-artifacts, and never has.
well at least hudson needs to call the logic in my patch (somehow) because the
maven bootstrap uses:
{noformat}solr/example/lib/jetty-${patched.jetty.version}.jar{noformat}
{quote}
Your patch puts {{ant resolve}} in the wrong place.
{{mvn -P bootstrap install}} is run by the jenkins script before attempting to
run {{mvn install}} and {{mvn test}}, but {{ant genenerate-maven-artifacts}}
is called by the jenkins script *after* running all of these (to deploy
snapshots), so {{ant resolve}} should happen *before* any of the {{mvn ...}}
stuff.
{quote}
And it seems that maven could do this itself in its executions?
see
http://search.maven.org/remotecontent?filepath=org/apache/rat/apache-rat-tasks/0.8/apache-rat-tasks-0.8.pom
for an example?
{quote}
Yes, you're right - the ant build shouldn't have to deal with this at all.
I'll make a patch.
> get-maven-poms should depend on ivy resolve, so that non-mavenized jars are
> available for use by mvn -P bootstrap install
> -
>
> Key: LUCENE-3951
> URL: https://issues.apache.org/jira/browse/LUCENE-3951
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.6
>Reporter: Steven Rowe
>Assignee: Steven Rowe
> Fix For: 3.6
>
> Attachments: LUCENE-3951.patch
>
>
> see title
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[
https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246413#comment-13246413
]
Steven Rowe commented on LUCENE-3951:
-
{quote}
on 3.x i think it wants the jetty jars to be there.
but this can be solved by simply adding an
to this top-level task only needed by the maven build.
{quote}
Yes, you're right, only on branch_3x, where jetty and jetty-util are still
locally-modified non-released test dependencies, 'the maven build'
(specifically running tests under Maven) needs these two jars to be in
{{solr/example/lib}}. Re-opening...
> get-maven-poms should depend on ivy resolve, so that non-mavenized jars are
> available for use by mvn -P bootstrap install
> -
>
> Key: LUCENE-3951
> URL: https://issues.apache.org/jira/browse/LUCENE-3951
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.6
>Reporter: Steven Rowe
>Assignee: Steven Rowe
> Fix For: 3.6
>
> Attachments: LUCENE-3951.patch
>
>
> see title
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[
https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246406#comment-13246406
]
Steven Rowe commented on LUCENE-3951:
-
bq. ok i see: maven build still requires this task, it just doesnt need the
libs resolved...
'The maven build' doesn't require {{generate-maven-artifacts}}, and never has.
> get-maven-poms should depend on ivy resolve, so that non-mavenized jars are
> available for use by mvn -P bootstrap install
> -
>
> Key: LUCENE-3951
> URL: https://issues.apache.org/jira/browse/LUCENE-3951
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.6, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
> Fix For: 3.6, 4.0
>
>
> see title
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[
https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246392#comment-13246392
]
Steven Rowe commented on LUCENE-3951:
-
{{dist-maven}} isn't recursive - {{generate-maven-artifacts}} provides
{{dist-maven}} recursion.
I'm missing some dots you've connected here - how is it that 'the maven build'
not needing {{ant resolve}} to function means that {{generate-maven-artifacts}}
is not necessary?
> get-maven-poms should depend on ivy resolve, so that non-mavenized jars are
> available for use by mvn -P bootstrap install
> -
>
> Key: LUCENE-3951
> URL: https://issues.apache.org/jira/browse/LUCENE-3951
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.6, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
> Fix For: 3.6, 4.0
>
>
> see title
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3951) get-maven-poms should depend on ivy resolve, so that non-mavenized jars are available for use by mvn -P bootstrap install
[
https://issues.apache.org/jira/browse/LUCENE-3951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13246359#comment-13246359
]
Steven Rowe commented on LUCENE-3951:
-
Hmm, JIRA lost a comment I made on this issue before resolving (or I screwed up
by editing the issue before submitting a comment I was making) - it was
something like:
I confused releasing and enabling 'the maven build', which involves putting the
POMs in place via {{ant get-maven-poms}} and installing non-mavenized
dependencies into the user's local maven repository via {{mvn -P bootstrap
install}}. The source of the non-mavenized dependencies was the {{lib/}}
directories, which are empty until ivy resolve is done, so ivy resolve is a
prerequisite.
However, since there are no longer any non-mavenized dependencies (see
SOLR-3308, LUCENE-3930, and SOLR-3310 - thanks Robert Muir and Chris Male), ivy
resolve is no longer a prerequisite for running 'the maven build'. I'll
resolve this issue as Invalid.
> get-maven-poms should depend on ivy resolve, so that non-mavenized jars are
> available for use by mvn -P bootstrap install
> -
>
> Key: LUCENE-3951
> URL: https://issues.apache.org/jira/browse/LUCENE-3951
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: 3.6, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
> Fix For: 3.6, 4.0
>
>
> see title
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3945) we should include checksums for every jar ivy fetches in svn & src releases to verify the jars are the ones we expect
[
https://issues.apache.org/jira/browse/LUCENE-3945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245636#comment-13245636
]
Steven Rowe commented on LUCENE-3945:
-
bq. it can also detect ivy cache corrumption.
I have encountered cache corrumption: AFAICT a truncated jar file
(tika-parsers-1.0.jar); killing the cache fixed the problem. We could add a
{{clean-ivy-cache}} target calling [the target Ivy
provides|http://ant.apache.org/ivy/history/2.2.0/use/cleancache.html].
> we should include checksums for every jar ivy fetches in svn & src releases
> to verify the jars are the ones we expect
> -
>
> Key: LUCENE-3945
> URL: https://issues.apache.org/jira/browse/LUCENE-3945
> Project: Lucene - Java
> Issue Type: Task
>Reporter: Hoss Man
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3945.patch
>
>
> Conversation with rmuir last night got me thinking about the fact that one
> thing we lose by using ivy is confidence that every user of a release is
> compiling against (and likely using at run time) the same dependencies as
> every other user.
> Up to 3.5, users of src and binary releases could be confident that the jars
> included in the release were the same jars the lucene devs vetted and tested
> against when voting on the release candidate, but with ivy there is now the
> possibility that after the source release is published, the owner of a domain
> where these dependencies are hosted might change the jars in some way w/o
> anyone knowing. Likewise: we as developers could commit an ivy.xml file
> pointing to a specific URL which we then use for and test for months, and
> just prior to a release, the contents of the remote URL could change such
> that a JAR included in the binary artifacts might not match the ones we've
> vetted and tested leading up to that RC.
> So i propose that we include checksum files in svn and in our source releases
> that can be used by users to verify that the jars they get from ivy match the
> jars we tested against.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3944) ant clean should remove pom.xml's
[
https://issues.apache.org/jira/browse/LUCENE-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245566#comment-13245566
]
Steven Rowe commented on LUCENE-3944:
-
bq. I just recently peeked at Apache ANT's source distribution and this seems
to be done this way (separate folder structure just for POMs with relative
refs).
On #lucene IRC last night and this morning, Chris Male pointed out Ant's POM
setup, and said that he's working on enabling exactly the same setup for
Lucene/Solr. I believe the new {{filter-pom-templates}} target included in my
patches on this issue could be part of such a change.
> ant clean should remove pom.xml's
> -
>
> Key: LUCENE-3944
> URL: https://issues.apache.org/jira/browse/LUCENE-3944
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3944.patch, LUCENE-3944.patch
>
>
> Currently once the pom.xml's are in place, its hard to get them out. Having
> them can be a little trappy when you're trying to debug the bug. We should
> facilitate their removal during clean.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3944) ant clean should remove pom.xml's
[
https://issues.apache.org/jira/browse/LUCENE-3944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13245514#comment-13245514
]
Steven Rowe commented on LUCENE-3944:
-
bq. A nice improvement in the future would be if solr's common-build defined
filtered.pom.templates.dir to be under its own solr/build (rather than lucene's)
Where would {{modules/}} POMs go - each under its own build directory?
If we ever try to do this, I think Maven Ant Tasks' deploy target needs to be
able to access the parent and grandparent POMs, which (I think) means either
putting them into the user's local maven repository, or putting them at the
relative location given in the parent POM section of each POM. Maybe in order
to satisfy this the grandparent POM could be put in both places (or all places
if {{modules/}} need their own)?
> ant clean should remove pom.xml's
> -
>
> Key: LUCENE-3944
> URL: https://issues.apache.org/jira/browse/LUCENE-3944
> Project: Lucene - Java
> Issue Type: Improvement
> Components: general/build
>Reporter: Chris Male
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3944.patch, LUCENE-3944.patch
>
>
> Currently once the pom.xml's are in place, its hard to get them out. Having
> them can be a little trappy when you're trying to debug the bug. We should
> facilitate their removal during clean.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3941) Maven Build Broken - Bootstrap fails
[
https://issues.apache.org/jira/browse/LUCENE-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13244384#comment-13244384
]
Steven Rowe commented on LUCENE-3941:
-
Hi Tobias,
Thanks for reporting.
I'm working on it. Should be functional later today.
> Maven Build Broken - Bootstrap fails
>
>
> Key: LUCENE-3941
> URL: https://issues.apache.org/jira/browse/LUCENE-3941
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Affects Versions: Realtime Branch
>Reporter: Tobias Rübner
>
> Building Lucene/Solr as described in dev-tools/maven/README.maven fails,
> because a contributed lib is missing.
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:2.3.1:install-file
> (install-langdetect) on project lucene-solr-grandparent:
> Error installing artifact 'org.apache.solr:solr-langdetect:jar':
> Failed to install artifact org.apache.solr:solr-langdetect:jar:4.0-SNAPSHOT:
> /home/truebner/dev/workspace/apache-lucene/solr/contrib/langid/lib/langdetect-r111.jar
> (No such file or directory) -> [Help 1]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3940) When Japanese (Kuromoji) tokenizer removes a punctuation token it should leave a hole
[ https://issues.apache.org/jira/browse/LUCENE-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13243784#comment-13243784 ] Steven Rowe commented on LUCENE-3940: - bq. I think its well accepted that words carry the information content of a doc, punctuation has no information content really here, it doesn't tell me what the doc is about, and I don't think this is controversial, I just think your view on this is extreme... I disagree with you, Robert. (If punctuation has no information content, why does it exist?) IMHO Mike's examples are not at all extreme, e.g. some punctuation tokens could be used to trigger position increment gaps. bq. StandardTokenizer doesnt leave holes when it drops punctuation, I think holes should only be real 'words' for the most part "Standard"Tokenizer is drawn from Unicode UAX#29, which only describes word *boundaries*. Lucene has grafted onto these boundary rules an assumption that only alphanumeric "words" should be tokens - this assumption does not exist in the standard itself. My opinion is that we should have both types of things: a tokenizer that discards non-alphanumeric characters between word boundaries; and different type of analysis component that discards nothing. I think of the discard-nothing process as *segmentation* rather than tokenization, and I've [argued for it previously|https://issues.apache.org/jira/browse/LUCENE-2498?focusedCommentId=12878963&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12878963]. > When Japanese (Kuromoji) tokenizer removes a punctuation token it should > leave a hole > - > > Key: LUCENE-3940 > URL: https://issues.apache.org/jira/browse/LUCENE-3940 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Michael McCandless >Priority: Minor > Fix For: 4.0 > > Attachments: LUCENE-3940.patch, LUCENE-3940.patch, LUCENE-3940.patch > > > I modified BaseTokenStreamTestCase to assert that the start/end > offsets match for graph (posLen > 1) tokens, and this caught a bug in > Kuromoji when the decompounding of a compound token has a punctuation > token that's dropped. > In this case we should leave hole(s) so that the graph is intact, ie, > the graph should look the same as if the punctuation tokens were not > initially removed, but then a StopFilter had removed them. > This also affects tokens that have no compound over them, ie we fail > to leave a hole today when we remove the punctuation tokens. > I'm not sure this is serious enough to warrant fixing in 3.6 at the > last minute... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-2202) Money/Currency FieldType
[ https://issues.apache.org/jira/browse/SOLR-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242865#comment-13242865 ] Steven Rowe commented on SOLR-2202: --- bq. Is it that your Compiler settings in IntelliJ don't include .json files? That is usually my first goto when a file with an exotic extension isn't getting copied into the build space. Yes, this was the problem. I committed a fix to both trunk and branch_3x after Yonik asked me about the problem on #lucene-dev IRC. > Money/Currency FieldType > > > Key: SOLR-2202 > URL: https://issues.apache.org/jira/browse/SOLR-2202 > Project: Solr > Issue Type: New Feature > Components: Schema and Analysis >Affects Versions: 1.5 >Reporter: Greg Fodor >Assignee: Jan Høydahl > Fix For: 3.6, 4.0 > > Attachments: SOLR-2022-solr-3.patch, > SOLR-2202-3x-stabilize-provider-interface.patch, > SOLR-2202-fix-NPE-if-no-tlong-fieldType.patch, SOLR-2202-lucene-1.patch, > SOLR-2202-no-fieldtype-deps.patch, SOLR-2202-solr-1.patch, > SOLR-2202-solr-10.patch, SOLR-2202-solr-2.patch, SOLR-2202-solr-4.patch, > SOLR-2202-solr-5.patch, SOLR-2202-solr-6.patch, SOLR-2202-solr-7.patch, > SOLR-2202-solr-8.patch, SOLR-2202-solr-9.patch, SOLR-2202.patch, > SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch, > SOLR-2202.patch, SOLR-2202.patch, SOLR-2202.patch > > > Provides support for monetary values to Solr/Lucene with query-time currency > conversion. The following features are supported: > - Point queries > - Range quries > - Sorting > - Currency parsing by either currency code or symbol. > - Symmetric & Asymmetric exchange rates. (Asymmetric exchange rates are > useful if there are fees associated with exchanging the currency.) > At indexing time, money fields can be indexed in a native currency. For > example, if a product on an e-commerce site is listed in Euros, indexing the > price field as "1000,EUR" will index it appropriately. By altering the > currency.xml file, the sorting and querying against Solr can take into > account fluctuations in currency exchange rates without having to re-index > the documents. > The new "money" field type is a polyfield which indexes two fields, one which > contains the amount of the value and another which contains the currency code > or symbol. The currency metadata (names, symbols, codes, and exchange rates) > are expected to be in an xml file which is pointed to by the field type > declaration in the schema.xml. > The current patch is factored such that Money utility functions and > configuration metadata lie in Lucene (see MoneyUtil and CurrencyConfig), > while the MoneyType and MoneyValueSource lie in Solr. This was meant to > mirror the work being done on the spacial field types. > This patch will be getting used to power the international search > capabilities of the search engine at Etsy. > Also see WIKI page: http://wiki.apache.org/solr/MoneyFieldType -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3296) Explore alternatives to Commons CSV
[
https://issues.apache.org/jira/browse/SOLR-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13242289#comment-13242289
]
Steven Rowe commented on SOLR-3296:
---
Minor nit about releasing noggit, which is hosted at Apache Labs: from
[http://labs.apache.org/bylaws.html]:
{quote}
h2. Guidelines
[...]
h4. Releases
(x) Labs are prohibited from making releases.
{quote}
> Explore alternatives to Commons CSV
> ---
>
> Key: SOLR-3296
> URL: https://issues.apache.org/jira/browse/SOLR-3296
> Project: Solr
> Issue Type: Improvement
> Components: Build
>Reporter: Chris Male
>
> In LUCENE-3930 we're implementing some less than ideal solutions to make
> available the unreleased version of commons-csv. We could remove these
> solutions if we didn't rely on this lib. So I think we should explore
> alternatives.
> I think [opencsv|http://opencsv.sourceforge.net/] is an alternative to
> consider, I've used it in many commercial projects. Bizarrely Commons-CSV's
> website says that Opencsv uses a BSD license, but this isn't the case,
> OpenCSV uses ASL2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3937) Workaround the XERCES-J bug in Benchmark
[
https://issues.apache.org/jira/browse/LUCENE-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241925#comment-13241925
]
Steven Rowe commented on LUCENE-3937:
-
Committed the remaining references patch to branch_3x and trunk. Uwe, you can
kill the {{benchmark/CHANGES.txt}} entry I added if you don't like it.
> Workaround the XERCES-J bug in Benchmark
>
>
> Key: LUCENE-3937
> URL: https://issues.apache.org/jira/browse/LUCENE-3937
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3937-remaining-references.patch,
> LUCENE-3937-remaining-references.patch, LUCENE-3937.patch, LUCENE-3937.patch
>
>
> In becnhmark we have a patched version of XERCES which is hard to compile
> from source. When looking at the code part patched and the source of
> EnwikiContentSource, to simply provide the XML parser a Reader instead of
> InputStream, so the broken code is not triggered. This assumes, that the
> XML-file is always UTF-8 If not it will no longer work (because the XML
> parser cannot switch encoding, if it only has a Reader).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3937) Workaround the XERCES-J bug in Benchmark
[
https://issues.apache.org/jira/browse/LUCENE-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241906#comment-13241906
]
Steven Rowe commented on LUCENE-3937:
-
{quote}
bq. wait: i don't think we should remove the licensing information totally?
bq. we still rely on xerces. it should just say 2.9.1 (not patched-hacked
version)
Right, thanks, I'll put it back and adjust the version.
{quote}
So, I'll put it back and adjust the version in {{lucene/NOTICE.txt}}, but think
it should be removed from {{solr/NOTICE.txt}} because it's not actually
included in Solr? Here's what's in {{solr/NOTICE.txt}} now:
{noformat}
Includes software from other Apache Software Foundation projects,
including, but not limited to:
[...]
- Xerces (lib/xercesImpl-2.9.1-patched-XERCESJ-1257.jar)
{noformat}
No xercesImpl jar exists under {{solr/lib/}}.
> Workaround the XERCES-J bug in Benchmark
>
>
> Key: LUCENE-3937
> URL: https://issues.apache.org/jira/browse/LUCENE-3937
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3937-remaining-references.patch,
> LUCENE-3937.patch, LUCENE-3937.patch
>
>
> In becnhmark we have a patched version of XERCES which is hard to compile
> from source. When looking at the code part patched and the source of
> EnwikiContentSource, to simply provide the XML parser a Reader instead of
> InputStream, so the broken code is not triggered. This assumes, that the
> XML-file is always UTF-8 If not it will no longer work (because the XML
> parser cannot switch encoding, if it only has a Reader).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3937) Workaround the XERCES-J bug in Benchmark
[
https://issues.apache.org/jira/browse/LUCENE-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241901#comment-13241901
]
Steven Rowe commented on LUCENE-3937:
-
{quote}
wait: i don't think we should remove the licensing information totally?
we still rely on xerces. it should just say 2.9.1 (not patched-hacked version)
{quote}
Right, thanks, I'll put it back and adjust the version.
> Workaround the XERCES-J bug in Benchmark
>
>
> Key: LUCENE-3937
> URL: https://issues.apache.org/jira/browse/LUCENE-3937
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3937-remaining-references.patch,
> LUCENE-3937.patch, LUCENE-3937.patch
>
>
> In becnhmark we have a patched version of XERCES which is hard to compile
> from source. When looking at the code part patched and the source of
> EnwikiContentSource, to simply provide the XML parser a Reader instead of
> InputStream, so the broken code is not triggered. This assumes, that the
> XML-file is always UTF-8 If not it will no longer work (because the XML
> parser cannot switch encoding, if it only has a Reader).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3937) Workaround the XERCES-J bug in Benchmark
[ https://issues.apache.org/jira/browse/LUCENE-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241899#comment-13241899 ] Steven Rowe commented on LUCENE-3937: - bq. I added a changes entry? Benchmark has its own CHANGES.txt, and there is mention in there of this patched jar, so I thought it appropriate to add an entry there. I didn't think to check for your CHANGES entry. I'll go do that now. > Workaround the XERCES-J bug in Benchmark > > > Key: LUCENE-3937 > URL: https://issues.apache.org/jira/browse/LUCENE-3937 > Project: Lucene - Java > Issue Type: Bug >Reporter: Uwe Schindler >Assignee: Uwe Schindler >Priority: Blocker > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3937-remaining-references.patch, > LUCENE-3937.patch, LUCENE-3937.patch > > > In becnhmark we have a patched version of XERCES which is hard to compile > from source. When looking at the code part patched and the source of > EnwikiContentSource, to simply provide the XML parser a Reader instead of > InputStream, so the broken code is not triggered. This assumes, that the > XML-file is always UTF-8 If not it will no longer work (because the XML > parser cannot switch encoding, if it only has a Reader). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3294) Remove binary carrot2.jar and replace it with a maven dependency.
[ https://issues.apache.org/jira/browse/SOLR-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241785#comment-13241785 ] Steven Rowe commented on SOLR-3294: --- bq. Since you have it open would you commit it in too? Remove that 'dist-maven' section, it isn't needed indeed. Thanks! Will do. > Remove binary carrot2.jar and replace it with a maven dependency. > - > > Key: SOLR-3294 > URL: https://issues.apache.org/jira/browse/SOLR-3294 > Project: Solr > Issue Type: Task > Components: contrib - Clustering >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Blocker > Fix For: 3.6 > > Attachments: SOLR-3294.patch > > > The repo contains a manually retrowoven Carrot2 JAR which does not have a > corresponding artefact in Maven Central (so won't work for ivy). > We will make a release with 1.5 backport (I hate this!). > http://issues.carrot2.org/browse/CARROT-902 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3294) Remove binary carrot2.jar and replace it with a maven dependency.
[
https://issues.apache.org/jira/browse/SOLR-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241775#comment-13241775
]
Steven Rowe commented on SOLR-3294:
---
I just checked, and Maven Central now has the new release. I'll remove my
{{}} entry and retry.
> Remove binary carrot2.jar and replace it with a maven dependency.
> -
>
> Key: SOLR-3294
> URL: https://issues.apache.org/jira/browse/SOLR-3294
> Project: Solr
> Issue Type: Task
> Components: contrib - Clustering
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: SOLR-3294.patch
>
>
> The repo contains a manually retrowoven Carrot2 JAR which does not have a
> corresponding artefact in Maven Central (so won't work for ivy).
> We will make a release with 1.5 backport (I hate this!).
> http://issues.carrot2.org/browse/CARROT-902
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3294) Remove binary carrot2.jar and replace it with a maven dependency.
[
https://issues.apache.org/jira/browse/SOLR-3294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241772#comment-13241772
]
Steven Rowe commented on SOLR-3294:
---
{quote}
A patch replacing Carrot2 with (maven central released) 3.5.0.1.
A feeble attempt to fix maven descriptors as well, but Steve -- help, help --
did I get it right? :)
I've just pushed 3.5.0.1 to MC so it'll be there in an hour or so (rsync). You
can grab it from
https://oss.sonatype.org/content/repositories/releases/org/carrot2/carrot2-core/3.5.0.1/
too.
{quote}
As of this writing, the new artifacts haven't made it to MC yet. The Maven
build (compile/install/test) works, under both Java5 and Java6, if I
temporarily add this to the top-level POM:
{code:xml}
sonatype.oss.releases
Sonatype OSS releases
https://oss.sonatype.org/content/repositories/releases
true
false
{code}
One small thing: the {{dist-maven}} specialization can be removed entirely from
{{clustering/build.xml}}:
{code:xml}
{code}
I also tried the Ant build ({{ant test}} under {{solr/contrib/clustering/}})
under both Java5 and Java6 (after populating {{clustering/lib/}} from my local
Maven repo), and it succeeded for me.
> Remove binary carrot2.jar and replace it with a maven dependency.
> -
>
> Key: SOLR-3294
> URL: https://issues.apache.org/jira/browse/SOLR-3294
> Project: Solr
> Issue Type: Task
> Components: contrib - Clustering
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Blocker
> Fix For: 3.6
>
> Attachments: SOLR-3294.patch
>
>
> The repo contains a manually retrowoven Carrot2 JAR which does not have a
> corresponding artefact in Maven Central (so won't work for ivy).
> We will make a release with 1.5 backport (I hate this!).
> http://issues.carrot2.org/browse/CARROT-902
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3272) Solr filter factory for MorfologikFilter
[
https://issues.apache.org/jira/browse/SOLR-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240032#comment-13240032
]
Steven Rowe commented on SOLR-3272:
---
bq. where is the code that copies these JARs to solr?
The {{dist}} target in {{solr/webapp/build.xml}} depends on
{{lucene-jars-to-solr}} in {{solr/common-build.xml}}, which makes sure that
lucene .jar dependencies are built (via {{prep-lucene-jars}}), and then copies
them to {{solr/build/lucene-libs/}}, the contents of which are then packaged
into the .war. Dawid, I think this is where you want to make changes.
More packaging details:
The {{dist}} target in {{solr/webapp/build.xml}} also runs the
{{contribs-add-to-war}} target from {{solr/common-build.xml}}, which invokes
{{add-to-war}} in each Solr contrib that has a {{src/webapp/}} directory
(currently only DIH) to copy the contents of {{src/webapp/}} to
{{solr/build/web/}}, the contents of which are then packaged into the .war.
Lastly, the {{create-package}} target in {{solr/build.xml}} depends on the
{{dist}} target, which depends on the {{dist-contrib}} target, which invokes
{{dist}} in each Solr contrib. Solr contribs that want to include lucene .jar
dependencies in the Solr distribution (but not the .war) have their {{dist}}
targets populate {{solr/build/contrib//lucene-libs/}} with those
.jars. The {{create-package}} target then invokes
{{add-lucene-libs-to-package}} in each Solr contrib, which copies the contents
of {{solr/build/contrib//lucene-libs/}} to
{{solr/build/contrib-lucene-libs-to-package/contrib//}}.
Finally, the .war incorporates the contents of
{{solr/build/contrib-lucene-libs-to-package/}}.
Wow, that last part is way more complex than it needs to be. (And it's totally
my fault :( )
Before Robert and I rewrote the Solr build, the top-level Solr build file was
*huge*. One of the guiding principles I used was "keep build configuration
local". Now individual modules handle the details that only concern them.
Coordination among modules, as seen in the above packaging description, remains
a challenge...
> Solr filter factory for MorfologikFilter
>
>
> Key: SOLR-3272
> URL: https://issues.apache.org/jira/browse/SOLR-3272
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Affects Versions: 4.0
>Reporter: Rafał Kuć
>Assignee: Dawid Weiss
> Fix For: 4.0
>
> Attachments: SOLR-3272-toupper-correction.patch,
> SOLR-3272-with-javadoc-example-usage.patch, SOLR-3272.patch, SOLR-3272.patch,
> SOLR-3727-new.patch
>
>
> I didn't find MorfologikFilter factory in Solr, so here is a simple. Maybe
> someone will have make use of it :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3930) nuke jars from source tree and use ivy
[
https://issues.apache.org/jira/browse/LUCENE-3930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240017#comment-13240017
]
Steven Rowe commented on LUCENE-3930:
-
bq. I have no idea what uses this maven-ant-tasks.jar thats still there, or
where to fetch it from, but maybe Steve knows :)
maven-ant-tasks.jar is used by {{generate-maven-artifacts}} / {{dist-maven}} /
{{m2-deploy\*}} to deploy Maven artifacts; these are used by the Jenkins Maven
builds to deploy snapshots to the Apache Snapshot repository, and up through
the most recent release, to create Maven release artifacts to be published on
Maven central.
I unpacked the .jar and found a POM under META-INF, and it says its
{{groupId:artifactId:version}} coordinates are
{{org.apache.maven:maven-ant-tasks:2.1.3}}, which is available from the Maven
Central repository at
[http://repo1.maven.org/maven2/org/apache/maven/maven-ant-tasks/2.1.3/].
> nuke jars from source tree and use ivy
> --
>
> Key: LUCENE-3930
> URL: https://issues.apache.org/jira/browse/LUCENE-3930
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Robert Muir
>Assignee: Robert Muir
> Attachments: LUCENE-3930.patch
>
>
> As mentioned on the ML thread: "switch jars to ivy mechanism?".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239543#comment-13239543 ] Steven Rowe commented on SOLR-2020: --- bq. I think the problem was with maven version. I first tried with maven 3.0.4 and saw those failures but it sure compiles with 2.2.1. Thanks for tracking down the problem, Sami. Last time I checked, the Maven build worked under Maven 3.0.4. I use Maven 2.2.1, though, so I don't regularly test with 3.0.4. I should set up another Jenkins job that runs the build under Maven 3.0.X. In the mean time, though, I'll look into why 3.0.4 doesn't like the build and make it work for both 2.2.1 and 3.0.4. > HttpComponentsSolrServer > > > Key: SOLR-2020 > URL: https://issues.apache.org/jira/browse/SOLR-2020 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4.1 > Environment: Any >Reporter: Chantal Ackermann >Priority: Minor > Fix For: 4.0 > > Attachments: HttpComponentsSolrServer.java, > HttpComponentsSolrServerTest.java, SOLR-2020-3x.patch, > SOLR-2020-HttpSolrServer.patch, SOLR-2020.patch, SOLR-2020.patch, > SOLR-2020.patch, SOLR-2020.patch > > > Implementation of SolrServer that uses the Apache Http Components framework. > Http Components (http://hc.apache.org/) is the successor of Commons > HttpClient and thus HttpComponentsSolrServer would be a successor of > CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-2020) HttpComponentsSolrServer
[
https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239501#comment-13239501
]
Steven Rowe commented on SOLR-2020:
---
Sami, [today's Jenkins Maven 3.x
build|https://builds.apache.org/job/Lucene-Solr-Maven-3.x/439/] succeeded,
including the changes I made, so I suspect your compilation issues are as a
result of stale artifacts in your local repository.
Before I run tests, I usually do {{mvn -N -P bootstrap install}} and then {{mvn
-DskipTests install}} from the top level.
> HttpComponentsSolrServer
>
>
> Key: SOLR-2020
> URL: https://issues.apache.org/jira/browse/SOLR-2020
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Affects Versions: 1.4.1
> Environment: Any
>Reporter: Chantal Ackermann
>Priority: Minor
> Fix For: 4.0
>
> Attachments: HttpComponentsSolrServer.java,
> HttpComponentsSolrServerTest.java, SOLR-2020-3x.patch,
> SOLR-2020-HttpSolrServer.patch, SOLR-2020.patch, SOLR-2020.patch,
> SOLR-2020.patch, SOLR-2020.patch
>
>
> Implementation of SolrServer that uses the Apache Http Components framework.
> Http Components (http://hc.apache.org/) is the successor of Commons
> HttpClient and thus HttpComponentsSolrServer would be a successor of
> CommonsHttpSolrServer, in the future.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-2020) HttpComponentsSolrServer
[
https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239020#comment-13239020
]
Steven Rowe commented on SOLR-2020:
---
Sami,
Solrj compilation fails under Maven: see [today's Jenkins Maven 3.x
build|https://builds.apache.org/job/Lucene-Solr-Maven-3.x/438/].
I've committed the following changes - tests now succeed for me locally under
the Maven build:
* Switched the scope from runtime to compile for the two {{httpcomponents}}
dependencies in the {{solrj}} POM - compilation fails unless these are on the
classpath.
* Removed {{commons-httpclient}} dependency from the {{solr-core}} POM. It
gets this dependency transitively through {{solrj}}.
* Added the two {{httpcomponents}} dependencies with test scope to the POM for
{{solr-core}} (under which all Solr tests are run in the Maven build, including
those of {{solrj}}); otherwise tests fail, because these are *optional*
dependencies of {{solrj}}, and are not transitively included on the test
classpath.
* Added a {{httpcomponents.version}} property to the Lucene/Solr grandparent
POM, and used it in the {{}} declarations for the two
{{httpcomponents}} dependencies.
> HttpComponentsSolrServer
>
>
> Key: SOLR-2020
> URL: https://issues.apache.org/jira/browse/SOLR-2020
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Affects Versions: 1.4.1
> Environment: Any
>Reporter: Chantal Ackermann
>Priority: Minor
> Fix For: 4.0
>
> Attachments: HttpComponentsSolrServer.java,
> HttpComponentsSolrServerTest.java, SOLR-2020-3x.patch,
> SOLR-2020-HttpSolrServer.patch, SOLR-2020.patch, SOLR-2020.patch,
> SOLR-2020.patch, SOLR-2020.patch
>
>
> Implementation of SolrServer that uses the Apache Http Components framework.
> Http Components (http://hc.apache.org/) is the successor of Commons
> HttpClient and thus HttpComponentsSolrServer would be a successor of
> CommonsHttpSolrServer, in the future.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3268) remove write acess to source tree (chmod 555) when running tests in jenkins
[
https://issues.apache.org/jira/browse/SOLR-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238793#comment-13238793
]
Steven Rowe commented on SOLR-3268:
---
bq. All of these are in .gitignore, Steven (and can be regenerated via
dev-tools/scripts/gitignore-gen.sh.
Right, I'd forgotten about that (I'm not a git user).
I rolled my own dirty one-liner script (newlines/indents added here for
clarity):
{noformat}
(for a in $(find . -type d | grep -v '\.svn\|/build') ; do
b=`svn propget svn:ignore $a`
if [[ -n $b ]]; then
c=${b//$'\n'/, }
echo "|$a|$c|"
fi
done) 2>/dev/null
{noformat}
> remove write acess to source tree (chmod 555) when running tests in jenkins
> ---
>
> Key: SOLR-3268
> URL: https://issues.apache.org/jira/browse/SOLR-3268
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Robert Muir
> Fix For: 4.0
>
> Attachments: SOLR-3268_sync.patch
>
>
> Some tests are currently creating files under the source tree.
> This causes a lot of problems, it makes my checkout look dirty after running
> 'ant test' and i have to cleanup.
> I opened and issue for this a month in a half for
> solrj/src/test-files/solrj/solr/shared/test-solr.xml (SOLR-3112),
> but now we have a second file
> (core/src/test-files/solr/conf/elevate-data-distrib.xml).
> So I think hudson needs to chmod these src directories to 555, so that solr
> tests that do this will fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3268) remove write acess to source tree (chmod 555) when running tests in jenkins
[
https://issues.apache.org/jira/browse/SOLR-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238767#comment-13238767
]
Steven Rowe commented on SOLR-3268:
---
Here's the list for {{trunk/solr/}}:
||directory||svn:ignore||
|contrib/dataimporthandler/src/test-files|dataimport.properties|
|contrib/dataimporthandler/src/test-files/dih/solr/conf|dataimport.properties|
|contrib/dataimporthandler-extras/src/test-files/dihextras/solr/conf|dataimport.properties|
|core/src/test-files/solr|data|
|example/example-DIH/solr/db|data|
|example/example-DIH/solr/db/conf|dataimport.properties|
|example/example-DIH/solr/mail|data|
|example/example-DIH/solr/mail/lib|*.jar|
|example/example-DIH/solr/rss|data|
|example/example-DIH/solr/rss/conf|dataimport.properties|
|example/example-DIH/solr/tika|data|
|example/exampledocs|post.jar|
|example/multicore/core0|data|
|example/multicore/core1|data|
|example/solr|data, lib, logs, zoo_data|
> remove write acess to source tree (chmod 555) when running tests in jenkins
> ---
>
> Key: SOLR-3268
> URL: https://issues.apache.org/jira/browse/SOLR-3268
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Robert Muir
> Fix For: 4.0
>
> Attachments: SOLR-3268_sync.patch
>
>
> Some tests are currently creating files under the source tree.
> This causes a lot of problems, it makes my checkout look dirty after running
> 'ant test' and i have to cleanup.
> I opened and issue for this a month in a half for
> solrj/src/test-files/solrj/solr/shared/test-solr.xml (SOLR-3112),
> but now we have a second file
> (core/src/test-files/solr/conf/elevate-data-distrib.xml).
> So I think hudson needs to chmod these src directories to 555, so that solr
> tests that do this will fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3268) remove write acess to source tree (chmod 555) when running tests in jenkins
[
https://issues.apache.org/jira/browse/SOLR-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238738#comment-13238738
]
Steven Rowe commented on SOLR-3268:
---
bq. i think you're talking about SOLR-3112
I don't think so - I think I was remembering something under DIH
{{test-files/}}.
Here are the non-standard {{svn:ignore}}'s I found under {{branch_3x/solr/}} -
are any of these problematic?:
||directory||svn:ignore||
|contrib/dataimporthandler/src/test-files|dataimport.properties|
|contrib/dataimporthandler/src/test-files/dih/solr/conf|dataimport.properties|
|contrib/dataimporthandler-extras/src/test-files/dihextras/solr/conf|dataimport.properties|
|core/src/test-files/solr|data|
|core/src/test-files/solr|data|
|example/example-DIH/solr/db|data|
|example/example-DIH/solr/mail|data|
|example/example-DIH/solr/db|data|
|example/example-DIH/solr/mail|data|
|example/example-DIH/solr/mail/lib|*.jar|
|example/example-DIH/solr/rss|data|
|example/example-DIH/solr/rss/conf|dataimport.properties|
|example/example-DIH/solr/tika|data|
|example/exampledocs|post.jar|
|example/multicore/core0|data|
|example/multicore/core1|data|
|example/solr|data, lib, logs|
> remove write acess to source tree (chmod 555) when running tests in jenkins
> ---
>
> Key: SOLR-3268
> URL: https://issues.apache.org/jira/browse/SOLR-3268
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Robert Muir
> Fix For: 4.0
>
> Attachments: SOLR-3268_sync.patch
>
>
> Some tests are currently creating files under the source tree.
> This causes a lot of problems, it makes my checkout look dirty after running
> 'ant test' and i have to cleanup.
> I opened and issue for this a month in a half for
> solrj/src/test-files/solrj/solr/shared/test-solr.xml (SOLR-3112),
> but now we have a second file
> (core/src/test-files/solr/conf/elevate-data-distrib.xml).
> So I think hudson needs to chmod these src directories to 555, so that solr
> tests that do this will fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3268) remove write acess to source tree (chmod 555) when running tests in jenkins
[
https://issues.apache.org/jira/browse/SOLR-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238702#comment-13238702
]
Steven Rowe commented on SOLR-3268:
---
{quote}
add a final step to the jenkins build script that fails if "svn status | wc -l"
returns non-zero?
it wont't ensure no changes are made to src/, but it should ensure no changes
are made to src/ unless explicitly allowed by an svn:ignore
{quote}
I don't remember which one(s), but I recall that at least one file is (was?)
produced by a Solr test and svn:ignore'd. In order for Hoss's suggestion to be
fully effective, we should stop svn:ignore'ing test outputs (outside of
{{build/}} or other already ignored directories). I'll see what's being
svn:ignore'd now.
> remove write acess to source tree (chmod 555) when running tests in jenkins
> ---
>
> Key: SOLR-3268
> URL: https://issues.apache.org/jira/browse/SOLR-3268
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Robert Muir
> Fix For: 4.0
>
> Attachments: SOLR-3268_sync.patch
>
>
> Some tests are currently creating files under the source tree.
> This causes a lot of problems, it makes my checkout look dirty after running
> 'ant test' and i have to cleanup.
> I opened and issue for this a month in a half for
> solrj/src/test-files/solrj/solr/shared/test-solr.xml (SOLR-3112),
> but now we have a second file
> (core/src/test-files/solr/conf/elevate-data-distrib.xml).
> So I think hudson needs to chmod these src directories to 555, so that solr
> tests that do this will fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3913) HTMLStripCharFilter produces invalid final offset
[
https://issues.apache.org/jira/browse/LUCENE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237695#comment-13237695
]
Steven Rowe commented on LUCENE-3913:
-
{quote}
bq. I don't think it will be interesting, instead just make seeds less
reproducible across java 6 and 7 or other jre impls with different # of locales
Hmm, I didn't think of the reproducibility angle. I'll fix.
{quote}
Committed to trunk and branch_3x.
Thanks again Robert!
> HTMLStripCharFilter produces invalid final offset
> -
>
> Key: LUCENE-3913
> URL: https://issues.apache.org/jira/browse/LUCENE-3913
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Steven Rowe
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3913.patch, LUCENE-3913.patch
>
>
> Nightly build found this... I boiled it down to a small test case that
> doesn't require the big line file docs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3913) HTMLStripCharFilter produces invalid final offset
[ https://issues.apache.org/jira/browse/LUCENE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237689#comment-13237689 ] Steven Rowe commented on LUCENE-3913: - bq. I don't think it will be interesting, instead just make seeds less reproducible across java 6 and 7 or other jre impls with different # of locales Hmm, I didn't think of the reproducibility angle. I'll fix. > HTMLStripCharFilter produces invalid final offset > - > > Key: LUCENE-3913 > URL: https://issues.apache.org/jira/browse/LUCENE-3913 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Steven Rowe > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3913.patch, LUCENE-3913.patch > > > Nightly build found this... I boiled it down to a small test case that > doesn't require the big line file docs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3913) HTMLStripCharFilter produces invalid final offset
[ https://issues.apache.org/jira/browse/LUCENE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237656#comment-13237656 ] Steven Rowe commented on LUCENE-3913: - bq. I think the toUpperCase/toLowerCase in recaseCodePoints should take Locale.ENGLISH? Yeah, I had that in at first, but then I thought it might be useful to use the randomized locale to trigger "interesting things". That's what we want, right? > HTMLStripCharFilter produces invalid final offset > - > > Key: LUCENE-3913 > URL: https://issues.apache.org/jira/browse/LUCENE-3913 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless >Assignee: Steven Rowe > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3913.patch, LUCENE-3913.patch > > > Nightly build found this... I boiled it down to a small test case that > doesn't require the big line file docs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3913) HTMLStripCharFilter produces invalid final offset
[
https://issues.apache.org/jira/browse/LUCENE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237650#comment-13237650
]
Steven Rowe commented on LUCENE-3913:
-
bq. ant test -Dtestcase=HTMLStripCharFilterTest -Dtestmethod=null ...
Actually, I ran it without {{-Dtestmethod=null}}.
> HTMLStripCharFilter produces invalid final offset
> -
>
> Key: LUCENE-3913
> URL: https://issues.apache.org/jira/browse/LUCENE-3913
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Steven Rowe
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3913.patch, LUCENE-3913.patch
>
>
> Nightly build found this... I boiled it down to a small test case that
> doesn't require the big line file docs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3913) HTMLStripCharFilter produces invalid final offset
[ https://issues.apache.org/jira/browse/LUCENE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237571#comment-13237571 ] Steven Rowe commented on LUCENE-3913: - bq. Since we know those are special, a good idea for the future could be to add both those elements to randomHtmlishString +1 > HTMLStripCharFilter produces invalid final offset > - > > Key: LUCENE-3913 > URL: https://issues.apache.org/jira/browse/LUCENE-3913 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3913.patch > > > Nightly build found this... I boiled it down to a small test case that > doesn't require the big line file docs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3913) HTMLStripCharFilter produces invalid final offset
[ https://issues.apache.org/jira/browse/LUCENE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237567#comment-13237567 ] Steven Rowe commented on LUCENE-3913: - Minimal test failure trigger appears to be "x", where "x" can be any non-whitespace character, and "" must be "". (No problems with "x", "x", etc.) and are handled specially, so this should narrow it down. > HTMLStripCharFilter produces invalid final offset > - > > Key: LUCENE-3913 > URL: https://issues.apache.org/jira/browse/LUCENE-3913 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3913.patch > > > Nightly build found this... I boiled it down to a small test case that > doesn't require the big line file docs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3913) HTMLStripCharFilter produces invalid final offset
[ https://issues.apache.org/jira/browse/LUCENE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237550#comment-13237550 ] Steven Rowe commented on LUCENE-3913: - I can reproduce - I'm digging. > HTMLStripCharFilter produces invalid final offset > - > > Key: LUCENE-3913 > URL: https://issues.apache.org/jira/browse/LUCENE-3913 > Project: Lucene - Java > Issue Type: Bug >Reporter: Michael McCandless > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3913.patch > > > Nightly build found this... I boiled it down to a small test case that > doesn't require the big line file docs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3260) Improve exception handling / logging for ScriptTransformer.init()
[
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235688#comment-13235688
]
Steven Rowe commented on SOLR-3260:
---
bq. I missed one. Sorry about that. Should be fixed now.
Thanks James, I think it's fixed - just now in the console output from the
Jenkins Maven trunk job (still running as I write this), I saw:
{noformat}
Running org.apache.solr.handler.dataimport.TestScriptTransformer
NOTE: Assume failed in
'testCheckScript(org.apache.solr.handler.dataimport.TestScriptTransformer)'
(ignored): got: ,
expected: null
NOTE: Assume failed in
'testBasic(org.apache.solr.handler.dataimport.TestScriptTransformer)'
(ignored): got: ,
expected: null
NOTE: Assume failed in
'testOneparam(org.apache.solr.handler.dataimport.TestScriptTransformer)'
(ignored): got: ,
expected: null
Tests run: 4, Failures: 0, Errors: 0, Skipped: 3, Time elapsed: 0.023 sec
{noformat}
> Improve exception handling / logging for ScriptTransformer.init()
> -
>
> Key: SOLR-3260
> URL: https://issues.apache.org/jira/browse/SOLR-3260
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 3.5, 4.0
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Trivial
> Fix For: 3.6, 4.0
>
> Attachments: SOLR-3260.patch
>
>
> This came up on the user-list. ScriptTransformer logs the same "need a >=1.6
> jre" message for several problems, making debugging difficult for users.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()
[
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235600#comment-13235600
]
Steven Rowe commented on SOLR-3260:
---
James, the trunk Maven build is still unhappy:
{noformat}
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/433/
1 tests failed.
FAILED: org.apache.solr.handler.dataimport.TestScriptTransformer.testOneparam
Error Message:
Cannot load Script Engine for language: JavaScript
Stack Trace:
org.apache.solr.handler.dataimport.DataImportHandlerException: Cannot load
Script Engine for language: JavaScript
at
org.apache.solr.handler.dataimport.ScriptTransformer.initEngine(ScriptTransformer.java:76)
{noformat}
> Improve exception handling / logging for ScriptTransformer.init()
> -
>
> Key: SOLR-3260
> URL: https://issues.apache.org/jira/browse/SOLR-3260
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 3.5, 4.0
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Trivial
> Fix For: 3.6, 4.0
>
> Attachments: SOLR-3260.patch
>
>
> This came up on the user-list. ScriptTransformer logs the same "need a >=1.6
> jre" message for several problems, making debugging difficult for users.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3263) Stop including more than one servlet-api jar version in the test classpath in the Maven build
[
https://issues.apache.org/jira/browse/SOLR-3263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234910#comment-13234910
]
Steven Rowe commented on SOLR-3263:
---
I committed to trunk.
I'll go kick off a trunk Maven build on Jenkins now.
> Stop including more than one servlet-api jar version in the test classpath in
> the Maven build
> -
>
> Key: SOLR-3263
> URL: https://issues.apache.org/jira/browse/SOLR-3263
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
> Attachments: SOLR-3263.patch
>
>
> [Today's nightly Jenkins Maven trunk
> build|https://builds.apache.org/job/Lucene-Solr-Maven-trunk/431/testReport/]
> has several test failures with the error message:
> {noformat}
> class "javax.servlet.FilterRegistration"'s signer information does not match
> signer information of other classes in the same package
> {noformat}
> On SOLR-3260, [Ryan McKinley
> mentioned|https://issues.apache.org/jira/browse/SOLR-3260?focusedCommentId=13234472&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13234472]
> that these errors can be caused by mixing servlet-api jar versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()
[
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234854#comment-13234854
]
Steven Rowe commented on SOLR-3260:
---
{quote}
> > class "javax.servlet.FilterRegistration"'s signer information does not
> > match signer information of other classes in the same package
>
> I have seen this before when servlet-2.5 and servlet-api 3.0 are both in the
> classpath
Yeah, I'm testing a change to the solr-core POM that would make the servlet
dependency use the "provided" scope, which would exclude it from the runtime
classpath.
Seems to fix the trunk failures you're referring to in the DIH tests. Running
all Solr tests locally now before I commit the change.
{quote}
See SOLR-3263
> Improve exception handling / logging for ScriptTransformer.init()
> -
>
> Key: SOLR-3260
> URL: https://issues.apache.org/jira/browse/SOLR-3260
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 3.5, 4.0
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Trivial
> Fix For: 3.6, 4.0
>
> Attachments: SOLR-3260.patch
>
>
> This came up on the user-list. ScriptTransformer logs the same "need a >=1.6
> jre" message for several problems, making debugging difficult for users.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()
[
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234477#comment-13234477
]
Steven Rowe commented on SOLR-3260:
---
{quote}
bq. class "javax.servlet.FilterRegistration"'s signer information does not
match signer information of other classes in the same package
I have seen this before when servlet-2.5 and servlet-api 3.0 are both in the
classpath
{quote}
Yeah, I'm testing a change to the solr-core POM that would make the servlet
dependency use the "provided" scope, which would exclude it from the runtime
classpath.
Seems to fix the trunk failures you're referring to in the DIH tests. Running
all Solr tests locally now before I commit the change.
> Improve exception handling / logging for ScriptTransformer.init()
> -
>
> Key: SOLR-3260
> URL: https://issues.apache.org/jira/browse/SOLR-3260
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 3.5, 4.0
>Reporter: James Dyer
>Assignee: James Dyer
>Priority: Trivial
> Fix For: 3.6, 4.0
>
> Attachments: SOLR-3260.patch
>
>
> This came up on the user-list. ScriptTransformer logs the same "need a >=1.6
> jre" message for several problems, making debugging difficult for users.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3260) Improve exception handling / logging for ScriptTransformer.init()
[ https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234449#comment-13234449 ] Steven Rowe commented on SOLR-3260: --- I see we got the same failures on the trunk Maven build today: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/431/testReport/ I'll forward-port my test-skipping changes to trunk. > Improve exception handling / logging for ScriptTransformer.init() > - > > Key: SOLR-3260 > URL: https://issues.apache.org/jira/browse/SOLR-3260 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 3.5, 4.0 >Reporter: James Dyer >Assignee: James Dyer >Priority: Trivial > Fix For: 3.6, 4.0 > > Attachments: SOLR-3260.patch > > > This came up on the user-list. ScriptTransformer logs the same "need a >=1.6 > jre" message for several problems, making debugging difficult for users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3260) Improve exception handling / logging for ScriptTransformer.init()
[ https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234451#comment-13234451 ] Steven Rowe commented on SOLR-3260: --- bq. In light of the maven 3.x failure, I think I need to move some of the reflection calls from the 3nd try/catch to the 2nd. This means we can ignore 2 of the 3 exceptions instead of all 3. +1 > Improve exception handling / logging for ScriptTransformer.init() > - > > Key: SOLR-3260 > URL: https://issues.apache.org/jira/browse/SOLR-3260 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 3.5, 4.0 >Reporter: James Dyer >Assignee: James Dyer >Priority: Trivial > Fix For: 3.6, 4.0 > > Attachments: SOLR-3260.patch > > > This came up on the user-list. ScriptTransformer logs the same "need a >=1.6 > jre" message for several problems, making debugging difficult for users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3260) Improve exception handling / logging for ScriptTransformer.init()
[ https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233876#comment-13233876 ] Steven Rowe commented on SOLR-3260: --- I committed the test skipping changes to branch_3x. I haven't seen the same problem (yet) on trunk, so I'll hold off there. > Improve exception handling / logging for ScriptTransformer.init() > - > > Key: SOLR-3260 > URL: https://issues.apache.org/jira/browse/SOLR-3260 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 3.5, 4.0 >Reporter: James Dyer >Assignee: James Dyer >Priority: Trivial > Fix For: 3.6, 4.0 > > Attachments: SOLR-3260.patch > > > This came up on the user-list. ScriptTransformer logs the same "need a >=1.6 > jre" message for several problems, making debugging difficult for users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3260) Improve exception handling / logging for ScriptTransformer.init()
[ https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233871#comment-13233871 ] Steven Rowe commented on SOLR-3260: --- bq. I am a bit confused why it is giving the "eval failed..." message though. It's an NPE, but beyond that I'm not sure what's happening. The branch_3x Maven job compiles under a 1.5 JDK, then runs tests via Maven's Surefire plugin under a 1.6 (OpenJDK) JVM. These tests appear to pass on the Solr_3x job under the same 1.6 JVM, though, so there's something weird going on here. (The Solr_3x job runs under Ant, but I'm not sure why the Ant/Maven difference would be the cause of this.) bq. Why don't you make the fix you've proposed and I'll look later to see if there is something less-blunt we can do. Sound ok? Sure, I'll commit those changes now. > Improve exception handling / logging for ScriptTransformer.init() > - > > Key: SOLR-3260 > URL: https://issues.apache.org/jira/browse/SOLR-3260 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 3.5, 4.0 >Reporter: James Dyer >Assignee: James Dyer >Priority: Trivial > Fix For: 3.6, 4.0 > > Attachments: SOLR-3260.patch > > > This came up on the user-list. ScriptTransformer logs the same "need a >=1.6 > jre" message for several problems, making debugging difficult for users. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3260) Improve exception handling / logging for ScriptTransformer.init()
[
https://issues.apache.org/jira/browse/SOLR-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233851#comment-13233851
]
Steven Rowe commented on SOLR-3260:
---
Hi James,
The branch_3x Maven Jenkins job is now failing in {{TestScriptTransformer}} as
a result of your commit from this issue, e.g.
https://builds.apache.org/job/Lucene-Solr-Maven-3.x/432/testReport/.
I'd like to expand the set of exception message checked in the JUnit
assumptions that allow tests to be skipped to include the two new messages your
changes on this issue introduced:
Currently:
{noformat}
} catch (DataImportHandlerException e) {
assumeFalse("JRE does not contain a JavaScript engine (OpenJDK)",
e.getMessage().startsWith("
[jira] [Commented] (LUCENE-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233049#comment-13233049 ] Steven Rowe commented on LUCENE-3885: - Committed to branch_3x and trunk > smokeTestRelease.checkMaven should not require a release branch > --- > > Key: LUCENE-3885 > URL: https://issues.apache.org/jira/browse/LUCENE-3885 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Reporter: Robert Muir > Attachments: LUCENE-3885.patch > > > Currently this throws an exception, but I think it should unpack any pom > templates it needs from the artifacts themselves. > # its nice to be able to generate and test RC's without having an official > branch yet. I am currently doing this just to > move us closer to release (just trying to find bugs etc). Also anyone > should be able to just toss up an RC at any time. > # its better to test the artifacts themselves rather than anything in SVN. At > the least the -src jars have an svn export > so this should work... if it doesn't, then there is a packaging bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232778#comment-13232778 ] Steven Rowe commented on LUCENE-3885: - bq. the likelihood of a mismatch between the local checkout and the release branch is higher :) hmm, that's a bit obvious I just meant that relying on the local checkout could be problematic if it's not the same branch as the one over which the RC is being constructed. > smokeTestRelease.checkMaven should not require a release branch > --- > > Key: LUCENE-3885 > URL: https://issues.apache.org/jira/browse/LUCENE-3885 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Reporter: Robert Muir > > Currently this throws an exception, but I think it should unpack any pom > templates it needs from the artifacts themselves. > # its nice to be able to generate and test RC's without having an official > branch yet. I am currently doing this just to > move us closer to release (just trying to find bugs etc). Also anyone > should be able to just toss up an RC at any time. > # its better to test the artifacts themselves rather than anything in SVN. At > the least the -src jars have an svn export > so this should work... if it doesn't, then there is a packaging bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232774#comment-13232774 ] Steven Rowe commented on LUCENE-3885: - bq. as a simple workaround can the smokeTester.py (which sits in dev-tools/scripts) just look for ../maven (from its own location as a reference)? Yes, I think that should work, but this should be done only if the release branch isn't available, since when there is a release branch, the likelihood of a mismatch between the local checkout and the release branch is higher. > smokeTestRelease.checkMaven should not require a release branch > --- > > Key: LUCENE-3885 > URL: https://issues.apache.org/jira/browse/LUCENE-3885 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Reporter: Robert Muir > > Currently this throws an exception, but I think it should unpack any pom > templates it needs from the artifacts themselves. > # its nice to be able to generate and test RC's without having an official > branch yet. I am currently doing this just to > move us closer to release (just trying to find bugs etc). Also anyone > should be able to just toss up an RC at any time. > # its better to test the artifacts themselves rather than anything in SVN. At > the least the -src jars have an svn export > so this should work... if it doesn't, then there is a packaging bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232771#comment-13232771 ] Steven Rowe commented on LUCENE-3885: - Also, because of the way the POMs are structured, those that "aggregate" (recurse in sub-modules) but are not parents (e.g. the lucene and solr contrib POMs) are not released, since the release artifacts don't refer to them. Without them, it's impossible to tell which artifacts should be there. > smokeTestRelease.checkMaven should not require a release branch > --- > > Key: LUCENE-3885 > URL: https://issues.apache.org/jira/browse/LUCENE-3885 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Reporter: Robert Muir > > Currently this throws an exception, but I think it should unpack any pom > templates it needs from the artifacts themselves. > # its nice to be able to generate and test RC's without having an official > branch yet. I am currently doing this just to > move us closer to release (just trying to find bugs etc). Also anyone > should be able to just toss up an RC at any time. > # its better to test the artifacts themselves rather than anything in SVN. At > the least the -src jars have an svn export > so this should work... if it doesn't, then there is a packaging bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3885) smokeTestRelease.checkMaven should not require a release branch
[ https://issues.apache.org/jira/browse/LUCENE-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232767#comment-13232767 ] Steven Rowe commented on LUCENE-3885: - In the past we've released with maven artifacts missing. That's why the svn check is done. svn export excludes dev-tools, so the pom templates aren't available. > smokeTestRelease.checkMaven should not require a release branch > --- > > Key: LUCENE-3885 > URL: https://issues.apache.org/jira/browse/LUCENE-3885 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Reporter: Robert Muir > > Currently this throws an exception, but I think it should unpack any pom > templates it needs from the artifacts themselves. > # its nice to be able to generate and test RC's without having an official > branch yet. I am currently doing this just to > move us closer to release (just trying to find bugs etc). Also anyone > should be able to just toss up an RC at any time. > # its better to test the artifacts themselves rather than anything in SVN. At > the least the -src jars have an svn export > so this should work... if it doesn't, then there is a packaging bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232685#comment-13232685 ] Steven Rowe commented on LUCENE-3882: - Maven Ant Tasks generates the hashes, so we would have to delete them after they are created. > maven-metadata.xml's are only hashed but not signed > --- > > Key: LUCENE-3882 > URL: https://issues.apache.org/jira/browse/LUCENE-3882 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Reporter: Robert Muir > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3882.patch > > > we only produce .sha/.md5 for these files, but not .asc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3882) maven-metadata.xml's are only hashed but not signed
[
https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232670#comment-13232670
]
Steven Rowe commented on LUCENE-3882:
-
These hashes appear to be regenerated by the repository (I checked the
Maven-core hashes and they matched), and as a result, the hashes submitted to
the repo are ignored.
However, some people use the results of {{generate-maven-artifacts}} directly,
in which case these hashes may provide some utility? And I don't think they're
doing any harm.
So I'm -0 to stop making hashes for these files.
> maven-metadata.xml's are only hashed but not signed
> ---
>
> Key: LUCENE-3882
> URL: https://issues.apache.org/jira/browse/LUCENE-3882
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Reporter: Robert Muir
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3882.patch
>
>
> we only produce .sha/.md5 for these files, but not .asc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3882) maven-metadata.xml's are only hashed but not signed
[ https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232661#comment-13232661 ] Steven Rowe commented on LUCENE-3882: - bq. OK to cancel this issue then? +1 > maven-metadata.xml's are only hashed but not signed > --- > > Key: LUCENE-3882 > URL: https://issues.apache.org/jira/browse/LUCENE-3882 > Project: Lucene - Java > Issue Type: Bug > Components: general/build >Reporter: Robert Muir > Fix For: 3.6, 4.0 > > Attachments: LUCENE-3882.patch > > > we only produce .sha/.md5 for these files, but not .asc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3882) maven-metadata.xml's are only hashed but not signed
[
https://issues.apache.org/jira/browse/LUCENE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232655#comment-13232655
]
Steven Rowe commented on LUCENE-3882:
-
Robert, I think it's not necessary/useful to sign these files.
In Maven Central, many projects don't have signatures for this file, e.g.
http://search.maven.org/#browse|1946773355 ({{org.apache.apache}}, the Apache
parent POM.
I think the issue is that when Maven artifacts are uploaded, for each artifact,
entries from the maven-metadata.xml file's contents are merged with the
existing version of that file. As a result, the signature will no longer apply.
Maven-core is an example of a project where they used to sign this file, then
stopped doing it, but left the signature in the repo:
[http://search.maven.org/#browse|-1493030540]. Note that the
{{maven-metadata.xml.asc}} file is dated 2006.
> maven-metadata.xml's are only hashed but not signed
> ---
>
> Key: LUCENE-3882
> URL: https://issues.apache.org/jira/browse/LUCENE-3882
> Project: Lucene - Java
> Issue Type: Bug
> Components: general/build
>Reporter: Robert Muir
> Fix For: 3.6, 4.0
>
> Attachments: LUCENE-3882.patch
>
>
> we only produce .sha/.md5 for these files, but not .asc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3880) UAX29URLEmailTokenizer fails to recognize emails as such when the mailto: scheme is prepended
[
https://issues.apache.org/jira/browse/LUCENE-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232308#comment-13232308
]
Steven Rowe commented on LUCENE-3880:
-
bq. Can we maybe (as discussed before) also add a corresponding Analyzer (clone
of StandardAna)?
+1
> UAX29URLEmailTokenizer fails to recognize emails as such when the mailto:
> scheme is prepended
> -
>
> Key: LUCENE-3880
> URL: https://issues.apache.org/jira/browse/LUCENE-3880
> Project: Lucene - Java
> Issue Type: Bug
>Affects Versions: 3.5, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Minor
> Attachments: LUCENE-3880.patch
>
>
> As [reported by Kai Gülzau on
> solr-user|http://markmail.org/message/n32kji3okqm2c5qn]:
> UAX29URLEmailTokenizer seems to split at the wrong place:
> {noformat}mailto:t...@example.org{noformat} ->
> {noformat}mailto:test{noformat}
> {noformat}example.org{noformat}
> As a workaround I use
> {code:xml}
> mailto:";
> replacement="mailto: "/>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3880) UAX29URLEmailTokenizer fails to recognize emails as such when the mailto: scheme is prepended
[
https://issues.apache.org/jira/browse/LUCENE-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232284#comment-13232284
]
Steven Rowe commented on LUCENE-3880:
-
[RFC 2368|http://tools.ietf.org/html/rfc2368] describes URLs employing the
{{mailto:}} scheme; this RFC has been obsoleted by [RFC
6068|http://tools.ietf.org/html/rfc6068], which describes the {{mailto:}} *URI*
scheme.
{{mailto:}} URIs can contain multiple email addresses, and fielded information
including CC, BCC, Subject, and Body - in short, the entire contents of an
email message.
However, a significant proportion of (probably most) {{mailto:}} URIs in the
wild contain just a single email address. Short of handling all aspects of the
{{mailto:}} scheme (out of scope for this issue), I think it would be useful to
employ a trick similar to the charFilter hack described by Kai Gülzau:
explicitly split "mailto:"; off from a following email address, allowing the
email address to be recognized as such.
> UAX29URLEmailTokenizer fails to recognize emails as such when the mailto:
> scheme is prepended
> -
>
> Key: LUCENE-3880
> URL: https://issues.apache.org/jira/browse/LUCENE-3880
> Project: Lucene - Java
> Issue Type: Bug
>Affects Versions: 3.5, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Minor
>
> As [reported by Kai Gülzau on
> solr-user|http://markmail.org/message/n32kji3okqm2c5qn]:
> UAX29URLEmailTokenizer seems to split at the wrong place:
> {noformat}mailto:t...@example.org{noformat} ->
> {noformat}mailto:test{noformat}
> {noformat}example.org{noformat}
> As a workaround I use
> {code:xml}
> mailto:";
> replacement="mailto: "/>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3223) excludes the lower bound in inclusive range queries with characters
[ https://issues.apache.org/jira/browse/SOLR-3223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226876#comment-13226876 ] Steven Rowe commented on SOLR-3223: --- abhimanyu, this does not appear to be a bug, but rather a question of how to use Solr. Please ask your question again on the solr users' mailing list: [http://lucene.apache.org/solr/discussion.html]. > excludes the lower bound in inclusive range queries with characters > > > Key: SOLR-3223 > URL: https://issues.apache.org/jira/browse/SOLR-3223 > Project: Solr > Issue Type: Bug >Affects Versions: 3.5, 4.0 >Reporter: abhimanyu > Labels: range, text > > while using a range query to retrieve all the record over a inclusive range > with characters , eg > name : [a TO e] > the returned result set excludes the lower bound in range query, like in this > case it does not include the results with 'e' . > Please suggest any solution for this . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3159) Upgrade to Jetty 8
[
https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13226520#comment-13226520
]
Steven Rowe commented on SOLR-3159:
---
{quote}
bq. Wierdly, I don't see an annoucement for v8.1.2
Sorry .. poor wording on my part: the issue is marked fixed in 8.1.2 but the
jetty Jira system lists 8.1.2 as unreleased (ie: fixed on jetty's 8.1 branch
for hte next release i guess)
{quote}
Well, the weirdness from my perspective is that 8.1.2 is downloadable and
marked as a release: http://download.eclipse.org/jetty/
> Upgrade to Jetty 8
> --
>
> Key: SOLR-3159
> URL: https://issues.apache.org/jira/browse/SOLR-3159
> Project: Solr
> Issue Type: Task
>Reporter: Ryan McKinley
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-3159-maven.patch
>
>
> Solr is currently tested (and bundled) with a patched jetty-6 version.
> Ideally we can release and test with a standard version.
> Jetty-6 (at codehaus) is just maintenance now. New development and
> improvements are now hosted at eclipse. Assuming performance is equivalent,
> I think we should switch to Jetty 8.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13225688#comment-13225688 ] Steven Rowe commented on SOLR-3159: --- bq. apparently fixed in 8.1.2 ? Wierdly, I don't see an annoucement for v8.1.2 on [the jetty-announce list archives|http://dev.eclipse.org/mhonarc/lists/jetty-announce/] (unlike v8.1.1, which was announced), and the Maven artifacts haven't shown up in Maven central (again, unlike the v8.1.1 artifacts). The full 8.1.2 version name is 8.1.2.v20120302, where AFAICT the suffix is the release date, six days ago. Unlike 8.1.2, the Maven Central artifacts for 8.1.0 and 8.1.1 are dated one day after the (assumed) release date from the version number. > Upgrade to Jetty 8 > -- > > Key: SOLR-3159 > URL: https://issues.apache.org/jira/browse/SOLR-3159 > Project: Solr > Issue Type: Task >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3159-maven.patch > > > Solr is currently tested (and bundled) with a patched jetty-6 version. > Ideally we can release and test with a standard version. > Jetty-6 (at codehaus) is just maintenance now. New development and > improvements are now hosted at eclipse. Assuming performance is equivalent, > I think we should switch to Jetty 8. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3204) solr-commons-csv must not use the org.apache.commons.csv package
[
https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224906#comment-13224906
]
Steven Rowe commented on SOLR-3204:
---
{quote}
or C)
you can publish the artifacts, link to them as optional, and users can specify
in their pom's which jar to bring in. This is not that uncommon -- it is the
expected way to deal with slf4j for example, where one and only one of several
options must be chosen at runtime. Same thing with the bytecode re-writing
dependency in Hibernate.
bq. -1 from me for using optional dependencies to counter Maven's virality.
Please consider this further with option C) above for artifacts that live in a
custom groupId:artifactId namespace but not a custom package.
{quote}
My implicit assumption was that as a result of using optional dependencies, we
would cease publishing any third-party dependencies to Maven Central. (That's
part of what I was -1'ing.)
> solr-commons-csv must not use the org.apache.commons.csv package
>
>
> Key: SOLR-3204
> URL: https://issues.apache.org/jira/browse/SOLR-3204
> Project: Solr
> Issue Type: Bug
> Components: Build
>Affects Versions: 3.5
>Reporter: Emmanuel Bourg
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 3.6, 4.0
>
> Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch,
> SOLR-3204.patch, apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar,
> apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt,
> solr-csv.patch
>
>
> The solr-commons-csv artifact reused the code from the Apache Commons CSV
> project but the package wasn't changed to something else than
> org.apache.commons.csv in the process. This creates a compatibility issue as
> the Apache Commons team works toward an official release of Commons CSV. It
> prevents Commons CSV from using its own org.apache.commons.csv package, or
> forces the renaming of all the classes to avoid a classpath conflict.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224900#comment-13224900 ] Steven Rowe commented on SOLR-3159: --- bq. Maven configuration: [...] Committing shortly. Done: r1298247 > Upgrade to Jetty 8 > -- > > Key: SOLR-3159 > URL: https://issues.apache.org/jira/browse/SOLR-3159 > Project: Solr > Issue Type: Task >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3159-maven.patch > > > Solr is currently tested (and bundled) with a patched jetty-6 version. > Ideally we can release and test with a standard version. > Jetty-6 (at codehaus) is just maintenance now. New development and > improvements are now hosted at eclipse. Assuming performance is equivalent, > I think we should switch to Jetty 8. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3802) Grouping collector that computes grouped facet counts
[
https://issues.apache.org/jira/browse/LUCENE-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224871#comment-13224871
]
Steven Rowe commented on LUCENE-3802:
-
When I run tests from Maven, I get:
{quote}
---
Test set: org.apache.lucene.search.grouping.AbstractGroupingTestCase
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.046 sec <<< FA
ILURE!
initializationError(org.apache.lucene.search.grouping.AbstractGroupingTestCase)
Time elapsed: 0.003 sec <<< ERROR!
[...]
Results :
Tests in error:
initializationError(org.apache.lucene.search.grouping.AbstractGroupingTestCase):
No runnable methods!
{quote}
The Ant build doesn't have this problem.
I'll add an {{@Ignore}} annotation to this class to keep Maven happy.
> Grouping collector that computes grouped facet counts
> -
>
> Key: LUCENE-3802
> URL: https://issues.apache.org/jira/browse/LUCENE-3802
> Project: Lucene - Java
> Issue Type: New Feature
> Components: modules/grouping
>Reporter: Martijn van Groningen
> Fix For: 4.0
>
> Attachments: LUCENE-3802.patch, LUCENE-3802.patch, LUCENE-3802.patch,
> LUCENE-3802.patch
>
>
> Spinoff from issue SOLR-2898.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224835#comment-13224835 ] Steven Rowe commented on SOLR-3159: --- bq. Am I missing something? Woohoo! Found it!: [org.eclipse.jetty.orbit:javax.servlet:3.0.0.v201112011016|http://repo1.maven.org/maven2/org/eclipse/jetty/orbit/javax.servlet/3.0.0.v201112011016/] > Upgrade to Jetty 8 > -- > > Key: SOLR-3159 > URL: https://issues.apache.org/jira/browse/SOLR-3159 > Project: Solr > Issue Type: Task >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > > Solr is currently tested (and bundled) with a patched jetty-6 version. > Ideally we can release and test with a standard version. > Jetty-6 (at codehaus) is just maintenance now. New development and > improvements are now hosted at eclipse. Assuming performance is equivalent, > I think we should switch to Jetty 8. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3159) Upgrade to Jetty 8
[ https://issues.apache.org/jira/browse/SOLR-3159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224827#comment-13224827 ] Steven Rowe commented on SOLR-3159: --- Hi Ryan, I'm trying to fix the Maven build to use Jetty 8, and I see that you've upgraded servlet-api jar to v3.0, but I can't find that version in the Maven Central repository. The two closest I found are [javax.servlet:javax-servlet.api:3.0.1|http://repo1.maven.org/maven2/javax/servlet/javax.servlet-api/3.0.1/] and [javax.servlet:servlet-api:3.0-alpha-1|http://repo1.maven.org/maven2/javax/servlet/servlet-api/3.0-alpha-1/]. Am I missing something? If you don't know of a 3.0 Maven artifact, can we upgrade to the 3.0.1 artifact in Maven central? (I did not test this myself.) > Upgrade to Jetty 8 > -- > > Key: SOLR-3159 > URL: https://issues.apache.org/jira/browse/SOLR-3159 > Project: Solr > Issue Type: Task >Reporter: Ryan McKinley >Priority: Minor > Fix For: 4.0 > > > Solr is currently tested (and bundled) with a patched jetty-6 version. > Ideally we can release and test with a standard version. > Jetty-6 (at codehaus) is just maintenance now. New development and > improvements are now hosted at eclipse. Assuming performance is equivalent, > I think we should switch to Jetty 8. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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-3204) solr-commons-csv must not use the org.apache.commons.csv package
[ https://issues.apache.org/jira/browse/SOLR-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224818#comment-13224818 ] Steven Rowe commented on SOLR-3204: --- bq. Steven Rowe: If I broke something with maven, can you please fix? I have no idea... :) Only one problem: the name of the source file in the bootstrap profile (copies lib/ files to users' local Maven repositories) - I just committed the file renaming to both trunk and branch_3x. > solr-commons-csv must not use the org.apache.commons.csv package > > > Key: SOLR-3204 > URL: https://issues.apache.org/jira/browse/SOLR-3204 > Project: Solr > Issue Type: Bug > Components: Build >Affects Versions: 3.5 >Reporter: Emmanuel Bourg >Assignee: Uwe Schindler >Priority: Blocker > Fix For: 3.6, 4.0 > > Attachments: SOLR-3204.patch, SOLR-3204.patch, SOLR-3204.patch, > SOLR-3204.patch, apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, > apache-solr-commons-csv-1.0-SNAPSHOT-r966014.jar, rule.txt, rule.txt, > solr-csv.patch > > > The solr-commons-csv artifact reused the code from the Apache Commons CSV > project but the package wasn't changed to something else than > org.apache.commons.csv in the process. This creates a compatibility issue as > the Apache Commons team works toward an official release of Commons CSV. It > prevents Commons CSV from using its own org.apache.commons.csv package, or > forces the renaming of all the classes to avoid a classpath conflict. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa 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
