RE: managing CHANGES.txt?

will, modulo free time of course. Feel free to ignore my idiocy. Steve > -Original Message- > From: Mark Miller [mailto:markrmil...@gmail.com] > Sent: Tuesday, June 21, 2011 1:54 PM > To: dev@lucene.apache.org > Subject: Re: managing CHANGES.txt? > > On Jun 21, 2011,

RE: managing CHANGES.txt?

On 6/21/2011 at 1:26 PM, Robert Muir wrote: > On Tue, Jun 21, 2011 at 1:23 PM, Steven A Rowe wrote: > > Is the CHANGES.txt policy you advocate (and police) written up in one > > place?  I'm sure you'd like to not have to fix up everybody's entries > > It

RE: managing CHANGES.txt?

Robert, Is the CHANGES.txt policy you advocate (and police) written up in one place? I'm sure you'd like to not have to fix up everybody's entries Steve > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Tuesday, June 21, 2011 1:14 PM > To: dev@lucene.apache

RE: svn commit: r1137092 - in /lucene/dev/trunk/solr/src: java/org/apache/solr/core/QuerySenderListener.java test-files/solr/conf/solrconfig-querysender-noquery.xml test/org/apache/solr/core/TestQuery

Hi Erick, When you include the JIRA issue ID in your Subversion commit log message, the log message and links to each of your changes are automatically appended to the JIRA issue (you can see these from the "All" tab). But this apparently only happens if you use all caps, e.g. "SOLR-2598". Th

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #155: POMs out of sync

The problem with this failing test under the Maven build is a merged-form-trunk-but-not-adjusted-for-branch_3x property setting tests.luceneMatchVersion=4.0 in the Solr UIMA contrib's POM. I've opened LUCENE-3211 to fix this by making all Solr testing under Maven default to tests.luceneMatchVer

RE: svn commit: r1136543 - /lucene/dev/branches/branch_3x/lucene/CHANGES.txt

Thanks Robert, I was the botcher... TODO: double check CHANGES.txt diff after a merge... - Steve > -Original Message- > From: rm...@apache.org [mailto:rm...@apache.org] > Sent: Thursday, June 16, 2011 12:57 PM > To: comm...@lucene.apache.org > Subject: svn commit: r1136543 - > /lucene/de

RE: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 8840 - Failure

This build failed because of a missing NOTICE file for the maven-ant-tasks jar. I'm adding it now. - Steve > -Original Message- > From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] > Sent: Tuesday, June 14, 2011 5:37 PM > To: dev@lucene.apache.org > Subject: [JENKINS] Lucene-

RE: Welcome Jan Høydahl as Lucene/Solr committer

Welcome! > -Original Message- > From: Mark Miller [mailto:markrmil...@gmail.com] > Sent: Monday, June 13, 2011 10:43 AM > To: dev@lucene.apache.org > Subject: Welcome Jan Høydahl as Lucene/Solr committer > > I'm happy to announce that the Lucene/Solr PMC has voted in Jan Høydahl > as our

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #150: POMs out of sync

ing https protocol in LWP > > I also improved the script/build.xml to show errors. > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > -Original Message- > > From: Steven A Rowe [mai

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #150: POMs out of sync

t; eMail: u...@thetaphi.de > > > > -Original Message- > > From: Steven A Rowe [mailto:sar...@syr.edu] > > Sent: Sunday, June 12, 2011 6:58 PM > > To: dev@lucene.apache.org > > Subject: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #150: POMs out of > >

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #150: POMs out of sync

t; > -Original Message- > > From: Steven A Rowe [mailto:sar...@syr.edu] > > Sent: Sunday, June 12, 2011 6:37 PM > > To: dev@lucene.apache.org > > Subject: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #150: POMs out of > > sync > > > > Thanks for fi

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #150: POMs out of sync

Thanks for fixing this one too, Uwe. I should get shell access on the lucene Jenkins slave so I can do this kind of investigation myself - I was doing remote tweaks (for what I assumed was the missing JSON module) without access to the real problem. I'm really surprised that LWP::Simple is not

RE: Is docs for PatternReplaceFilterFactory missing on wiki...?

Hi Eric, If you want to add it, you should. Steve > -Original Message- > From: Eric Pugh [mailto:ep...@opensourceconnections.com] > Sent: Tuesday, June 07, 2011 12:21 PM > To: dev@lucene.apache.org > Subject: Is docs for PatternReplaceFilterFactory missing on wiki...? > > Seems like the

RE: svn commit: r1130547 - /lucene/dev/trunk/modules/analysis/icu/build.xml

Thanks Ryan - I missed this :) - I only ran "mvn install" and not "ant generate-maven-artifacts" before committing the grandparent POM change... > -Original Message- > From: r...@apache.org [mailto:r...@apache.org] > Sent: Thursday, June 02, 2011 9:43 AM > To: comm...@lucene.apache.org >

