[
https://issues.apache.org/jira/browse/SOLR-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-2857:
Attachment: SOLR-2857-content-type-refactor.patch
Here is another version that refactors the base cl
I'm getting a reproducible failure with:
ant test -Dtests.class=*.TestReplicationHandler -Dtests.method=test
-Dtests.seed=414E41D45EA70F7E -Dargs="-Dfile.encoding=Cp1252"
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.or
[
https://issues.apache.org/jira/browse/SOLR-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated SOLR-3402:
-
Attachment: SOLR-3402.patch
Patch moves lenient parsing of Versions into Version. Still need to move some
Is anyone else seeing lots of failures for
PingRequestHandlerTest.testDisablingServer?
I get something like this 1/3 of the time -- but it does not reproduce:
[junit4] Suite: org.apache.solr.handler.PingRequestHandlerTest
[junit4]> (@BeforeClass output)
[junit4] 2> Creating dataDir:
C
[
https://issues.apache.org/jira/browse/SOLR-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-2690:
---
Attachment: SOLR-2690.patch
Updated patch, adds TimeZoneUtils (with tests) to do what TimeZone.getTimeZone
sh
[
https://issues.apache.org/jira/browse/SOLR-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated SOLR-3402:
-
Description:
Currently the Lucene Version value is put into the Map that is passed to the
{{init}} method
[
https://issues.apache.org/jira/browse/SOLR-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated SOLR-3402:
-
Attachment: SOLR-3402.patch
Patch doing what is described above.
Some nocommits in {{BaseTokeTestCase}} t
[
https://issues.apache.org/jira/browse/SOLR-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-2857:
Attachment: SOLR-2857-update-content-type.patch
last patch was missing files
> Mult
[
https://issues.apache.org/jira/browse/SOLR-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-2857:
Attachment: SOLR-2857-update-content-type.patch
cleans things up a bit more, but the UpdateRequestHa
Chris Male created SOLR-3403:
Summary: Move logging of deprecated Analysis Factory inside
Factory itself
Key: SOLR-3403
URL: https://issues.apache.org/jira/browse/SOLR-3403
Project: Solr
Issue T
Chris Male created SOLR-3402:
Summary: Parse Version outside of Analysis Factories
Key: SOLR-3402
URL: https://issues.apache.org/jira/browse/SOLR-3402
Project: Solr
Issue Type: Improvement
[
https://issues.apache.org/jira/browse/SOLR-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male resolved SOLR-3363.
--
Resolution: Fixed
Fix Version/s: 4.0
Assignee: Chris Male
Resolved in trunk.
I got it.
I found my test codes some problem.
the new test result is:
when minShould=1, new algorithm is a little bit faster than old one. when
minShould>1, old algorithm is faster.
On Sun, Apr 22, 2012 at 3:32 AM, Mikhail Khludnev <
mkhlud...@griddynamics.com> wrote:
> Li,
>
> I can give you my
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-2074:
Fix Version/s: (was: 4.0)
> GeoRSS ResponseWriter
> -
>
>
[
https://issues.apache.org/jira/browse/LUCENE-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260149#comment-13260149
]
Han Jiang commented on LUCENE-3892:
---
Thank all of you for providing me this opportunity
On Mon, Apr 23, 2012 at 8:42 PM, Chris Male wrote:
> I'm with Steve here, -1. I think the arguments have already been well
> articulated and the issue seems to be about dependency management in general
> not just about Maven. However I also absolutely agree with Robert that we
> need to make thi
On Mon, Apr 23, 2012 at 8:28 PM, Benson Margulies wrote:
>
> If you like (or can live with) everything about the situation except
> for the additional Maven burden, then it's worthwhile for us
> Maven-heads to offer schemes that purport to do Maven without making
> it (much) worse. But if the situ
I'm with Steve here, -1. I think the arguments have already been well
articulated and the issue seems to be about dependency management in
general not just about Maven. However I also absolutely agree with Robert
that we need to make this easier somehow.
One thing I thought, is there any way we
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiyu Li updated SOLR-2074:
--
Attachment: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt
Patch updated: SOLR-2074.Mattmann.Quach.Li.042312.patch
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiyu Li updated SOLR-2074:
--
Comment: was deleted
(was: Patch updated: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt
This updated patch also
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiyu Li updated SOLR-2074:
--
Attachment: (was: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt)
> GeoRSS ResponseWriter
> --
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiyu Li updated SOLR-2074:
--
Attachment: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt
Patch updated: SOLR-2074.Mattmann.Quach.Li.042312.patch
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiyu Li updated SOLR-2074:
--
Attachment: (was: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt)
> GeoRSS ResponseWriter
> --
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiyu Li updated SOLR-2074:
--
Comment: was deleted
(was: Patch updated: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt
This updated patch also
> Its definitely overwhelming right now, the size of the codebase and
> the number of dependencies, given what we have. I think we should be
> considering all options. Maven packaging just adds to the complexity
> due to the fact of how it manages dependencies (they must themselves
> be in maven so
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiyu Li updated SOLR-2074:
--
Attachment: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt
> GeoRSS ResponseWriter
> -
>
>
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiyu Li updated SOLR-2074:
--
Attachment: (was: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt)
> GeoRSS ResponseWriter
> --
[
https://issues.apache.org/jira/browse/SOLR-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260107#comment-13260107
]
Ryan McKinley commented on SOLR-3367:
-
The auto-update continues to check even when you
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260105#comment-13260105
]
Yiyu Li edited comment on SOLR-2074 at 4/24/12 12:15 AM:
-
Patch upd
[
https://issues.apache.org/jira/browse/SOLR-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yiyu Li updated SOLR-2074:
--
Attachment: SOLR-2074.Mattmann.Quach.Li.042312.patch.txt
This updated patch also outputs the "pubDate" for the G
> for Solr, as an application, maybe we should just be making a massive
> solr.jar anyway for the binary release that you java -jar (leaving the
> webapp as an implementation detail or something):
The solr application is solr.war (not .jar) -- we can safely dump
whatever hacked/patched jar files i
On Mon, Apr 23, 2012 at 7:46 PM, Benson Margulies wrote:
> It makes perfect sense. Some of us do, however, embed Solr (for tests
> or other unrecommended reasons), or build our own Solr plugins with
> dependencies on the existing Solr plugins, and we would thus mourn, or
> have to go back to doing
On Mon, Apr 23, 2012 at 7:45 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 7:31 PM, Benson Margulies
> wrote:
>> I have a suggestion for how to get from here to the exit.
>>
>> Forget about maven for the moment, and please explain to me exactly
>> how you'd like to handle bugfixes to other Ap
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13430/
1 tests failed.
REGRESSION: org.apache.solr.handler.TestReplicationHandler.test
Error Message:
no segments* file found in
org.apache.lucene.store.SimpleFSDirectory@/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-
On Mon, Apr 23, 2012 at 7:30 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies
> wrote:
>> On Mon, Apr 23, 2012 at 6:31 PM, Robert Muir wrote:
>>> On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss
>>> wrote:
The issue with such poms is that once you want to publis
[
https://issues.apache.org/jira/browse/LUCENE-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260085#comment-13260085
]
Michael McCandless commented on LUCENE-2686:
LiLi can you post the test case
On Mon, Apr 23, 2012 at 7:31 PM, Benson Margulies wrote:
> I have a suggestion for how to get from here to the exit.
>
> Forget about maven for the moment, and please explain to me exactly
> how you'd like to handle bugfixes to other Apache items in releases if
> all you had to worry about was ant
On Mon, Apr 23, 2012 at 7:21 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies
> wrote:
>
>> Thus, I claim that this debate is fundamentally about package
>> renaming, not publication.
>>
>> Shall I be maximally annoying and mention OSGi again?
>>
>
> Its not really a de
On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies wrote:
> On Mon, Apr 23, 2012 at 6:31 PM, Robert Muir wrote:
>> On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss
>> wrote:
>>>
>>> The issue with such poms is that once you want to publish your stuff
>>> to maven central it won't work (because all de
On Mon, Apr 23, 2012 at 6:49 PM, Benson Margulies wrote:
> Thus, I claim that this debate is fundamentally about package
> renaming, not publication.
>
> Shall I be maximally annoying and mention OSGi again?
>
Its not really a debate, its 'how do we do this'. (I can argue your
claim is wrong, bu
On Mon, Apr 23, 2012 at 6:31 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss
> wrote:
>>
>> The issue with such poms is that once you want to publish your stuff
>> to maven central it won't work (because all dependencies must be
>> available and there is no "local" repositor
On Mon, Apr 23, 2012 at 6:28 PM, Dawid Weiss
wrote:
>
> The issue with such poms is that once you want to publish your stuff
> to maven central it won't work (because all dependencies must be
> available and there is no "local" repository).
>
This is the problem I am asking about.
I don't care a
>> And now you hit the nail on the head. Because your 'option 2'
>> (download+patch) with ivy doesnt involve 'publishing'. we just
>> download and patch.
You can take a look at Google Caliper -- they used maven for building
but required
JARs that were inside the project (not on maven central). The
On Mon, Apr 23, 2012 at 6:15 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 6:13 PM, Benson Margulies
> wrote:
>> On Mon, Apr 23, 2012 at 5:49 PM, Robert Muir wrote:
>>> On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies
>>> wrote:
>>>
b) Create a patching process that grabs their relea
On Mon, Apr 23, 2012 at 6:11 PM, Dawid Weiss
wrote:
>> I feel that currently, there is no option (maven limits us here). I'm
>> not sure if thats due to actual technical limitations in maven, or
>
> What Benson mentioned will work for maven, I don't see how it holds
> you back. If you publish an a
On Mon, Apr 23, 2012 at 6:13 PM, Benson Margulies wrote:
> On Mon, Apr 23, 2012 at 5:49 PM, Robert Muir wrote:
>> On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies
>> wrote:
>>
>>> b) Create a patching process that grabs their release package, fixes
>>> it, and builds it, renaming packages. Inc
On Mon, Apr 23, 2012 at 5:49 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies
> wrote:
>
>> b) Create a patching process that grabs their release package, fixes
>> it, and builds it, renaming packages. Include the patching process in
>> your source release.
>>
>
> I wou
> I feel that currently, there is no option (maven limits us here). I'm
> not sure if thats due to actual technical limitations in maven, or
What Benson mentioned will work for maven, I don't see how it holds
you back. If you publish an artefact for Ivy somewhere you can package
this JAR and publi
On 4/23/2012 at 5:58 PM, Robert Muir wrote:
> I feel that currently, there is no option (maven limits us here).
> I'm not sure if thats due to actual technical limitations in maven,
> or just because its complicated or unconventional or whatever, but
> I don't think we should let maven hold us bac
On Mon, Apr 23, 2012 at 5:54 PM, Mark Miller wrote:
>
> On Apr 23, 2012, at 5:46 PM, Uwe Schindler wrote:
>
>> And OUR source code was correct - PERIOD.
>
> I think more important than our code being correct is that our distributions
> work correctly. Being correct for the sake of it has no prac
On Apr 23, 2012, at 5:46 PM, Uwe Schindler wrote:
> And OUR source code was correct - PERIOD.
I think more important than our code being correct is that our distributions
work correctly. Being correct for the sake of it has no practical value. We
should strive for the best user experience. T
That works, you can download the source release using maven ("source" config)
and patch it (not automatically, but it's possible!).
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Robert Muir [mailto:rc
On Mon, Apr 23, 2012 at 5:47 PM, Benson Margulies wrote:
> b) Create a patching process that grabs their release package, fixes
> it, and builds it, renaming packages. Include the patching process in
> your source release.
>
I would *love* to be able to have this option available, but how will
t
On Mon, Apr 23, 2012 at 5:40 PM, Dawid Weiss
wrote:
>> Instead I'm asking how we handle bugfixes.
>
> This is a real problem. I've gone through this with recent updates to
> randomizedtesting package. There is
> no "clean" way of integrating a snapshot build or an interim package.
Thank you! This
Rob,
I personally think that the Apache policy issues here are not entirely
worked out, but let me try to summarize the situation.
Starting condition: a marooned bugfix or feature in some other Apache TLP.
1. Communicate with the other TLP, possibly siccing Uwe on their chair.
2. If they are un
Hi,
Don't be disappointed - I just say this: I would never have denied a release
with the Jetty UTF-8 bug! This bug was clearly out of our scope; so I don’t
care, I helped to investigate it, but fixing was not in Lucene's
responsibility, sorry. A release with the Jetty UTF-8 bug or the XALAN
X
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13426/
1 tests failed.
REGRESSION: org.apache.solr.handler.TestReplicationHandler.test
Error Message:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/solr-core/test/S0/org.apache.solr.handl
> Instead I'm asking how we handle bugfixes.
This is a real problem. I've gone through this with recent updates to
randomizedtesting package. There is
no "clean" way of integrating a snapshot build or an interim package.
With maven the integration can be done via snapshot repositories
(there are d
On 4/23/2012 at 5:33 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 5:29 PM, Uwe Schindler wrote:
> > Robert: I know that IVY also supports downloading from arbitrary
> > URLs, but that is missing stability and metadata).
>
> My questions have nothing to do with whether or not we release maven
>
On Mon, Apr 23, 2012 at 5:37 PM, Uwe Schindler wrote:
> Hi,
>
> The answer is quite clear: Not our problem! Note that bug in our release
> notes that there is a not-yet fixed zookeeper bug. We cannot make the world
> perfect. If there is a bug outside our responsibility, we can document it,
> b
Hi,
The answer is quite clear: Not our problem! Note that bug in our release notes
that there is a not-yet fixed zookeeper bug. We cannot make the world perfect.
If there is a bug outside our responsibility, we can document it, but not
necessarily fix it.
Uwe
-
Uwe Schindler
H.-H.-Meier-A
On Mon, Apr 23, 2012 at 5:29 PM, Uwe Schindler wrote:
> Robert: I know
> that IVY also supports downloading from arbitrary URLs, but that is missing
> stability and metadata).
>
My questions have nothing to do with whether or not we release maven
artifacts (if you read them, you will see that).
> Unless we get a wave of anti maven sentiment, it looks like things are
staying
> as they are right now anyway though. I just don't think any of us arguing
that
> Maven should not be our responsibility thinks that that would mean Maven
> support for Lucene/Solr would go away.
+1
No Anti-Maven st
Hi,
Thanks for clarification! This was one of the things that I never
understood, for me the additional maven build was just magic :-) This powers
my opinion, that the so called "maven builds" are simply another way of
publishing artifacts and that's important in my opinion, as we are using the
in
On Apr 23, 2012, at 5:09 PM, Uwe Schindler wrote:
> So we must publish maven artifacts to be successful on the open source
> market, sorry! (that's my opinion!)
I disagree that Lucene/Solr would not be popular if the committers and PMC did
not support Maven. In fact, I expect if there is real
I fixed it, then broke something else, then fixed that. It was a fun
cycle. Apparently, a new version of CMS is a little more strict than it
used to be with markdown, or a bug, idrk. If you have markdown inside of
any html, it treats it as plain text (this is normal). For some reason, it
used t
On 4/23/2012 at 5:09 PM, Uwe Schindler wrote:
> Finally, publishing maven artifacts has nothing to do with
> maven at all. We don't need a maven build to do that!
The Maven build is there to enable using Maven to check the correctness of the
POMs. I think this is essential. Prior to this, the L
I'm having trouble finding chained filter in the java lucene svn...
http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/contrib/?pathrev=990167
am I looking around in the wrong place?
> Date: Mon, 23 Apr 2012 11:19:51 +0300
> Subject: Re: Spatial contrib bug fixing
> From: ita...@
> copying them to the maven servers can be done completely without maven (at
This is true but doing it via maven (that is: compiling and testing
with actual dependencies) helps you to ensure it really is a usable
artefact. I've been doing tricks like building a JAR in ANT and then
simply attaching
[
https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259960#comment-13259960
]
Uwe Schindler commented on LUCENE-3312:
---
Hi Nikola,
I am glad to work with you this
Hi,
You might all know me as "die, maven, die" person, but this special case is
definitely not related to the issue mentioned at all:
The problem we had with commons csv was *not* related to maven at all, it
also affected our standard artifacts. The problem was that we were releasing
code in the
[
https://issues.apache.org/jira/browse/SOLR-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dyer resolved SOLR-3360.
--
Resolution: Fixed
Fix Version/s: 3.6.1
Assignee: James Dyer
Committed to 3.6 branch: r1
[
https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259947#comment-13259947
]
Chris Russell edited comment on SOLR-2894 at 4/23/12 9:05 PM:
--
[
https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259947#comment-13259947
]
Chris Russell edited comment on SOLR-2894 at 4/23/12 9:04 PM:
--
On Mon, Apr 23, 2012 at 4:54 PM, Dawid Weiss
wrote:
>
> I wouldn't be so sure that github's idea is to create endless forks,
> each ending up in a separate distribution :) I think it's to
> facilitate pulling changes back to the origin?
>
Not so sure, the idea is that forking is part of the desig
[
https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Russell updated SOLR-2894:
Attachment: distributed_pivot.patch
Some modifications to SOLR-2894.patch that I made while trying t
[
https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259947#comment-13259947
]
Chris Russell commented on SOLR-2894:
-
Hi Dan.
I have been working with your patch, 289
> If these projects don't want their code forked... dont offer it up on
> github under the Apache 2.0 license?
I wouldn't be so sure that github's idea is to create endless forks,
each ending up in a separate distribution :) I think it's to
facilitate pulling changes back to the origin?
Dawid
--
[
https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259939#comment-13259939
]
Nikola Tankovic commented on LUCENE-3312:
-
I want to thank you guys for the oppor
When 3.0.3 was ported, there were lots of changes and so we have to work with
re-porting all the contrib packages. (I think..)
> Date: Mon, 23 Apr 2012 11:19:51 +0300
> Subject: Re: Spatial contrib bug fixing
> From: ita...@code972.com
> To: lucene-net-...@lucene.apache.org
>
> One more thing -
On Mon, Apr 23, 2012 at 4:32 PM, Dawid Weiss
wrote:
>> Its also a good point that what i do on my github account, the apache
>> board has no control over (despite how powerful they might think they
>
> To my best knowledge this is the case, yes. People may not like the
> fact that you re-publish t
> Its also a good point that what i do on my github account, the apache
> board has no control over (despite how powerful they might think they
To my best knowledge this is the case, yes. People may not like the
fact that you re-publish the same code under the same packages but
there's really no r
[
https://issues.apache.org/jira/browse/LUCENE-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-4013.
Resolution: Fixed
Assignee: Michael McCandless
> DWPTpool shouldnt be pu
On Mon, Apr 23, 2012 at 3:53 PM, Dawid Weiss
wrote:
>> Really ??? But they won't criticize the fact someone put
>> http://code.google.com/p/language-detection/ into maven central?
>> http://search.maven.org/#artifactdetails|com.cybozu.labs|langdetect|1.1-20120112|jar
>
> I don't think even people
On Mon, Apr 23, 2012 at 3:53 PM, Dawid Weiss
wrote:
> I don't think even people who first accused Lucene of releasing
> commons-csv artifacts can address your question here. And I think if
> you published commons-csv on github they'd be equally upset.
>
Ok: so we just use https://github.com/Gasol
[
https://issues.apache.org/jira/browse/SOLR-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259896#comment-13259896
]
Rahul Babulal commented on SOLR-3390:
-
Thank you for the details.
For now, I am settin
> Really ??? But they won't criticize the fact someone put
> http://code.google.com/p/language-detection/ into maven central?
> http://search.maven.org/#artifactdetails|com.cybozu.labs|langdetect|1.1-20120112|jar
I don't think even people who first accused Lucene of releasing
commons-csv artifacts
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13422/
1 tests failed.
FAILED: org.apache.solr.handler.TestReplicationHandler.test
Error Message:
Backup success not detected:
0121.58
KB/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/s
[
https://issues.apache.org/jira/browse/SOLR-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259868#comment-13259868
]
Claudio R edited comment on SOLR-3360 at 4/23/12 7:42 PM:
--
Hi Mikh
[
https://issues.apache.org/jira/browse/SOLR-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259868#comment-13259868
]
Claudio R commented on SOLR-3360:
-
Hi Mikhail,
I did checkout from:
http://svn.apache.org
On Mon, Apr 23, 2012 at 3:23 PM, Benson Margulies wrote:
> Rob, did you mean 'Benson' by 'you' in that sentence? If so, I'm
> really sorry if I've given you the impression I think that that
> there's anything amiss with 3.6.0. All I meant to say was that, over
> the long haul, if the PMC was very
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13421/
1 tests failed.
FAILED: org.apache.solr.handler.TestReplicationHandler.test
Error Message:
Backup success not detected:
0121.58
KB/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build/s
Yep, sure. You don't need a property, btw., there is a condition for that --
wrap it into a fail and you're set.
D.
On Mon, Apr 23, 2012 at 7:33 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 1:29 PM, Dawid Weiss
> wrote:
>
>> Definitely not the early ones because they were buggy. 1.8.
On Mon, Apr 23, 2012 at 3:09 PM, Robert Muir wrote:
> On Mon, Apr 23, 2012 at 3:02 PM, Benson Margulies
> wrote:
>>
>> That's right. If you, Rob Muir, just so happen to set up a github
>> project with a fix to Xerces, and I, Benson Margulies, just happen to
>> help you publish it to Maven Centra
[
https://issues.apache.org/jira/browse/LUCENE-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259856#comment-13259856
]
Robert Muir commented on LUCENE-4013:
-
+1
> DWPTpool shouldnt be pub
[
https://issues.apache.org/jira/browse/LUCENE-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-4013:
---
Attachment: LUCENE-4013.patch
New patch, making a few more classes package private..
This is a test bug. I am committing a fix...
James Dyer
E-Commerce Systems
Ingram Content Group
(615) 213-4311
-Original Message-
From: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
Sent: Monday, April 23, 2012 2:09 PM
To: dev@lucene.apache.org
Subject: [JENKINS] Lucene-Solr
On Mon, Apr 23, 2012 at 3:02 PM, Benson Margulies wrote:
>
> That's right. If you, Rob Muir, just so happen to set up a github
> project with a fix to Xerces, and I, Benson Margulies, just happen to
> help you publish it to Maven Central, then the PMC, without (much)
> fear of hassle, can consume
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2314/
1 tests failed.
REGRESSION: org.apache.solr.handler.TestReplicationHandler.test
Error Message:
Backup success not detected:
0121,58
KB/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk-java7/checko
[
https://issues.apache.org/jira/browse/SOLR-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259843#comment-13259843
]
Mikhail Khludnev commented on SOLR-3360:
Claudio,
patched sources are https://githu
1 - 100 of 179 matches
Mail list logo
