Re: [VOTE] Lucene and Solr 3.1 release candidate
2011/3/14 slaava : > Hi, > when could we expect "final" 3.1 version with maven-repository? We need some > functionality included in 3.1 and I don't know if I have to wait or create > own maven project from sources... Hi, I hope soon as well, in the meantime we've been testing with the release candidate "repositories": lucene-staging-rmuir lucene-staging-repository-rmuir Lucene testing repo http://people.apache.org/~rmuir/staging_area/lucene-solr-3.1RC0-rev1078688/lucene-3.1RC0/maven/ default true never false never solr-staging-repository-rmuir Solr testing repo http://people.apache.org/~rmuir/staging_area/lucene-solr-3.1RC0-rev1078688/solr-3.1RC0/maven default true never false never Use it with care, as they are marked with the same identifiers the final will have, so you might end up polluting your local caches with this: make sure you delete all copies when the real one is released. -- Sanne > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/VOTE-Lucene-and-Solr-3-1-release-candidate-tp2645100p2675660.html > Sent from the Solr - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Lucene and Solr 3.1 release candidate
Hi, when could we expect "final" 3.1 version with maven-repository? We need some functionality included in 3.1 and I don't know if I have to wait or create own maven project from sources... -- View this message in context: http://lucene.472066.n3.nabble.com/VOTE-Lucene-and-Solr-3-1-release-candidate-tp2645100p2675660.html Sent from the Solr - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
OK, things are looking good. I fixed many of the issues that Hoss pointed out (well, the ones I agreed with at least). The only remaining 3.1 issue is https://issues.apache.org/jira/browse/LUCENE-2960 Hopefully that can be done quickly and then we can cut another release candidate (I'll volunteer). If there is anything you want to fix, then fix it now *before* the next release candidate comes out. The only thing stopping the next RC should be real blockers, not minor doc issues or anything. To create the current packages yourself, checkout https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1 For solr, run "ant package" For lucene, run "ant dist" -Yonik http://lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
I'm trying to fix the solr javadoc targets. I just noticed that it looks like we have a double-copy of the solr javadoc too - I'll try and fix that while I'm in there. Overall I think things are looking pretty good - if anyone wants to review/fix things, please run "ant package" and check the resulting output. Many of the items Hoss mentioned had already been fixed. -Yonik http://lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Fri, Mar 11, 2011 at 8:14 AM, Yonik Seeley wrote: > On Thu, Mar 10, 2011 at 6:49 PM, Chris Hostetter > wrote: >> The number of "lucene" jars included in the release is also odd -- they >> are embedded in the solr.war obviously, but not included anywhere else. >> so people wanting to do something like use apache-solr-core-3.1.0.jar to >> embed solr in their app still need to get the lucene jars from a distinct >> release ... except that there does seem to be 3 lucene jars included in >> ./contrib/analysis-extras/lucene-libs (i suspect this was a mistake in an >> intentional exclusion of those jars) > > I was just going for including jars needed to run (and the lucene jars > are in the war, but the ones from analysis-extras are not). > Thinking about it again... we should either leave out "lib" (which > should also be in the war) or include lucene_lib. Oops, my mistake... I already did exclude "lib" as well. -Yonik http://lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Thu, Mar 10, 2011 at 6:49 PM, Chris Hostetter wrote: > The number of "lucene" jars included in the release is also odd -- they > are embedded in the solr.war obviously, but not included anywhere else. > so people wanting to do something like use apache-solr-core-3.1.0.jar to > embed solr in their app still need to get the lucene jars from a distinct > release ... except that there does seem to be 3 lucene jars included in > ./contrib/analysis-extras/lucene-libs (i suspect this was a mistake in an > intentional exclusion of those jars) I was just going for including jars needed to run (and the lucene jars are in the war, but the ones from analysis-extras are not). Thinking about it again... we should either leave out "lib" (which should also be in the war) or include lucene_lib. Doing the latter should make it possible to compile plugins against a binary release w/o exploding the war... but I don't know how important that is. -Yonik http://lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Mar 10, 2011, at 9:18 PM, Chris Hostetter wrote: > i'm just wondering if we really need both lucene-src and > solr-src artifacts. particularly considering that solr-src is already a > superset of lucene-src ... it just seems like one uber lucene-solr-src > package of the "dev" tree would be the simplest most straight forward > thing to ship for people who want source. At this point, I'm only using Lucene. Never looked at Solr. In the Eclipse dev environment, I bring in the jars for Lucene that we use and attach source to it. Not sure I want everything. In a way I wish there was a src for each jar. That said, I'll take it any way I can get it. And re-package it if I need to. -- DM - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Thu, Mar 10, 2011 at 9:03 PM, Chris Hostetter wrote: > The way it gets into the solr docs is via a property file generated by the > build (see the init-forrest-entities, it's setup as a dependency for just > about everything) that forrest then reads. the old release process docs > were specific that the forrest docs needed to be rebuilt *after* running > ant with the specversion set... > >> http://wiki.apache.org/solr/HowToReleaseSlowly >> No, it looks like you are still confused. i ran init-forrest-entities followed by the forrest regeneration, committed (http://svn.apache.org/viewvc?view=revision&revision=1078685) If i had not done this, then that date would not have said march 6, 2011. So, i did everything correctly here. If you are upset that the specversion variable says, 3.0 (and not say 3.1 or whatever else), that's not the RM's problem. And for the record, this versioning/website update is nothing like lucene. in lucene, these versions etc kept up to date (for example, branch-3x says 3.2 right now). In solr, it seems that things such as these versions are just left for the release manager to deal with? And the release manager is supposed to do things like test tomcat, jetty, and resin? In solr, the website itself in branch_3x was completely out of sync from trunk (someone was just too lazy to backport?), which is why you see "extra" announcements in my commit referenced above, because i had to sync it up. Finally, the absolute most frustrating thing at all was that the legal stuff was completely fucked, including invalid copyright notices that people just committed, i guess these things were committed out of laziness, realizing someone (probably the RM?) will have to fix all this stuff before release. I probably will never do another RC candidate again, due to my complete frustration with what I believe is a fundamentally broken process (no wonder releases are so infrequent), but one good thing did come out of my 20 hours of complete wasted time: I realized that when it comes to third party dependencies and licensing, this stuff has to be taken more seriously. There is no "policeman" for this right now unfortunately, but you can bet I'm gonna start watching commits on this stuff a lot more carefully in the future. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
: - I'm definitely for separate source and binary releases - makes so : much more sense post merge. : solr's "src" is particularly great now... one can modify any part : (lucene, modules, etc) and easily rebuild. agreed .. i'm just wondering if we really need both lucene-src and solr-src artifacts. particularly considering that solr-src is already a superset of lucene-src ... it just seems like one uber lucene-solr-src package of the "dev" tree would be the simplest most straight forward thing to ship for people who want source. (particularly looking forward to 4.0 when we'll also have "modules" in the top level ... should that really be a seperate src package?) The only advantage i can think of to having seperate solr/lucene src packages is the size issue ... the lucene-src by itself is much smaller and that has it's perks for people who really only want src ... but i still wonder about dev-tools (and modules) and wether it would make sense for the lucene-src package to be from the root of the "dev" tree but excluding ./solr? -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
: > glitch: it lists the Solr version as "3.0.0.2011.03.06.20.12.33" (which i : > know means it wasn't regenerated with the forrest properties set by ant). : : This is wrong and misleading. As you see in this long and confusing : string: 2011.03.06 was the date that I updated forrest, regenerated : the site, and included into the release candidate. How much more up to : date can it be!!? : : I did my part. I have no idea what this version string means but I it comes from the ant specversion variable, which default to being date based (same thing goes into the jar manifests if you don't specify specversion when building, pretty sure lucene works the same way) The way it gets into the solr docs is via a property file generated by the build (see the init-forrest-entities, it's setup as a dependency for just about everything) that forrest then reads. the old release process docs were specific that the forrest docs needed to be rebuilt *after* running ant with the specversion set... > http://wiki.apache.org/solr/HowToReleaseSlowly > > # On the branch, compile the code and run unit tests. > * ant -Dversion=X.Y.M -Dspecversion=X.Y.M -Dmaven_version=X.Y.M clean > test > # Regenerate the "site" docs per Website_Update_HOWTO so the documentation > included with this release will reflect the correct version number (at > the moment, this is specific to the tutorial) ...but we could certianly improve the build.xml to try and automate that as part of the new "prepare-release" target ... using an task for forrest if nothing else. And for the record robert: (allthough i hope you already know this) You didn't do "your part", you've done way more then "your part" and it's been awesome. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
Too much here to reply to all the points at once... but I'll take a stab at some of them. - "maven" directory in the binary release - that was a mistake/bug - has been fixed in build.xml - I'm definitely for separate source and binary releases - makes so much more sense post merge. solr's "src" is particularly great now... one can modify any part (lucene, modules, etc) and easily rebuild. "bin" really makes sense given the size of "src" (size, number of files, more complex directory structure, etc), and the number of solr users that want to know nothing about java. - in the future, I think it makes sense to cut down the binary distro even further... cut out the complexity of including the site, cut out the javadoc. - no, there is no requirement that binary artifacts contain source code -Yonik http://lucidimagination.com On Thu, Mar 10, 2011 at 6:49 PM, Chris Hostetter wrote: > > : Artifacts are located here: http://s.apache.org/solrcene31rc0 > > Finally got a chance to look at 3.1 rc0. > > my comments are below -- they are in the order i encountered them ... > stream of conciousness. Note that this was my first real chance to look > at the new packaging work folks have been doing to deal with the merged > dev tree (ie: the solr source only packaging, and how we include the > lucene jars in solr releases, etc...). I also have to confess being > woefully behind on reading hte dev list and jira, so forgive me if any of > this has already been discussed / dealt with... > > The short summary, i'm a -1 for these RC0 packages > > I focused on the *.tgz files, assuming (for now) that the zip files are > consistent > > > I started with apache-solr-3.1.0-src.tgz > > The first thing that jumped out at me when i unpacked it was that the > directory structure i get was definitley not what i was expecting. As a > committer familiar with how the tree works, i understand what these > directories are, but i suspect this may confuse folks who have downloaded > solr in the past, and those that haven't are going to be double confused. > > At a minimum the fact that there is no top level README.txt file seems > like a major oversight that we should definitely deal with. > > It also seems like we should probably have a README.txt file in dev-tools > (may not be needed if a top level README.txt explains it, but it still > seems like a good idea) > > looking in the "solr" directory, i look at it's README.txt file, and see > the section "Files Included In Apache Solr Distributions" it refers to a > lot of stuff that is not actaully included in the distribution (because > this is the *src* only distribution). it's one thing to assume people > downloading the *src* package will understand why the war nad jar aren't > in solr/dist/ but we also refer to a "docs" directory that doesn't exist > until they build it. > > If we really want to ship a Solr src only package (which i think it's a > great idea) we need to figure out a way to rework/structure this > README.txt file to make sense for both cases (or ship two differnet ones > -- but that seems like a bad idea) ... we could start by moving the > "Instructions for Building Apache Solr from Source" up and rewording the > "Files Included" section ... but even before that i notice we refer to > docs/tutorial.html in the "Getting Started" section > > looking only at the src release, i couldn't even find any documentation on > how to build the tutorial and other files -- again: since this is a src > only release, it may be ok to only include the "src" of the tutorial, but > we should at least mention somewhere how to build it. > > After running "ant test" from the top level, and "ant example" in the solr > dir, i had a working example dir that seemed to be functioning fine, but i > still had no javadocs for solr. when i tried to run "ant javadoc-all" in > the solr directory, javadoc actaully failed with a DocletAbortException > stack trace because of a FileNotFoundException when trying to copy > ./build/docs/api/prettify/stylesheet+prettify.css (i have a > ./build/docs/api/prettify/ but it's empty ... not sure what target was > expected to populate it) > > switching tracks, i looked at solr's CHANGES.txt I noticed a few small > things... > > * under the "Versions of Major Components" we list "Apache Lucene trunk" > * below the 3.1 changes is a list of 1.4.0 changes -- but no 1.4.1 > changes? > * we had discussed on the dev list that we should stop including changes > from older "major" versions (ie: 3.x CHANGES.txt would only list things > from 3.0 on) ... i thought i remembered people agreeing that was agood > idea, but maybe i was imaginging that. > > > As i mentioned -- most of the issues were really about documentation and > expectation setting for a "src" release. the README and ant task > descriptions we have were never really written with that idea in mind. > > > Next I looked at apache-solr-3.1.0.tgz > > Other then the minor CHANGES.txt stuff
Re: [VOTE] Lucene and Solr 3.1 release candidate
Thanks for the review hoss... the rest of this stuff should surely be fixed (FYI won't be by me, I did my time) I only had one comment. > exist -- dist and docs. Looking at the tutorial, i noticed the first > glitch: it lists the Solr version as "3.0.0.2011.03.06.20.12.33" (which i > know means it wasn't regenerated with the forrest properties set by ant). This is wrong and misleading. As you see in this long and confusing string: 2011.03.06 was the date that I updated forrest, regenerated the site, and included into the release candidate. How much more up to date can it be!!? I did my part. I have no idea what this version string means but I regenerated forrest. If someone wants the string to display something else, then they need to change it and commit it. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
: Artifacts are located here: http://s.apache.org/solrcene31rc0 Finally got a chance to look at 3.1 rc0. my comments are below -- they are in the order i encountered them ... stream of conciousness. Note that this was my first real chance to look at the new packaging work folks have been doing to deal with the merged dev tree (ie: the solr source only packaging, and how we include the lucene jars in solr releases, etc...). I also have to confess being woefully behind on reading hte dev list and jira, so forgive me if any of this has already been discussed / dealt with... The short summary, i'm a -1 for these RC0 packages I focused on the *.tgz files, assuming (for now) that the zip files are consistent I started with apache-solr-3.1.0-src.tgz The first thing that jumped out at me when i unpacked it was that the directory structure i get was definitley not what i was expecting. As a committer familiar with how the tree works, i understand what these directories are, but i suspect this may confuse folks who have downloaded solr in the past, and those that haven't are going to be double confused. At a minimum the fact that there is no top level README.txt file seems like a major oversight that we should definitely deal with. It also seems like we should probably have a README.txt file in dev-tools (may not be needed if a top level README.txt explains it, but it still seems like a good idea) looking in the "solr" directory, i look at it's README.txt file, and see the section "Files Included In Apache Solr Distributions" it refers to a lot of stuff that is not actaully included in the distribution (because this is the *src* only distribution). it's one thing to assume people downloading the *src* package will understand why the war nad jar aren't in solr/dist/ but we also refer to a "docs" directory that doesn't exist until they build it. If we really want to ship a Solr src only package (which i think it's a great idea) we need to figure out a way to rework/structure this README.txt file to make sense for both cases (or ship two differnet ones -- but that seems like a bad idea) ... we could start by moving the "Instructions for Building Apache Solr from Source" up and rewording the "Files Included" section ... but even before that i notice we refer to docs/tutorial.html in the "Getting Started" section looking only at the src release, i couldn't even find any documentation on how to build the tutorial and other files -- again: since this is a src only release, it may be ok to only include the "src" of the tutorial, but we should at least mention somewhere how to build it. After running "ant test" from the top level, and "ant example" in the solr dir, i had a working example dir that seemed to be functioning fine, but i still had no javadocs for solr. when i tried to run "ant javadoc-all" in the solr directory, javadoc actaully failed with a DocletAbortException stack trace because of a FileNotFoundException when trying to copy ./build/docs/api/prettify/stylesheet+prettify.css (i have a ./build/docs/api/prettify/ but it's empty ... not sure what target was expected to populate it) switching tracks, i looked at solr's CHANGES.txt I noticed a few small things... * under the "Versions of Major Components" we list "Apache Lucene trunk" * below the 3.1 changes is a list of 1.4.0 changes -- but no 1.4.1 changes? * we had discussed on the dev list that we should stop including changes from older "major" versions (ie: 3.x CHANGES.txt would only list things from 3.0 on) ... i thought i remembered people agreeing that was agood idea, but maybe i was imaginging that. As i mentioned -- most of the issues were really about documentation and expectation setting for a "src" release. the README and ant task descriptions we have were never really written with that idea in mind. Next I looked at apache-solr-3.1.0.tgz Other then the minor CHANGES.txt stuff mentioned above, this package made much more sense when i first unpacked it. There is a top level README.txt, and most things mentioned in the README.txt file seemed to exist -- dist and docs. Looking at the tutorial, i noticed the first glitch: it lists the Solr version as "3.0.0.2011.03.06.20.12.33" (which i know means it wasn't regenerated with the forrest properties set by ant). Other then that, the tutorial looks good, the example seems to work, and the link from the tutorial to the javadocs works and i can browse them just fine. Then I realized there was no "src" directory. i'm not sure if this was intentional (don't all of our releases need to include the source, even the binary ones?) but at the very least we have a problem with the README.txt which says the src should be there and that you should be able to rebuild it with and (except that we also don't have a build.xml file even if we had the source) This binary distribution also seems to be more redundent then it
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 like solr-foo.1.5.jar (see the commons-csv from > 1.4) You're right. I have no idea why this didn't occur to me. I think this should be fixed before 3.1 gets released. I've created an issue to track the work: https://issues.apache.org/jira/browse/LUCENE-2957 Steve
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Mar 8, 2011, at 11:27 AM, Sanne Grinovero wrote: > 2011/3/8 Steven A Rowe : >> Hi Sanne, >> >> 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 like solr-foo.1.5.jar (see the commons-csv from 1.4) >> >> 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 (from the >> top-level directory containing lucene, solr, etc.): >> >>ant get-maven-poms >>mvn -N -P bootstrap install >> >> Maybe there should also be a way to deploy these to an internal repository? >> >> Steve > > Hi Steve, > thank you for the answer. I'm not personally worried as I'm unaffected > by this issue, just thought to let the list know, so core developers > can evaluate how urgent it is. > > I'm not sold on the "several non-mavenized dependencies" argument: if > I adjust my pom locally to refer to a released Jetty version I have no > other build nor test issues, so this should be the only artifact > unless you refer to some other optional dependency. > > Also I used to depend on Solr in the past via maven, without issues - > so it looks to me that this is going to break expectations, as it > worked properly before. > > I'm totally fine with as long as you're all aware of it and making a > conscious decision, I don't think waiting for a Jetty release is a > reasonable option, but I'd add at least a warning in the release > notes. > > Regards, > Sanne > >> >>> -Original Message- >>> From: Sanne Grinovero [mailto:sanne.grinov...@gmail.com] >>> Sent: Tuesday, March 08, 2011 6:44 AM >>> To: dev@lucene.apache.org >>> Subject: Re: [VOTE] Lucene and Solr 3.1 release candidate >>> >>> Hello, >>> the lucene-solr-grandparent pom [1] file mentions a jetty version >>> "6.1.26-patched-JETTY-1340" which is not available in the repositories >>> where I would expect it. >>> Do I need to enable some additional repository? >>> >>> This seems related to SOLR-2381. >>> >>> I think for people using Solr as their dependency via Maven, this is a >>> blocker; of course not everyone uses it so I've no strong opinions >>> about this, but thought to let you know. >>> Personally I'd depend on the released version of jetty, and document >>> that this bug is not fixed until Jetty version XY is released; in >>> alternative, I'd add keep the pom as is but instructions and warnings >>> in the release notes would be very welcome. (I couldn't find a >>> Chances.html for Solr?) >>> >>> Regards, >>> Sanne >>> >>> [1] http://people.apache.org/~rmuir/staging_area/lucene-solr-3.1RC0- >>> rev1078688/lucene-3.1RC0/maven/org/apache/lucene/lucene-solr- >>> grandparent/3.1.0/lucene-solr-grandparent-3.1.0.pom >>> >>> 2011/3/8 Shai Erera : >>>> I found what seems to be a "glitch" in StopFilter's ctors -- the boolean >>>> 'enablePosInc' was removed from the ctors and users now have to use the >>>> setter instead. However, the ctors do default to 'true' if the passed in >>>> Version is onOrAfter(29). >>>> >>>> All of FilteringTokenFilter sub-classes include the enablePosIncr in >>> their >>>> ctors, including FilteringTF itself. Therefore I assume the parameter >>> was >>>> mistakenly dropped from StopFilter's ctors. Also, the @deprecated text >>>> doesn't mention how should I enable/disable it, and reading the source >>> code >>>> doesn't help either, since the setter/getter are in FilteringTF. >>>> >>>> Also, LengthFilter has a deprecated ctor, but the class was added on Nov >>> 16 >>>> and I don't see it in 3.0.3. So perhaps we can remove that ctor (and add >>> a >>>> @since tag to the class)? >>>> >>>> I don't know if these two warrant a new RC but I think they are >>> important to >>>> fix. >>>> >>>> Shai >>>> >>>> On Mon, Mar 7, 2011 at 5:52 PM, Smiley, David W. >>> wrote: >>>>> >>>>> So https://issues.apache.org/jira
Re: [VOTE] Lucene and Solr 3.1 release candidate
2011/3/8 Steven A Rowe : > 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 (from the > top-level directory containing lucene, solr, etc.): > > ant get-maven-poms > mvn -N -P bootstrap install > > Maybe there should also be a way to deploy these to an internal repository? > > Steve Hi Steve, thank you for the answer. I'm not personally worried as I'm unaffected by this issue, just thought to let the list know, so core developers can evaluate how urgent it is. I'm not sold on the "several non-mavenized dependencies" argument: if I adjust my pom locally to refer to a released Jetty version I have no other build nor test issues, so this should be the only artifact unless you refer to some other optional dependency. Also I used to depend on Solr in the past via maven, without issues - so it looks to me that this is going to break expectations, as it worked properly before. I'm totally fine with as long as you're all aware of it and making a conscious decision, I don't think waiting for a Jetty release is a reasonable option, but I'd add at least a warning in the release notes. Regards, Sanne > >> -Original Message- >> From: Sanne Grinovero [mailto:sanne.grinov...@gmail.com] >> Sent: Tuesday, March 08, 2011 6:44 AM >> To: dev@lucene.apache.org >> Subject: Re: [VOTE] Lucene and Solr 3.1 release candidate >> >> Hello, >> the lucene-solr-grandparent pom [1] file mentions a jetty version >> "6.1.26-patched-JETTY-1340" which is not available in the repositories >> where I would expect it. >> Do I need to enable some additional repository? >> >> This seems related to SOLR-2381. >> >> I think for people using Solr as their dependency via Maven, this is a >> blocker; of course not everyone uses it so I've no strong opinions >> about this, but thought to let you know. >> Personally I'd depend on the released version of jetty, and document >> that this bug is not fixed until Jetty version XY is released; in >> alternative, I'd add keep the pom as is but instructions and warnings >> in the release notes would be very welcome. (I couldn't find a >> Chances.html for Solr?) >> >> Regards, >> Sanne >> >> [1] http://people.apache.org/~rmuir/staging_area/lucene-solr-3.1RC0- >> rev1078688/lucene-3.1RC0/maven/org/apache/lucene/lucene-solr- >> grandparent/3.1.0/lucene-solr-grandparent-3.1.0.pom >> >> 2011/3/8 Shai Erera : >> > I found what seems to be a "glitch" in StopFilter's ctors -- the boolean >> > 'enablePosInc' was removed from the ctors and users now have to use the >> > setter instead. However, the ctors do default to 'true' if the passed in >> > Version is onOrAfter(29). >> > >> > All of FilteringTokenFilter sub-classes include the enablePosIncr in >> their >> > ctors, including FilteringTF itself. Therefore I assume the parameter >> was >> > mistakenly dropped from StopFilter's ctors. Also, the @deprecated text >> > doesn't mention how should I enable/disable it, and reading the source >> code >> > doesn't help either, since the setter/getter are in FilteringTF. >> > >> > Also, LengthFilter has a deprecated ctor, but the class was added on Nov >> 16 >> > and I don't see it in 3.0.3. So perhaps we can remove that ctor (and add >> a >> > @since tag to the class)? >> > >> > I don't know if these two warrant a new RC but I think they are >> important to >> > fix. >> > >> > Shai >> > >> > On Mon, Mar 7, 2011 at 5:52 PM, Smiley, David W. >> wrote: >> >> >> >> So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in >> >> yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have >> waited >> >> for a committer to agree with the issue. I would have had it in >> Saturday. >> >> >> >> ~ David Smiley >> >> >> >> On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: >> >> >> >> > Hi all, >> >> > >> >> > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, >> >> > both from revision 1078688 of >> >> > http:
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 (from the top-level directory containing lucene, solr, etc.): ant get-maven-poms mvn -N -P bootstrap install Maybe there should also be a way to deploy these to an internal repository? Steve > -Original Message- > From: Sanne Grinovero [mailto:sanne.grinov...@gmail.com] > Sent: Tuesday, March 08, 2011 6:44 AM > To: dev@lucene.apache.org > Subject: Re: [VOTE] Lucene and Solr 3.1 release candidate > > Hello, > the lucene-solr-grandparent pom [1] file mentions a jetty version > "6.1.26-patched-JETTY-1340" which is not available in the repositories > where I would expect it. > Do I need to enable some additional repository? > > This seems related to SOLR-2381. > > I think for people using Solr as their dependency via Maven, this is a > blocker; of course not everyone uses it so I've no strong opinions > about this, but thought to let you know. > Personally I'd depend on the released version of jetty, and document > that this bug is not fixed until Jetty version XY is released; in > alternative, I'd add keep the pom as is but instructions and warnings > in the release notes would be very welcome. (I couldn't find a > Chances.html for Solr?) > > Regards, > Sanne > > [1] http://people.apache.org/~rmuir/staging_area/lucene-solr-3.1RC0- > rev1078688/lucene-3.1RC0/maven/org/apache/lucene/lucene-solr- > grandparent/3.1.0/lucene-solr-grandparent-3.1.0.pom > > 2011/3/8 Shai Erera : > > I found what seems to be a "glitch" in StopFilter's ctors -- the boolean > > 'enablePosInc' was removed from the ctors and users now have to use the > > setter instead. However, the ctors do default to 'true' if the passed in > > Version is onOrAfter(29). > > > > All of FilteringTokenFilter sub-classes include the enablePosIncr in > their > > ctors, including FilteringTF itself. Therefore I assume the parameter > was > > mistakenly dropped from StopFilter's ctors. Also, the @deprecated text > > doesn't mention how should I enable/disable it, and reading the source > code > > doesn't help either, since the setter/getter are in FilteringTF. > > > > Also, LengthFilter has a deprecated ctor, but the class was added on Nov > 16 > > and I don't see it in 3.0.3. So perhaps we can remove that ctor (and add > a > > @since tag to the class)? > > > > I don't know if these two warrant a new RC but I think they are > important to > > fix. > > > > Shai > > > > On Mon, Mar 7, 2011 at 5:52 PM, Smiley, David W. > wrote: > >> > >> So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in > >> yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have > waited > >> for a committer to agree with the issue. I would have had it in > Saturday. > >> > >> ~ David Smiley > >> > >> On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: > >> > >> > Hi all, > >> > > >> > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, > >> > both from revision 1078688 of > >> > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > >> > Thanks for all your help! Please test them and give your votes, the > >> > tentative release date for both versions is Sunday, March 13th, 2011. > >> > Only votes from Lucene PMC are binding, but everyone is welcome to > >> > check the release candidates and voice their approval or disapproval. > >> > The vote passes if at least three binding +1 votes are cast. > >> > > >> > The release candidates are produced in parallel because in 2010 we > >> > merged the development of Lucene and Solr in order to produce higher > >> > quality releases. While we voted to reserve the right to release > >> > Lucene by itself, in my opinion we should definitely try to avoid > this > >> > unless absolutely necessary, as it would ultimately cause more work > >> > and complication: instead it would be far easier to just fix whatever > >> > issues are discovered and respin both releases again. > >> > > >> > Because of this, I ask that you cast a single vote to cover both > >> > releases. If the vote s
Re: [VOTE] Lucene and Solr 3.1 release candidate
What about StopFilter (and LengthFilter) -- should we fix them before 3.1? Shai On Tue, Mar 8, 2011 at 4:05 PM, Uwe Schindler wrote: > I opened https://issues.apache.org/jira/browse/LUCENE-2954 > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -Original Message- > > From: Uwe Schindler [mailto:u...@thetaphi.de] > > Sent: Tuesday, March 08, 2011 2:43 PM > > To: dev@lucene.apache.org > > Subject: RE: [VOTE] Lucene and Solr 3.1 release candidate > > > > Hi, > > > > I found a serious issue in CheckIndex.java (lines 357++): > > If you run CheckIndex on an index updated or changed with 3.1 it print > the > > following: > > > > 2011-03-08 14:38:56,373 INFO org.apache.lucene.index.CheckIndex - > > Segments file=segments_g19 numSegments=5 version=-11 [Lucene 1.3 or > > prior] > > > > Too stupid. We should check all other version numbers printed in > CheckIndex > > and fix accordingly. I know, Shaie added new versions in several other > files, > > too. I don't think we can provide this to users, as it will cause lot's > of JIRA > > issues complaining about that. > > > > Do we also need to fix the Solr' ConcurentLRUMap issue? Yonik? I provided > a > > patch this morning. > > > > Uwe > > > > - > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > > > -Original Message- > > > From: Robert Muir [mailto:rcm...@gmail.com] > > > Sent: Monday, March 07, 2011 7:33 AM > > > To: dev@lucene.apache.org > > > Subject: [VOTE] Lucene and Solr 3.1 release candidate > > > > > > Hi all, > > > > > > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, > > > both from revision 1078688 of > > > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > > > Thanks for all your help! Please test them and give your votes, the > > > tentative release date for both versions is Sunday, March 13th, 2011. > > > Only votes from Lucene PMC are binding, but everyone is welcome to > > > check the release candidates and voice their approval or disapproval. > > > The vote passes if at least three binding +1 votes are cast. > > > > > > The release candidates are produced in parallel because in 2010 we > > > merged the development of Lucene and Solr in order to produce higher > > > quality releases. While we voted to reserve the right to release > > > Lucene by itself, in my opinion we should definitely try to avoid this > > > unless absolutely necessary, as it would ultimately cause more work > > > and complication: instead it would be far easier to just fix whatever > > > issues are discovered and respin both releases again. > > > > > > Because of this, I ask that you cast a single vote to cover both > > > releases. If the vote succeeds, both sets of artifacts can go their > > > separate ways to the different websites. > > > > > > Artifacts are located here: http://s.apache.org/solrcene31rc0 > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > > additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > > commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
RE: [VOTE] Lucene and Solr 3.1 release candidate
I opened https://issues.apache.org/jira/browse/LUCENE-2954 - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Tuesday, March 08, 2011 2:43 PM > To: dev@lucene.apache.org > Subject: RE: [VOTE] Lucene and Solr 3.1 release candidate > > Hi, > > I found a serious issue in CheckIndex.java (lines 357++): > If you run CheckIndex on an index updated or changed with 3.1 it print the > following: > > 2011-03-08 14:38:56,373 INFO org.apache.lucene.index.CheckIndex - > Segments file=segments_g19 numSegments=5 version=-11 [Lucene 1.3 or > prior] > > Too stupid. We should check all other version numbers printed in CheckIndex > and fix accordingly. I know, Shaie added new versions in several other files, > too. I don't think we can provide this to users, as it will cause lot's of > JIRA > issues complaining about that. > > Do we also need to fix the Solr' ConcurentLRUMap issue? Yonik? I provided a > patch this morning. > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -Original Message- > > From: Robert Muir [mailto:rcm...@gmail.com] > > Sent: Monday, March 07, 2011 7:33 AM > > To: dev@lucene.apache.org > > Subject: [VOTE] Lucene and Solr 3.1 release candidate > > > > Hi all, > > > > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, > > both from revision 1078688 of > > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > > Thanks for all your help! Please test them and give your votes, the > > tentative release date for both versions is Sunday, March 13th, 2011. > > Only votes from Lucene PMC are binding, but everyone is welcome to > > check the release candidates and voice their approval or disapproval. > > The vote passes if at least three binding +1 votes are cast. > > > > The release candidates are produced in parallel because in 2010 we > > merged the development of Lucene and Solr in order to produce higher > > quality releases. While we voted to reserve the right to release > > Lucene by itself, in my opinion we should definitely try to avoid this > > unless absolutely necessary, as it would ultimately cause more work > > and complication: instead it would be far easier to just fix whatever > > issues are discovered and respin both releases again. > > > > Because of this, I ask that you cast a single vote to cover both > > releases. If the vote succeeds, both sets of artifacts can go their > > separate ways to the different websites. > > > > Artifacts are located here: http://s.apache.org/solrcene31rc0 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Lucene and Solr 3.1 release candidate
Hi, I found a serious issue in CheckIndex.java (lines 357++): If you run CheckIndex on an index updated or changed with 3.1 it print the following: 2011-03-08 14:38:56,373 INFO org.apache.lucene.index.CheckIndex - Segments file=segments_g19 numSegments=5 version=-11 [Lucene 1.3 or prior] Too stupid. We should check all other version numbers printed in CheckIndex and fix accordingly. I know, Shaie added new versions in several other files, too. I don't think we can provide this to users, as it will cause lot's of JIRA issues complaining about that. Do we also need to fix the Solr' ConcurentLRUMap issue? Yonik? I provided a patch this morning. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Monday, March 07, 2011 7:33 AM > To: dev@lucene.apache.org > Subject: [VOTE] Lucene and Solr 3.1 release candidate > > Hi all, > > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, both from > revision 1078688 of > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > Thanks for all your help! Please test them and give your votes, the tentative > release date for both versions is Sunday, March 13th, 2011. > Only votes from Lucene PMC are binding, but everyone is welcome to check > the release candidates and voice their approval or disapproval. > The vote passes if at least three binding +1 votes are cast. > > The release candidates are produced in parallel because in 2010 we merged > the development of Lucene and Solr in order to produce higher quality > releases. While we voted to reserve the right to release Lucene by itself, in > my opinion we should definitely try to avoid this unless absolutely necessary, > as it would ultimately cause more work and complication: instead it would be > far easier to just fix whatever issues are discovered and respin both releases > again. > > Because of this, I ask that you cast a single vote to cover both releases. If > the > vote succeeds, both sets of artifacts can go their separate ways to the > different websites. > > Artifacts are located here: http://s.apache.org/solrcene31rc0 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Tue, Mar 8, 2011 at 8:11 AM, Shai Erera wrote: > I found another problem. > > Maybe something changed in the logic of FSDirectory.open(), but now when I > run some tests over my code, I see that if MMapDirectory is chosen and an > attempt to seek to an incorrect position is made, IllegalArgumentException > is thrown, instead of IOE. This breaks my code which catches IOE and handle > it. > > While I can modify my code to also catch IAE, I wonder if it's ok that > MMapDir throws such an exception instead of IOE. It's actually thrown from > ByteBuffer, however the caller, which holds a reference to a Directory, does > not know if the underlying impl is MMapDir, LinuxFSDir etc. > This isn't a bug: Its clearly documented in the release notes that FSDirectory.open()'s behavior has changed to return different implementations for some platforms. Additionally the documentation in FSDirectory states that different implementations have quirks and recommends instantiating the desired implementation directly. The behavior of what exceptions MMapDirectory throws has not changed: it throws the same exceptions it always did. If your code depends upon the exact exception classes or text I think you should instantiate the directory directly (and for the record, i think this stuff is still "open-season" to change regardless, as its internal). Nowhere does any javadocs claim that any specific runtime exception is thrown. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Lucene and Solr 3.1 release candidate
I think we already have code that maps exceptions to IOException ones. But IAE is not catched. If Maps e.g. BufferUnderflowException to EOFException. Maybe we should map all RuntimeExceptions inside the read/seek methods to wrapped IOExceptions? This is a bug that existed in MMap since the beginning, we fixed some of them (the EOF case, because its needed even by Lucene internally). I don't know how to proceed. Can you open an issue? I will be glad to fix it, but not sure if we should need to fix it in the 3.1 branch as the bug already existed (yes, I know MMap was not a default in 3.0). Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de/> http://www.thetaphi.de eMail: u...@thetaphi.de From: Shai Erera [mailto:ser...@gmail.com] Sent: Tuesday, March 08, 2011 2:12 PM To: dev@lucene.apache.org Subject: Re: [VOTE] Lucene and Solr 3.1 release candidate I found another problem. Maybe something changed in the logic of FSDirectory.open(), but now when I run some tests over my code, I see that if MMapDirectory is chosen and an attempt to seek to an incorrect position is made, IllegalArgumentException is thrown, instead of IOE. This breaks my code which catches IOE and handle it. While I can modify my code to also catch IAE, I wonder if it's ok that MMapDir throws such an exception instead of IOE. It's actually thrown from ByteBuffer, however the caller, which holds a reference to a Directory, does not know if the underlying impl is MMapDir, LinuxFSDir etc. Should we fix it on the new branch and go for a second RC? Shai On Tue, Mar 8, 2011 at 9:19 AM, Shai Erera wrote: I found what seems to be a "glitch" in StopFilter's ctors -- the boolean 'enablePosInc' was removed from the ctors and users now have to use the setter instead. However, the ctors do default to 'true' if the passed in Version is onOrAfter(29). All of FilteringTokenFilter sub-classes include the enablePosIncr in their ctors, including FilteringTF itself. Therefore I assume the parameter was mistakenly dropped from StopFilter's ctors. Also, the @deprecated text doesn't mention how should I enable/disable it, and reading the source code doesn't help either, since the setter/getter are in FilteringTF. Also, LengthFilter has a deprecated ctor, but the class was added on Nov 16 and I don't see it in 3.0.3. So perhaps we can remove that ctor (and add a @since tag to the class)? I don't know if these two warrant a new RC but I think they are important to fix. Shai On Mon, Mar 7, 2011 at 5:52 PM, Smiley, David W. wrote: So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited for a committer to agree with the issue. I would have had it in Saturday. ~ David Smiley On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: > Hi all, > > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, > both from revision 1078688 of > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > Thanks for all your help! Please test them and give your votes, the > tentative release date for both versions is Sunday, March 13th, 2011. > Only votes from Lucene PMC are binding, but everyone is welcome to > check the release candidates and voice their approval or disapproval. > The vote passes if at least three binding +1 votes are cast. > > The release candidates are produced in parallel because in 2010 we > merged the development of Lucene and Solr in order to produce higher > quality releases. While we voted to reserve the right to release > Lucene by itself, in my opinion we should definitely try to avoid this > unless absolutely necessary, as it would ultimately cause more work > and complication: instead it would be far easier to just fix whatever > issues are discovered and respin both releases again. > > Because of this, I ask that you cast a single vote to cover both > releases. If the vote succeeds, both sets of artifacts can go their > separate ways to the different websites. > > Artifacts are located here: http://s.apache.org/solrcene31rc0 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
+1. I downloaded them all, checked sigs, compiled, tested both Lucene and Solr, ran the Solr demo. I also just want to thank Robert for the work he did on the licenses, etc. We need to make the stuff that goes into releases more testable and verifiable. On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: > Hi all, > > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, > both from revision 1078688 of > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > Thanks for all your help! Please test them and give your votes, the > tentative release date for both versions is Sunday, March 13th, 2011. > Only votes from Lucene PMC are binding, but everyone is welcome to > check the release candidates and voice their approval or disapproval. > The vote passes if at least three binding +1 votes are cast. > > The release candidates are produced in parallel because in 2010 we > merged the development of Lucene and Solr in order to produce higher > quality releases. While we voted to reserve the right to release > Lucene by itself, in my opinion we should definitely try to avoid this > unless absolutely necessary, as it would ultimately cause more work > and complication: instead it would be far easier to just fix whatever > issues are discovered and respin both releases again. > > Because of this, I ask that you cast a single vote to cover both > releases. If the vote succeeds, both sets of artifacts can go their > separate ways to the different websites. > > Artifacts are located here: http://s.apache.org/solrcene31rc0 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
I found another problem. Maybe something changed in the logic of FSDirectory.open(), but now when I run some tests over my code, I see that if MMapDirectory is chosen and an attempt to seek to an incorrect position is made, IllegalArgumentException is thrown, instead of IOE. This breaks my code which catches IOE and handle it. While I can modify my code to also catch IAE, I wonder if it's ok that MMapDir throws such an exception instead of IOE. It's actually thrown from ByteBuffer, however the caller, which holds a reference to a Directory, does not know if the underlying impl is MMapDir, LinuxFSDir etc. Should we fix it on the new branch and go for a second RC? Shai On Tue, Mar 8, 2011 at 9:19 AM, Shai Erera wrote: > I found what seems to be a "glitch" in StopFilter's ctors -- the boolean > 'enablePosInc' was removed from the ctors and users now have to use the > setter instead. However, the ctors do default to 'true' if the passed in > Version is onOrAfter(29). > > All of FilteringTokenFilter sub-classes include the enablePosIncr in their > ctors, including FilteringTF itself. Therefore I assume the parameter was > mistakenly dropped from StopFilter's ctors. Also, the @deprecated text > doesn't mention how should I enable/disable it, and reading the source code > doesn't help either, since the setter/getter are in FilteringTF. > > Also, LengthFilter has a deprecated ctor, but the class was added on Nov 16 > and I don't see it in 3.0.3. So perhaps we can remove that ctor (and add a > @since tag to the class)? > > I don't know if these two warrant a new RC but I think they are important > to fix. > > Shai > > > On Mon, Mar 7, 2011 at 5:52 PM, Smiley, David W. wrote: > >> So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in >> yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited >> for a committer to agree with the issue. I would have had it in Saturday. >> >> ~ David Smiley >> >> On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: >> >> > Hi all, >> > >> > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, >> > both from revision 1078688 of >> > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ >> > Thanks for all your help! Please test them and give your votes, the >> > tentative release date for both versions is Sunday, March 13th, 2011. >> > Only votes from Lucene PMC are binding, but everyone is welcome to >> > check the release candidates and voice their approval or disapproval. >> > The vote passes if at least three binding +1 votes are cast. >> > >> > The release candidates are produced in parallel because in 2010 we >> > merged the development of Lucene and Solr in order to produce higher >> > quality releases. While we voted to reserve the right to release >> > Lucene by itself, in my opinion we should definitely try to avoid this >> > unless absolutely necessary, as it would ultimately cause more work >> > and complication: instead it would be far easier to just fix whatever >> > issues are discovered and respin both releases again. >> > >> > Because of this, I ask that you cast a single vote to cover both >> > releases. If the vote succeeds, both sets of artifacts can go their >> > separate ways to the different websites. >> > >> > Artifacts are located here: http://s.apache.org/solrcene31rc0 >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >
Re: [VOTE] Lucene and Solr 3.1 release candidate
Hello, the lucene-solr-grandparent pom [1] file mentions a jetty version "6.1.26-patched-JETTY-1340" which is not available in the repositories where I would expect it. Do I need to enable some additional repository? This seems related to SOLR-2381. I think for people using Solr as their dependency via Maven, this is a blocker; of course not everyone uses it so I've no strong opinions about this, but thought to let you know. Personally I'd depend on the released version of jetty, and document that this bug is not fixed until Jetty version XY is released; in alternative, I'd add keep the pom as is but instructions and warnings in the release notes would be very welcome. (I couldn't find a Chances.html for Solr?) Regards, Sanne [1] http://people.apache.org/~rmuir/staging_area/lucene-solr-3.1RC0-rev1078688/lucene-3.1RC0/maven/org/apache/lucene/lucene-solr-grandparent/3.1.0/lucene-solr-grandparent-3.1.0.pom 2011/3/8 Shai Erera : > I found what seems to be a "glitch" in StopFilter's ctors -- the boolean > 'enablePosInc' was removed from the ctors and users now have to use the > setter instead. However, the ctors do default to 'true' if the passed in > Version is onOrAfter(29). > > All of FilteringTokenFilter sub-classes include the enablePosIncr in their > ctors, including FilteringTF itself. Therefore I assume the parameter was > mistakenly dropped from StopFilter's ctors. Also, the @deprecated text > doesn't mention how should I enable/disable it, and reading the source code > doesn't help either, since the setter/getter are in FilteringTF. > > Also, LengthFilter has a deprecated ctor, but the class was added on Nov 16 > and I don't see it in 3.0.3. So perhaps we can remove that ctor (and add a > @since tag to the class)? > > I don't know if these two warrant a new RC but I think they are important to > fix. > > Shai > > On Mon, Mar 7, 2011 at 5:52 PM, Smiley, David W. wrote: >> >> So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in >> yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited >> for a committer to agree with the issue. I would have had it in Saturday. >> >> ~ David Smiley >> >> On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: >> >> > Hi all, >> > >> > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, >> > both from revision 1078688 of >> > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ >> > Thanks for all your help! Please test them and give your votes, the >> > tentative release date for both versions is Sunday, March 13th, 2011. >> > Only votes from Lucene PMC are binding, but everyone is welcome to >> > check the release candidates and voice their approval or disapproval. >> > The vote passes if at least three binding +1 votes are cast. >> > >> > The release candidates are produced in parallel because in 2010 we >> > merged the development of Lucene and Solr in order to produce higher >> > quality releases. While we voted to reserve the right to release >> > Lucene by itself, in my opinion we should definitely try to avoid this >> > unless absolutely necessary, as it would ultimately cause more work >> > and complication: instead it would be far easier to just fix whatever >> > issues are discovered and respin both releases again. >> > >> > Because of this, I ask that you cast a single vote to cover both >> > releases. If the vote succeeds, both sets of artifacts can go their >> > separate ways to the different websites. >> > >> > Artifacts are located here: http://s.apache.org/solrcene31rc0 >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
I found what seems to be a "glitch" in StopFilter's ctors -- the boolean 'enablePosInc' was removed from the ctors and users now have to use the setter instead. However, the ctors do default to 'true' if the passed in Version is onOrAfter(29). All of FilteringTokenFilter sub-classes include the enablePosIncr in their ctors, including FilteringTF itself. Therefore I assume the parameter was mistakenly dropped from StopFilter's ctors. Also, the @deprecated text doesn't mention how should I enable/disable it, and reading the source code doesn't help either, since the setter/getter are in FilteringTF. Also, LengthFilter has a deprecated ctor, but the class was added on Nov 16 and I don't see it in 3.0.3. So perhaps we can remove that ctor (and add a @since tag to the class)? I don't know if these two warrant a new RC but I think they are important to fix. Shai On Mon, Mar 7, 2011 at 5:52 PM, Smiley, David W. wrote: > So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in > yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited > for a committer to agree with the issue. I would have had it in Saturday. > > ~ David Smiley > > On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: > > > Hi all, > > > > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, > > both from revision 1078688 of > > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > > Thanks for all your help! Please test them and give your votes, the > > tentative release date for both versions is Sunday, March 13th, 2011. > > Only votes from Lucene PMC are binding, but everyone is welcome to > > check the release candidates and voice their approval or disapproval. > > The vote passes if at least three binding +1 votes are cast. > > > > The release candidates are produced in parallel because in 2010 we > > merged the development of Lucene and Solr in order to produce higher > > quality releases. While we voted to reserve the right to release > > Lucene by itself, in my opinion we should definitely try to avoid this > > unless absolutely necessary, as it would ultimately cause more work > > and complication: instead it would be far easier to just fix whatever > > issues are discovered and respin both releases again. > > > > Because of this, I ask that you cast a single vote to cover both > > releases. If the vote succeeds, both sets of artifacts can go their > > separate ways to the different websites. > > > > Artifacts are located here: http://s.apache.org/solrcene31rc0 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Mon, Mar 7, 2011 at 10:52 AM, Smiley, David W. wrote: > So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in > yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited > for a committer to agree with the issue. I would have had it in Saturday. Oops, I thought it had made it (I accidentally marked fixed for 3.1). I guess the branch was created first. If we end up doing a respin, I can merge this to the branch. -Yonik http://lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited for a committer to agree with the issue. I would have had it in Saturday. ~ David Smiley On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: > Hi all, > > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, > both from revision 1078688 of > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > Thanks for all your help! Please test them and give your votes, the > tentative release date for both versions is Sunday, March 13th, 2011. > Only votes from Lucene PMC are binding, but everyone is welcome to > check the release candidates and voice their approval or disapproval. > The vote passes if at least three binding +1 votes are cast. > > The release candidates are produced in parallel because in 2010 we > merged the development of Lucene and Solr in order to produce higher > quality releases. While we voted to reserve the right to release > Lucene by itself, in my opinion we should definitely try to avoid this > unless absolutely necessary, as it would ultimately cause more work > and complication: instead it would be far easier to just fix whatever > issues are discovered and respin both releases again. > > Because of this, I ask that you cast a single vote to cover both > releases. If the vote succeeds, both sets of artifacts can go their > separate ways to the different websites. > > Artifacts are located here: http://s.apache.org/solrcene31rc0 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
So https://issues.apache.org/jira/browse/SOLR-2405 didn't make it in yesterday (apparently it didn't)? :-( Darn... maybe I shouldn't have waited for a committer to agree with the issue. I would have had it in Saturday. ~ David Smiley - Author: https://www.packtpub.com/solr-1-4-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/VOTE-Lucene-and-Solr-3-1-release-candidate-tp2645100p2646445.html Sent from the Solr - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Mon, Mar 7, 2011 at 9:36 AM, Grant Ingersoll wrote: > The Solr war (apache-solr-3.1.war) file isn't signed. Can probably do it by > hand. > Actually that war file shouldn't even be there. The problem is solr generates some 'intermediate' stuff in dist/ (used by maven tasks), and it got accidentally included. we should fix the maven stuff to use build/ and not put any intermediate stuff in dist... this is just asking for trouble like this. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
The Solr war (apache-solr-3.1.war) file isn't signed. Can probably do it by hand. On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: > Hi all, > > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, > both from revision 1078688 of > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > Thanks for all your help! Please test them and give your votes, the > tentative release date for both versions is Sunday, March 13th, 2011. > Only votes from Lucene PMC are binding, but everyone is welcome to > check the release candidates and voice their approval or disapproval. > The vote passes if at least three binding +1 votes are cast. > > The release candidates are produced in parallel because in 2010 we > merged the development of Lucene and Solr in order to produce higher > quality releases. While we voted to reserve the right to release > Lucene by itself, in my opinion we should definitely try to avoid this > unless absolutely necessary, as it would ultimately cause more work > and complication: instead it would be far easier to just fix whatever > issues are discovered and respin both releases again. > > Because of this, I ask that you cast a single vote to cover both > releases. If the vote succeeds, both sets of artifacts can go their > separate ways to the different websites. > > Artifacts are located here: http://s.apache.org/solrcene31rc0 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Mon, Mar 7, 2011 at 8:07 AM, Grant Ingersoll wrote: > > I'm fine w/ it being pushed (I was going to suggest it actually), but I guess > I missed the mail saying it was yesterday and thought I still might have time > to fix it. What thread was that on? > http://www.lucidimagination.com/search/document/fced217ddd7d1769/wind_down_for_3_1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Mar 7, 2011, at 8:02 AM, Robert Muir wrote: > On Mon, Mar 7, 2011 at 7:56 AM, Grant Ingersoll wrote: >> How do we have a release candidate if we still have issues open? Or is this >> just a test run? >> > > Anything in JIRA can make it in 3.2 instead. I said already, that > yesterday was the time I had available to produce this RC build. > I'm fine w/ it being pushed (I was going to suggest it actually), but I guess I missed the mail saying it was yesterday and thought I still might have time to fix it. What thread was that on? -Grant - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
On Mon, Mar 7, 2011 at 7:56 AM, Grant Ingersoll wrote: > How do we have a release candidate if we still have issues open? Or is this > just a test run? > Anything in JIRA can make it in 3.2 instead. I said already, that yesterday was the time I had available to produce this RC build. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Lucene and Solr 3.1 release candidate
How do we have a release candidate if we still have issues open? Or is this just a test run? On Mar 7, 2011, at 1:32 AM, Robert Muir wrote: > Hi all, > > I have posted a release candidate for both Lucene 3.1 and Solr 3.1, > both from revision 1078688 of > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ > Thanks for all your help! Please test them and give your votes, the > tentative release date for both versions is Sunday, March 13th, 2011. > Only votes from Lucene PMC are binding, but everyone is welcome to > check the release candidates and voice their approval or disapproval. > The vote passes if at least three binding +1 votes are cast. > > The release candidates are produced in parallel because in 2010 we > merged the development of Lucene and Solr in order to produce higher > quality releases. While we voted to reserve the right to release > Lucene by itself, in my opinion we should definitely try to avoid this > unless absolutely necessary, as it would ultimately cause more work > and complication: instead it would be far easier to just fix whatever > issues are discovered and respin both releases again. > > Because of this, I ask that you cast a single vote to cover both > releases. If the vote succeeds, both sets of artifacts can go their > separate ways to the different websites. > > Artifacts are located here: http://s.apache.org/solrcene31rc0 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[VOTE] Lucene and Solr 3.1 release candidate
Hi all, I have posted a release candidate for both Lucene 3.1 and Solr 3.1, both from revision 1078688 of http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_1/ Thanks for all your help! Please test them and give your votes, the tentative release date for both versions is Sunday, March 13th, 2011. Only votes from Lucene PMC are binding, but everyone is welcome to check the release candidates and voice their approval or disapproval. The vote passes if at least three binding +1 votes are cast. The release candidates are produced in parallel because in 2010 we merged the development of Lucene and Solr in order to produce higher quality releases. While we voted to reserve the right to release Lucene by itself, in my opinion we should definitely try to avoid this unless absolutely necessary, as it would ultimately cause more work and complication: instead it would be far easier to just fix whatever issues are discovered and respin both releases again. Because of this, I ask that you cast a single vote to cover both releases. If the vote succeeds, both sets of artifacts can go their separate ways to the different websites. Artifacts are located here: http://s.apache.org/solrcene31rc0 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