RE: Welcome Erick Erickson as Lucene/Solr committer

Welcome, Erick! > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Wednesday, June 01, 2011 4:08 PM > To: dev@lucene.apache.org > Subject: Welcome Erick Erickson as Lucene/Solr committer > > I'm pleased to announce that the Lucene PMC has voted for Erick > Erickson

RE: Welcome Martijn van Groningen as Lucene/Solr committer

Welcome! > -Original Message- > From: Michael McCandless [mailto:luc...@mikemccandless.com] > Sent: Wednesday, June 01, 2011 3:02 PM > To: dev@lucene.apache.org Dev > Subject: Welcome Martijn van Groningen as Lucene/Solr committer > > The Lucene PMC has voted to add Martijn van Groningen

RE: JIRA karma

Thanks! > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Tuesday, May 31, 2011 2:47 AM > To: dev@lucene.apache.org > Subject: Re: JIRA karma > > On Tue, May 31, 2011 at 2:44 AM, Steven A Rowe wrote: > > I want to add all pre-1.9 L

JIRA karma

I want to add all pre-1.9 Lucene releases to this page: https://issues.apache.org/jira/browse/LUCENE#selectedTab=com.atlassian.jira.plugin.system.project:versions-panel&subset=-1 but I don't see any UI elements to add versions. I assume this is because I don't have JIRA admin permissions. Can s

RE: [VOTE] Lucene/Solr release 3.2 (take 2)

Holy crap, Robert, you cranked through a huge number of issues to put this out. Kudos! I'll take a look at RC2 in the next couple of days. Steve > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Monday, May 30, 2011 11:54 PM > To: dev@lucene.apache.org > Subjec

RE: [VOTE] Release Lucene/Solr 3.2.0

