[
https://issues.apache.org/jira/browse/SOLR-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12910906#action_12910906
]
Israel Ekpo commented on SOLR-1967:
---
If you are getting errors when unserializing the
On Sat, Sep 18, 2010 at 7:52 AM, Uwe Schindler u...@thetaphi.de wrote:
Helau!
LOL - that made my day uwe :D
(means +1)
same here! +1
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Lance Norskog
This still failes because of JUnit / Clover treats each local run as a
single test method. I will open an issue to fix that.
simon
On Sat, Sep 18, 2010 at 7:21 AM, Apache Hudson Server
hud...@hudson.apache.org wrote:
See https://hudson.apache.org/hudson/job/Lucene-trunk/1291/changes
Changes:
On Thu, Sep 16, 2010 at 2:45 PM, Robert Muir rcm...@gmail.com wrote:
Ok, I will create an issue.
For starters we could comment out these runners (for example, if code does
not work for a locale, it will fail 'eventually' due to the fact we pick a
random one anyway).
In the future maybe we
Rethink LocalizedTestCaseRunner with JUnit 4 - Clover OOM
-
Key: LUCENE-2652
URL: https://issues.apache.org/jira/browse/LUCENE-2652
Project: Lucene - Java
Issue Type: Test
[
https://issues.apache.org/jira/browse/LUCENE-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer resolved LUCENE-2648.
-
Fix Version/s: 4.0
Resolution: Fixed
committed in rev. 998445
Allow
: Finally, as far as getting someone to do the work, I can certainly
: volunteer to help in the following ways:
: * being RM if you are ok with a non-maven release (until LUCENE-2268
: is fixed, i am uncomfortable with maven)
In the past i've argued that enough users care about maven we
On Sat, Sep 18, 2010 at 7:59 AM, Steven A Rowe sar...@syr.edu wrote:
Maven artifact production under Lucene's/Solr's Ant build suffers from the
same problem as releasing generally: lack of automation. Too much manual
intervention is required to keep the .pom templates in sync, etc.
On Fri, Sep 17, 2010 at 9:45 PM, Chris Hostetter
hossman_luc...@fucit.orgwrote:
My unscientific, off the cuff, sociological impression is that once we
moved forward with
the multi-branch development plan and created the 3x branch, a lot of
people who use to be the big proponents of regular
[
https://issues.apache.org/jira/browse/SOLR-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911011#action_12911011
]
Yonik Seeley commented on SOLR-2123:
OK, so I'm thinking to treat this just like
thanks Simon, i have a patch in my local but i neglected to open
issue/upload it... sorry!
On Sat, Sep 18, 2010 at 6:35 AM, Simon Willnauer
simon.willna...@googlemail.com wrote:
This still failes because of JUnit / Clover treats each local run as a
single test method. I will open an issue to
[
https://issues.apache.org/jira/browse/LUCENE-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911031#action_12911031
]
Robert Muir commented on LUCENE-2651:
-
I tested the patch, i don't think we should add
[
https://issues.apache.org/jira/browse/LUCENE-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-2652:
Attachment: LUCENE-2652.patch
here's a patch to disable use of the runners.
really i think the
[
https://issues.apache.org/jira/browse/LUCENE-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer updated LUCENE-2652:
Attachment: LUCENE-2652.patch
{quote}
really i think the two runners
I don't get what is being proposed... are you guys really suggesting
we drop the ant generate-maven-artifacts target? and let people who
use maven sort it out for themselves? Making sure the generated poms
are valid is another question
On Fri, Sep 17, 2010 at 8:44 PM, Chris Male
[
https://issues.apache.org/jira/browse/LUCENE-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911039#action_12911039
]
Robert Muir commented on LUCENE-2652:
-
bq. Yet, you patch changes lots of files
[
https://issues.apache.org/jira/browse/LUCENE-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911040#action_12911040
]
Simon Willnauer commented on LUCENE-2652:
-
{quote}
Right, but long term we should
ThaiAnalyzer assumes things about your jre
--
Key: LUCENE-2653
URL: https://issues.apache.org/jira/browse/LUCENE-2653
Project: Lucene - Java
Issue Type: Bug
Components: contrib/analyzers
[
https://issues.apache.org/jira/browse/LUCENE-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-2653:
Attachment: LUCENE-2653.patch
Here's a patch: it detects statically if the BreakIterator from
I don't think we really care if the tools remain in Lucene - that will
allow some guy that cares about Maven to still make it all happen.
I think we are more saying, lets drop it from part of the official
release process. When we release, we don't worry about Maven as part of
the release process.
On Sat, Sep 18, 2010 at 1:13 PM, Mark Miller markrmil...@gmail.com wrote:
I think we are more saying, lets drop it from part of the official
release process.
To clarify - it never really was part of the official release process,
(just as the referenced wiki pages and much on them never were
[
https://issues.apache.org/jira/browse/LUCENE-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911052#action_12911052
]
Robert Muir commented on LUCENE-2652:
-
bq. I'd commit the fix to trunk and 3.x and
[
https://issues.apache.org/jira/browse/LUCENE-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Willnauer reassigned LUCENE-2652:
---
Assignee: Simon Willnauer
Rethink LocalizedTestCaseRunner with JUnit 4 - Clover
[
https://issues.apache.org/jira/browse/LUCENE-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911058#action_12911058
]
Simon Willnauer commented on LUCENE-2652:
-
I committed the quick fix for now
*
On 9/18/10 1:31 PM, Yonik Seeley wrote:
On Sat, Sep 18, 2010 at 1:13 PM, Mark Miller markrmil...@gmail.com wrote:
I think we are more saying, lets drop it from part of the official
release process.
To clarify - it never really was part of the official release process,
(just as the
Just to be a bit more clear: I'm all for ditching the maven stuff from
the src tree as well, and having everything happen post release. But I
can see how that could be a pain in the ass if we did that quickly. I'm
much more concerned that Maven get out of the release process than the
maven
On Sat, Sep 18, 2010 at 2:49 PM, Mark Miller markrmil...@gmail.com wrote:
Well, you have always claimed that as de jure, I think defacto is that
it's part of the release. And the defacto is to follow the 'release to
do' best as makes sense (I'm not sure the Solr release to do wiki always
[
https://issues.apache.org/jira/browse/SOLR-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir reassigned SOLR-2108:
-
Assignee: Robert Muir
ReversedWildcardFilter can create false positives
[
https://issues.apache.org/jira/browse/SOLR-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911070#action_12911070
]
Robert Muir commented on SOLR-2108:
---
ok, i'd like to commit this to 4.0-only in a few days
I had not been faced with the scrofulous horror of Maven
Nice... Is this phrase copyrighted or can I use it extenuously without
paying royalties (eg, open sourced). :)
In other words, I could not agree more.
On Sat, Sep 18, 2010 at 1:19 AM, Lance Norskog goks...@gmail.com wrote:
+1 on the
On Sat, Sep 18, 2010 at 11:59 AM, Robert Muir rcm...@gmail.com wrote:
On Sat, Sep 18, 2010 at 2:49 PM, Mark Miller markrmil...@gmail.com wrote:
Well, you have always claimed that as de jure, I think defacto is that
it's part of the release. And the defacto is to follow the 'release to
do'
On Sat, Sep 18, 2010 at 3:36 PM, Ryan McKinley ryan...@gmail.com wrote:
As a maven user (not an expert by any means), the maven stuff in
3.x/trunk is actually pretty good. Running:
ant generate-maven-artifacts -Dmaven.dist.dir=maven -Dversion=4.0.rxxx
makes a folder (maven) with everything
On Sat, 18 Sep 2010, Robert Muir wrote:
Just my opinion: (personally i do not use maven, nor understand it).
If maven support is beneficial to bringing more devs to lucene, we should
consider what we can do.
But at the same time, perhaps Makefiles would bring more devs, too.
My problem with
Last time I checked, maven artifacts have to be uploaded by a representative of
the project. I.e. a committer. Farming this out seems like a no-go (for good
reasons). - Steve
From: Robert Muir [mailto:rcm...@gmail.com]
Sent: Saturday, September 18, 2010 3:51 PM
To: dev@lucene.apache.org
On Sat, Sep 18, 2010 at 3:57 PM, Steven A Rowe sar...@syr.edu wrote:
Last time I checked, maven artifacts have to be uploaded by a
representative of the project. I.e. a committer. Farming this out seems
like a no-go (for good reasons). - Steve
Well, (again completely ignorant of maven)
On Sat, Sep 18, 2010 at 3:57 PM, Andi Vajda va...@osafoundation.org wrote:
For example, I recently did an experimental build of Tika for Python using
JCC. Tika's Maven tricks pulled in a very large number - dozens - of
dependencies that had I had to download and build them all by myself
Hi Robert,
I can help a little here. Check out this guide:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
The long and the short of it is that there are several canonical Maven repos
that are sync'ed to Ibiblio and Maven central. Apache has one (through
the maven stuff in 3.x/trunk is actually pretty good
I've heard that about every release of Maven, and any time I've tried
to use it, it doesn't quite work as expected, and given what it does
should be fairly trivial, the fact that there bugs/issues, and it's
been released to me has meant I
On Sat, Sep 18, 2010 at 4:18 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
Hi Robert,
I can help a little here. Check out this guide:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
The long and the short of it is that there are several
On 9/18/2010 at 3:37 PM, Ryan McKinley wrote:
As an aside, I still think it is worth changing our dev builds from
-dev.jar to -SNAPSHOT.jar so that the daily builds are
automatically valid SNAPSHOT builds that are easy for maven/ivy users
to work with. (LUCENE-2493) As is, maven users have
I cannot in good conscience sign with my key, nor vote over any maven
artifacts. I noticed these guides only mentioned how to upload (which itself
seems extremely complex). But nowhere do i see 'how do you test that your
artifacts are correct'. And thats really the main problem I have with our
On Sat, Sep 18, 2010 at 5:09 PM, Ryan McKinley ryan...@gmail.com wrote:
I cannot in good conscience sign with my key, nor vote over any maven
artifacts. I noticed these guides only mentioned how to upload (which
itself
seems extremely complex). But nowhere do i see 'how do you test that
I can see leaving the build support around for those committers that
like and want to support Maven - I'm sure it wouldn't be easy to rip it
out short term. But I still think it should be completely outside of the
RM's cares (as Yonik claims it is now - I'd like to see a bit of
consensus on it
it sounds like it only solves 'part 2: uploading'.
i want to solve 'part 1: verifying artifacts are correct before
signing/uploading at all'.
The artifacts are the identical .jar files put into a special
directory structure. You have already verified they are correct --
this is what I don't
On Sat, Sep 18, 2010 at 2:22 PM, Mark Miller markrmil...@gmail.com wrote:
I can see leaving the build support around for those committers that
like and want to support Maven - I'm sure it wouldn't be easy to rip it
out short term. But I still think it should be completely outside of the
RM's
On Sat, Sep 18, 2010 at 5:29 PM, Ryan McKinley ryan...@gmail.com wrote:
On Sat, Sep 18, 2010 at 2:22 PM, Mark Miller markrmil...@gmail.com
wrote:
I can see leaving the build support around for those committers that
like and want to support Maven - I'm sure it wouldn't be easy to rip it
On Sat, Sep 18, 2010 at 2:32 PM, Robert Muir rcm...@gmail.com wrote:
On Sat, Sep 18, 2010 at 5:29 PM, Ryan McKinley ryan...@gmail.com wrote:
On Sat, Sep 18, 2010 at 2:22 PM, Mark Miller markrmil...@gmail.com
wrote:
I can see leaving the build support around for those committers that
like
On Sat, Sep 18, 2010 at 6:12 PM, Ryan McKinley ryan...@gmail.com wrote:
To automatically test if the maven files work, we would need to run
maven... that seems like a non-starter for many people.
why is this a problem? I don't mind having maven installed and setup if i
can run 'ant
On Sat, Sep 18, 2010 at 3:22 PM, Robert Muir rcm...@gmail.com wrote:
On Sat, Sep 18, 2010 at 6:12 PM, Ryan McKinley ryan...@gmail.com wrote:
To automatically test if the maven files work, we would need to run
maven... that seems like a non-starter for many people.
why is this a problem?
[
https://issues.apache.org/jira/browse/LUCENE-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911128#action_12911128
]
Ryan McKinley commented on LUCENE-2649:
---
I thought of an optimization that could
[
https://issues.apache.org/jira/browse/LUCENE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911144#action_12911144
]
Jason Rutherglen commented on LUCENE-2324:
--
Simon, I think the BytesHash being
I'm a little bit confused about the difference between the Lucene/Solr
3.x branch and Lucene/Solr trunk. Is there a page on the Lucene
Apache site yet for Lucene/Solr 3.x, linked to from the main page?
-
To unsubscribe, e-mail:
[
https://issues.apache.org/jira/browse/LUCENE-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12911157#action_12911157
]
Ryan McKinley commented on LUCENE-2649:
---
Here is the code for ByteValues that:
#
See https://hudson.apache.org/hudson/job/Lucene-trunk/1292/changes
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
54 matches
Mail list logo