, 2011 6:58 PM > To: dev@lucene.apache.org > Subject: Re: [VOTE] Release Lucene/Solr 3.2.0 > > On Mon, May 30, 2011 at 4:06 PM, Steven A Rowe wrote: > > 2. All contrib/*/CHANGES.txt have "3.2-dev" as the release header.  -1 > to RC1 based on this. > > > >

RE: [VOTE] Release Lucene/Solr 3.2.0

try to fix in 3.3 +1 On 5/30/2011 at 4:16 PM, Robert Muir wrote: > On Mon, May 30, 2011 at 4:06 PM, Steven A Rowe wrote: > > 3. Contrib Javadocs include links to removed contribs ant, > > db, lucli, and swing. -1 to RC1 based on this. > > While I agree with most of the othe

RE: [VOTE] Release Lucene/Solr 3.2.0

First, I want to say that I think being able to release more frequently is great. Thanks Mike for taking the initiative. But we need to be able to fix packaging problems, and the only time we look at them is at release time. So I'm -1 to the idea of ignoring problems because we don't want to

RE: do the Jenkins while(true) builds now catch javadoc warnings...?

I checked what it would take to test all of the javadocs on trunk, and found that there is no one target to call. To cover all javadocs: cd lucene ; ant javadocs-all javadocs-test-framework cd ../modules ; ant javadocs cd ../solr ; ant javadoc-all javadoc-test-framework

RE: Welcome Chris Male & Andi Vajda as full Solr / Lucene Committers

Welcome! > -Original Message- > From: Simon Willnauer [mailto:simon.willna...@googlemail.com] > Sent: Monday, May 23, 2011 12:40 PM > To: dev@lucene.apache.org; gene...@lucene.apache.org > Subject: Welcome Chris Male & Andi Vajda as full Solr / Lucene Committers > > Hi folks, > > I am ha

RE: Branch 3.x build failure w/1.5: solr/contrib/clustering/ [was: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #128: POMs out of sync]

On 5/20/2011 at 2:58 PM, Stanislaw Osinski wrote: > > The jar checked into SVN, both on trunk and on branch_3x, > > is solr/contrib/clustering/lib/simple-xml-2.3.5.jar, which > > means that the Ant build is using this older version on > > both branches - shouldn't this also be upgraded to 2.4.1? >

RE: Branch 3.x build failure w/1.5: solr/contrib/clustering/ [was: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #128: POMs out of sync]

Hi Staszek, On 5/20/2011 at 9:51 AM, Stanislaw Osinski wrote: > My fault, please go ahead and add it back (a newer version is > required though): > > > org.simpleframework > simple-xml > 2.4.1 > The jar checked into SVN, both on trunk and on branch_3x, is solr/contrib/cluster

RE: Branch 3.x build failure w/1.5: solr/contrib/clustering/ [was: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #128: POMs out of sync]

> -Original Message- > From: Steven A Rowe [mailto:sar...@syr.edu] > Sent: Friday, May 20, 2011 8:55 AM > To: dev@lucene.apache.org > Subject: RE: Branch 3.x build failure w/1.5: solr/contrib/clustering/ > [was: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #128: POMs out of sync] >

RE: Branch 3.x build failure w/1.5: solr/contrib/clustering/ [was: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #128: POMs out of sync]

This looks like a Maven-only problem, since compilation under Ant succeeds. - Steve > -Original Message- > From: Steven A Rowe [mailto:sar...@syr.edu] > Sent: Friday, May 20, 2011 8:51 AM > To: dev@lucene.apache.org > Subject: Branch 3.x build failure w/1.5: solr/contrib/c

Branch 3.x build failure w/1.5: solr/contrib/clustering/ [was: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #128: POMs out of sync]

On 5/20/2011 at 7:58 AM, Apache Jenkins Server wrote: > Build: https://builds.apache.org/hudson/job/Lucene-Solr-Maven-3.x/128/ There is some kind of problem with compiling the Solr clustering contrib under Java 1.5: [INFO] Compiling 10 source files to /usr/home/hudson/hudson-slave/workspace/Luc

RE: Javadoc warnings failing the branch_3x build [was: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #126: POMs out of sync]

ngs > (but the build clearly does)... > > Mike > > http://blog.mikemccandless.com > > On Wed, May 18, 2011 at 8:22 AM, Steven A Rowe wrote: > > This build failed because of Javadoc warnings: > > > >  [javadoc] Constructing Javadoc information... > >  [java

Javadoc warnings failing the branch_3x build [was: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #126: POMs out of sync]

This build failed because of Javadoc warnings: [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.5.0_16-p9 [javadoc] Building tree for all the packages and classes... [javadoc] .../org/apache/lucene/search/grouping/AllGroupsCollector.java:45: warning - Tag

RE: Lucene/Solr JIRA

On 5/17/2011 at 3:02 PM, Chris Hostetter wrote: > If we were starting from scratch, i'd agree with you that having a single > Jira project makes more sense, but given where we are today, i think we > should probably keep them distinct -- partly from a "pain of migration" > standpoint on our end, bu

RE: svn commit: r1103709 - in /lucene/java/site: docs/whoweare.html docs/whoweare.pdf src/documentation/content/xdocs/whoweare.xml

Hi Stanisław, You don’t need to be logged into people.apache.org to update the website. Have you seen these instructions? The “unversioned website” section is what you want, I think: http://wiki.apache.org/lucene-java/HowToUpdateTheWebsite Steve From: stac...@gmail.com [mailto:stac...@gmail.

RE: Improvements to the maven build

Hi David, On 5/6/2011 at 9:46 AM, David W. Smiley wrote: > On May 4, 2011, at 6:43 PM, Steven A Rowe wrote: > > I meant to keep the Maven build output location the same as the Ant > > build output location. I think the Solr modules' POMs can and should > > be changed to

RE: Improvements to the maven build

Hi Ryan, On 5/4/2011 at 7:14 PM, Ryan McKinley wrote: > As a rule, everything should go through JIRA on its way to svn -- this > is important so that we have somewhere to point for why we did things. > Even small things. Your phrase "As a rule" provides wiggle room that we all use. "Even small

RE: Improvements to the maven build

A correction: I wrote: > The full artifact name would be org.apache.solr:apache-solr:, > which seems weird to me in the double inclusion of "maven". s/"maven"/"apache"/

RE: Improvements to the maven build

Hi Ryan, > Do you want to make a JIRA issue with a patch? > > This is a good example of a patch that is easy to get committed > quickly because it is simple, clear, and understandable. Earlier today on #lucene IRC, David described the changes he had in mind, and asked me where to put the patch,

RE: Improvements to the maven build

Hi David, > I thought I'd put together a list of interesting differences between the > ant build output and the maven build output. Before each build I did a > full clean and then after the build I saved a file listing to a text file > so that I could diff it. Cool! Thanks for the effort. > 1.

RE: modularization discussion

On 4/27/2011 at 9:25 AM, Yonik wrote: > it seems only fair to meet half way and use the solr namespace > for some modules and the lucene namespace for others. Let's eliminate a source of conflict, and make modules another product that is neither Lucene nor Solr. Steve

RE: modularization discussion

> if its not stated as "this feature is going to Lucene" It seems as though some people assume that since Lucene is a library, and Solr is an application, that exposing Solr API *means* making it part of Lucene. It ain't necessarily so, and it need not be a point of contention. I want to reite

RE: probable sore topic... Maven build?

Hi Paul, As Grant mentioned, there is a full complement of Maven POMs stored under the top-level dev-tools/ directory. You can populate the source tree with POMs by running 'ant get-maven-poms' from the top level. Before the Maven build will function fully, run 'mvn -N -P bootstrap install' a

RE: Robert Muir thinks we should stop supporting Sun/Oracle JDK 1.5 on branch_3x

his before but we need to make sure everyone understands this is not mandatory. I code to the spec On Apr 15, 2011 9:55 AM, "Steven A Rowe" mailto:sar...@syr.edu>> wrote: > Turns out that the problem is that ReusableAnalyzerBase is not in the same > package in branch_3x as

RE: Robert Muir thinks we should stop supporting Sun/Oracle JDK 1.5 on branch_3x

fixing it. It appears that it is a Javadoc bug??? Why would we > keep good code out for that? > > -- DM > > On 04/15/2011 09:15 AM, Steven A Rowe wrote: > > As a result of Robert Muir's r1092398 commit on branch_3x (the Latvian > analysis stuff), the build is n

Robert Muir thinks we should stop supporting Sun/Oracle JDK 1.5 on branch_3x

As a result of Robert Muir's r1092398 commit on branch_3x (the Latvian analysis stuff), the build is now broken under Sun/Oracle JDK 1.5: [javadoc] C:\svn\lucene\dev\branches\branch_3x\lucene\contrib\analyzers\common\src\java\org\apache\lucene\analysis\lv\LatvianAnalyzer.java:118: warning - T

RE: Non ASF compatible license when using lucene/solr with an IDE?

Hi Patrick, FYI, the “idea” and the “get-maven-poms” targets do the same thing; when I set these up, I wanted to enable compilation of the full code base. If you want something different, please submit patches to set it up. Steve From: patrick o'leary [mailto:pj...@pjaol.com] Sent: Saturday, A

RE: [HUDSON] Lucene-trunk - Build # 1523 - Failure

AFAICT, these (Oracle/Sun-only) JVM parameters were introduced in 1.6 (that's what this parameters list says: http://blogs.sun.com/watt/resource/jvm-options-list.html) - we tell Jenkins to use 1.6 for Lucene/Solr testing, so this isn't an issue in practice, I guess. Hopefully 1.5 JVMs, and non-

RE: character escapes in source? ... was: Re: Eclipse: Invalid character constant

+1 I took an all-of-the-above approach, including the Unicode character description, for the ASCIIFoldingFilter-based stuff. E.g. from the mapping file : # Ä [LATIN CAPITAL LETTER

RE: Google Summer Code 2011 participation

Hi Jayendra, From : In order to participate in the program, you must be a student. Google defines a student as an individual enrolled in or accepted into an accredited institution including (but not necessarily

RE: svn commit: r1087649 - /lucene/dev/trunk/solr/src/test/org/apache/solr/spelling/suggest/SuggesterTest.java

Maven build fix committed to trunk: r1088065. > -Original Message- > From: Steven A Rowe [mailto:sar...@syr.edu] > Sent: Saturday, April 02, 2011 11:04 AM > To: dev@lucene.apache.org > Subject: RE: svn commit: r1087649 - > /lucene/dev/trunk/solr/src/test/org/apache/sol

RE: svn commit: r1087649 - /lucene/dev/trunk/solr/src/test/org/apache/solr/spelling/suggest/SuggesterTest.java

FYI, this commit introduced a new Solr Core test dependency on Google Collections (solr/lib/guava-r05.jar). Previously, AFAICT, only the Clustering contrib had this dependency. I noticed because the Maven trunk build failed. I'm working on addressing this now. Steve > -Original Message-

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #76: POMs out of sync

This build failed because of javadocs warnings under modules/. I committed fixes under LUCENE-3006. I guess the nightly Ant Lucene trunk build doesn't build modules/ javadocs? Steve > -Original Message- > From: Apache Hudson Server [mailto:hud...@hudson.apache.org] > Sent: Friday, Apri

RE: Questions about 3.1.0 release, SVN and common-build.xml

released ones. > > > > This was the same for all releases before (at least since 2.9.0 where we > had the discussion, too). > > > > Uwe > > > > - > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > >

RE: Questions about 3.1.0 release, SVN and common-build.xml

Hi Shai, On 4/1/2011 at 8:32 AM, Shai Erera wrote: > Also, the common-build.xml under the tag and the downloaded sources > specifies version to be 3.1-SNAPSHOT. On the ReleaseTodo I found > this: "... and the default version in lucene/common-build.xml on > the branch to X.Y (remove the -SNAPSHOT s

RE: [VOTE] Release Lucene/Solr 3.1

I found a few documentation issues in the binary Lucene .zip (these are not blockers, IMHO): Lucene binary .zip -- A. README.txt: 1. "contrib/demo/lucene-demos-XX.jar" ("demos" should be "demo") 2. "See BUILD.txt for building a source distribution" (there is no

RE: svn commit: r1084324 - in /lucene/dev/branches/branch_3x: lucene/build.xml solr/build.xml solr/common-build.xml

I agree – I’ve added it. - Steve From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Tuesday, March 22, 2011 3:54 PM To: dev@lucene.apache.org Subject: Re: svn commit: r1084324 - in /lucene/dev/branches/branch_3x: lucene/build.xml solr/build.xml solr/common-build.xml Thanks, we should add this r

RE: Lucene Solr 3.1 RC1

On 3/18/2011 at 7:37 AM, Robert Muir wrote: > I don't like that the lucene build from the source release is broken. https://issues.apache.org/jira/browse/LUCENE-2973 fixes it by including dev-tools (and everything else except solr/) > we can't let the official build depend on dev-tools. Why not

RE: [HUDSON] Lucene-Solr-tests-only-3.x - Build # 5964 - Failure

The build never made it past the initial pre-build "ant clean": --- clean: [delete] Deleting directory /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/

RE: Problem of Replication Reservation Duration

Hi Li Li, Please do not use the solr-dev mailing list - Solr and Lucene development both use the list. Steve > -Original Message- > From: Li Li [mailto:fancye...@gmail.com] > Sent: Friday, March 11, 2011 8:41 AM > To: solr-...@lucene.apache.org > Subject: Problem of Replication Reserva

RE: Building on windows

Hi Erick, I regularly build on Windows, and I've never encountered this problem. My environment: I'm on Windows 7 64-bit, using Oracle Java 1.6.0_23 64-bit and Ant 1.7.1. My Ant installation directory doesn't have any jasper libs in it ("find . -name '*ja?sp*.jar'" under cygwin bash shell retu

RE: [VOTE] Lucene and Solr 3.1 release candidate

Hi Grant, On 3/9/2001 at 6:38 AM Grant Ingersoll wrote: > > 2011/3/8 Steven A Rowe : > >> Solr (and some Lucene modules) have several non-Mavenized dependencies. > > In the past, we have usually published these along with Solr, by changing > the names to be something lik

RE: [VOTE] Lucene and Solr 3.1 release candidate

Hi Sanne, Solr (and some Lucene modules) have several non-Mavenized dependencies. To work around this, the Maven build has a profile called "bootstrap". If you check out the source (or use the source distribution) you can place all non-Mavenized dependencies in your local repository as follows

RE: [HUDSON] Lucene-Solr-tests-only-trunk - Build # 5709 - Failure

Mike, I can repro, but not consistently. In a while[1] script, after 12 iterations (I compiled with Java 5, then ran tests with Java 6, as on Jenkins): junit-sequential: [junit] RESOURCE LEAK: test method: 'testIndexingThenDeleting' left 1 thread(s) running [junit] NOTE: test params ar

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #48: POMs out of sync

Thanks Uwe! > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Monday, March 07, 2011 9:54 AM > To: dev@lucene.apache.org > Subject: RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #48: POMs out of sync > > Problem solved, Jenkins was still using 3.1 instead of 3.2. >

RE: [HUDSON] Solr-3.x - Build # 279 - Failure

Both branch_3x and trunk nightly jobs failed because the javadocs weren't produced: -- mv: rename build/docs/api/* to /home/hudson/hudson-slave/workspace/Solr-3.x/javadocs/*: No such file or directory -- > -Original Message- > From: Apache Hudson Server [mailto:

RE: [JENKINS-MAVEN] Lucene-Solr-Maven-3.x #46: POMs out of sync

I haven't tracked it down yet, but it appears that at least one Solr contrib's source archive is not being built - this is true both for branch_3x and trunk: --- BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-3.x/checkout/solr/build.xml:982: The following error oc

RE: [HUDSON] Lucene-Solr-tests-only-3.x - Build # 5498 - Failure

Ant 'clean' target failed to delete a build directory. This seems new, and coincides with Jenkins replacing Hudson. From the build console output: -- clean: [delete] Deleting directory /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-3.x/checkout/lucene/build BUILD FA

RE: [HUDSON-MAVEN] Lucene-Solr-Maven-trunk #41: POMs out of sync

This build failed because the Solr Clustering contrib timed out transferring two v3.0.1 Lucene artifacts dependencies from the Maven central repository, e.g.: Downloading: http://repo1.maven.org/maven2/org/apache/lucene/lucene-snowball /3.0.1/lucene-snowball-3.0.1.jar

RE: Converting an existing index format to Lucene Index

If you sort your old index file by filename, then iterate over the sorted file, your problem is solved, no? From: Lokendra Singh [mailto:lsingh@gmail.com] Sent: Friday, February 25, 2011 1:27 AM To: java-u...@lucene.apache.org Cc: dev@lucene.apache.org Subject: Converting an existing index fo

Solr-dev mailing list on Nabble

As I mentioned on the solr-dev mailing list , David Smiley's responses to emails on dev@l.a.o have been going to solr-dev@l.a.o. This is a problem, and it's not restricted to David's emails. David Smiley's response to

RE: wind down for 3.1?

David, you have been using solr-dev@l.a.o lately - would you please switch to dev@l.a.o? solr-dev was deprecated when Solr merged with Lucene. It gets quite confusing to try to follow discussions you participate on, when they are across multiple mailing lists. When people reply to your solr-d

RE: Welcome Dawid Weiss and Stanislaw Osinski as Lucene/Solr committers

Welcome Stanisław and Dawid! > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Tuesday, February 08, 2011 1:13 PM > To: gene...@lucene.apache.org; dev@lucene.apache.org > Subject: Welcome Dawid Weiss and Stanislaw Osinski as Lucene/Solr > committers > > I'm please

RE: Should ASCIIFoldingFilter be deprecated?

AFAIK, ISOLatin1AccentFilter was deprecated because ASCIIFoldingFilter provides a superset of it mappings. I haven't done any benchmarking, but I'm pretty sure that ASCIIFoldingFilter can achieve a significantly higher throughput rate than MappingCharFilter, and given that, it probably makes se

RE: Tokenization and Fuzziness: How to Allow Multiple Strategies?

Hi Tavi, solr-...@lucene.apache.org has been deprecated since the Lucene and Solr source trees merged last year. Please use dev@lucene.apache.org instead. However, your question is about *usage* of Lucene/Solr, rather than *development*, so you should be using solr-u...@lucene.apache.org or l

Nightly Lucene and Solr Maven snapshot artifacts

I have switched generation and publication of Lucene and Solr snapshot artifacts to two new nightly Hudson jobs: Lucene-Solr-Maven-3.x and Lucene-Solr-Maven-trunk. Latest Lucene and Solr 3.x snapshots: https://hudson.apache.org/hudson/job/Lucene-Solr-Maven-3.x/lastSuccessfulBuild/artifact/maven

RE: svn commit: r1064010 - in /lucene/dev/nightly: hudson-lucene-solr-maven-3.x.sh hudson-lucene-solr-maven-trunk.sh

Agreed, I'll get rid of the "strange" copying after the other build scripts are changed to not delete the repo. I want to wait until these Maven builds are stable though. I agree the maven env vars should be centralized. Current problem though is failing Groovy code in the grandparent pom that

RE: Nightly Hudson Maven builds

Maven builds > > Maybe you looked at one of the half-hourly builds? They don't build > artifacts, only test. > > Uwe > > > > "Steven A Rowe" schrieb: > > >On 1/27/2011 at 3:58 PM, Uwe Schindler wrote: > >> > [...] output from runni

RE: Nightly Hudson Maven builds

On 1/27/2011 at 3:58 PM, Uwe Schindler wrote: > > [...] output from running "ant generate-maven-artifacts" doesn't end up in > > the console output for the Hudson jobs. It succeeds or fails silently. > > This is cool if you find yourself in the die-maven-die camp, but not so cool > > otherwise. >

Nightly Hudson Maven builds

Robert Muir changed the Hudson scripts for the four builds that run "ant generate-maven-artifacts" (Lucene-3x, Solr-3x, Lucene-trunk, and Solr-trunk) so that the builds would not fail as a result of problems running "ant generate-maven-artifacts". This is a good thing. A secondary effect of hi

RE: Problems with Solr UIMA contrib maven dependencies [was: RE: Solr-3.x - Build # 238 - Failure]

On 1/24/2011 at 12:26 PM, Tommaso Teofili wrote: > those artifacts in snapshot repo are a bit old. > At UIMA we're about to release 2.3.1 version of the Addons package (which > includes > AlchemyAPIAnnotator, OpenCalaisAnnotator, WhitespaceTokenizer and Tagger) > hopefully > in a couple of weeks

Problems with Solr UIMA contrib maven dependencies [was: RE: Solr-3.x - Build # 238 - Failure]

directly using the jars under solr/contrib/uima/lib/, installing them to the user’s local repo via the “bootstrap” profile in the top-level POM. Steve From: Steven A Rowe [mailto:sar...@syr.edu] Sent: Monday, January 24, 2011 9:38 AM To: dev@lucene.apache.org Subject: RE: Solr-3.x - Build # 238

RE: Solr-3.x - Build # 238 - Failure

Thanks, Tommaso. - Steve From: Tommaso Teofili [mailto:tommaso.teof...@gmail.com] Sent: Monday, January 24, 2011 9:25 AM To: dev@lucene.apache.org Subject: Re: Solr-3.x - Build # 238 - Failure Hi Steve, please let me know if I can help you any way. Cheers, Tommaso 2011/1/24 Steven A Rowe

RE: Solr-3.x - Build # 238 - Failure

I'm working on it now. - Steve > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Monday, January 24, 2011 2:59 AM > To: dev@lucene.apache.org > Subject: RE: Solr-3.x - Build # 238 - Failure > > Ah, seems to be related to Roberts commit of the new UIMA module: Th

Hudson nightly build failures due to Clover

Clover causes Hudson nightly builds to fail intermittently. This is bad, because it looks like Lucene/Solr tests are failing when they are not. But Clover is good, so nobody wants to turn it off. One possible solution (apologies if this has already been suggested): make new nightly Clover-onl

RE: Lucene-Solr-tests-only-trunk - Build # 3990 - Failure

This failure is strange - I was watching the console output, and (contrary to the email's assertion that "No tests ran") the build appeared to be stuck somewhere in the middle of the JUnit tests. Steve > -Original Message- > From: Apache Hudson Server [mailto:hud...@hudson.apache.org] >

RE: svn commit: r1060843 - /lucene/dev/branches/branch_3x/dev-tools/eclipse/dot.classpath

Sorry about the improper naming - my fault. Thanks for fixing, Shai. - Steve > -Original Message- > From: sh...@apache.org [mailto:sh...@apache.org] > Sent: Wednesday, January 19, 2011 11:01 AM > To: comm...@lucene.apache.org > Subject: svn commit: r1060843 - /lucene/dev/branches/branch_3

RE: Let's drop Maven Artifacts !

On 1/18/2011 at 1:45 PM, Mark Miller wrote: > At some point, Grant or someone put in some Maven poms. I don't think > anyone else really paid attention. Later, as we did releases, and saw and > dealt with these poms, most of us commented against Maven support. It just > feels to me like it slipped

RE: Let's drop Maven Artifacts !

On 1/18/2011 at 12:14 PM, Robert Muir wrote: > On Tue, Jan 18, 2011 at 12:03 PM, Steven A Rowe wrote: > > > > There clearly is no consensus for removing Maven support from Lucene. > > and see there is my problem, there was no consensus to begin with, now > suddenly its &q

RE: Let's drop Maven Artifacts !

On 1/18/2011 at 11:34 AM, Robert Muir wrote: > On Tue, Jan 18, 2011 at 11:27 AM, Mark Miller > wrote: > > I'll open my arms to first class maven the first time it sees the light > > of consensus ;) > > thats the main thing missing from releasing maven artifacts... looking > at previous threads I

RE: Let's drop Maven Artifacts !

On 1/17/2011 at 3:05 PM, Michael Busch wrote: > On 1/17/11 8:06 AM, Steven A Rowe wrote: > > On 1/17/2011 at 1:53 AM, Michael Busch wrote: > >> I don't think any user needs the ability to run an ant target on > >> Lucene's sources to produce maven ar

RE: Let's drop Maven Artifacts !

On 1/17/2011 at 11:25 AM, Robert Muir wrote: > On Mon, Jan 17, 2011 at 11:06 AM, Steven A Rowe wrote: > > On 1/17/2011 at 1:53 AM, Michael Busch wrote: > >> I don't think any user needs the ability to run an ant target on > >> Lucene's sources to produce mave

RE: Let's drop Maven Artifacts !

On 1/17/2011 at 1:53 AM, Michael Busch wrote: > I don't think any user needs the ability to run an ant target on > Lucene's sources to produce maven artifacts I want to be able to make modifications to the Lucene source, install Maven snapshot artifacts in my local repository, then depend on thos

Re: Let's drop Maven Artifacts !

-1 from me on dropping Maven artifacts. I find it curious that on the verge of fixing the broken Maven artifacts situation (LUCENE-2657), there is a big push for a divorce. Robert, I agree we should have a way to test the "magic" artifacts. I'm working on it. Your other objection is the work

RE: top-level README or similar?

> > -0 on the setup-ide-* standardization - I like the shorter form. If > > there were 19 different supported IDEs, I would agree. But with just > > two, what's the gain? > > i wasn't trying to argue for any gain -- just standaridization. i wasn't > overly worried baout what hte standardization

RE: top-level README or similar?

> > Perhaps we should add a very basic README.txt to get people started? > > I noticed other projects seem to have something like this. [...] > > To setup your ide run 'ant copy-idea-files' (for Intellij) or 'ant > > eclipse' (for eclipse) Actually, 'ant idea' is preferable, since the 'idea' targe

RE: Changes Mess

On 12/7/2010 at 3:03 PM, Michael McCandless wrote: > Could we do something hybrid? Since we have no full control over > Jira, could we eg append a comment on the the Jira issue starting with > "CHANGES: ", if it needs a changes entry (many issues do not)? Can't we add a field? I see we already h

RE: Changes Mess

Chris, > > Yet another way would be to declare the problem non-existent and screw > > our users by insulting them with a honking great mass of changes without > > any indication about what they are or how they are inter-related. (You > > won't be surprised at this point, I think, by my -1 to this

RE: Changes Mess

Hi Chris, On 12/5/2010 at 10:36 PM, Chris Mattman wrote: > Yep, like you state below JIRA *could* be configured to deal with this. > > In all honesty, putting tons of thought and effort into how to precisely > deal with the changes you specify below might be somewhat overkill. I think dumping CH

RE: Changes Mess

On 12/5/2010 at 12:19 PM, Robert Muir wrote: > On Sun, Dec 5, 2010 at 12:08 PM, Mattmann, Chris A (388J) > wrote: > > Hi Mark, > > > > RE: the credit system. JIRA provides a contribution report here, like > > this one that I generated for Lucene 3.1: > > > > My concern with this is that it leaves

RE: svn commit: r1001318 - in /lucene/dev/trunk/solr: CHANGES.txt src/java/org/apache/solr/search/FunctionQParser.java src/test/org/apache/solr/search/QueryParsingTest.java src/test/org/apache/solr/se

On 12/2/2010 at 1:34 PM, Yonik Seeley wrote: > the window you see isn't necessarily the window that has the focus :-( A graph of the number of times I've made this mistake over time would look a lot like a flat line. The fact that this is such an easy mistake to make at this point in UI evolut

'ant generate-maven-artifacts' oddities

In getting 'ant generate-maven-artifacts' to work for me (LUCENE-2774), I noticed two oddities: 1. On both trunk and branch_3x, Solr's maven artifacts are named without the embedded timestamp that everybody else (Lucene core/contrib/modules) gets, e.g.: dist/maven/org/apache/solr/solr-solrj/3

<    1   2   3   4   5   >