[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Russell updated SOLR-2894: Attachment: distributed_pivot.patch facet_pivot will not show up in distrib search if no contents, reversed behavior of sorting to comply with solr standard for facet.sort > Implement distributed pivot faceting > > > Key: SOLR-2894 > URL: https://issues.apache.org/jira/browse/SOLR-2894 > Project: Solr > Issue Type: Improvement >Reporter: Erik Hatcher > Fix For: 4.0 > > Attachments: SOLR-2894.patch, distributed_pivot.patch, > distributed_pivot.patch > > > Following up on SOLR-792, pivot faceting currently only supports > undistributed mode. Distributed pivot faceting needs to be implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3408) org.apache.lucene.store.AlreadyClosedException: MMapIndexInput already closed: MMapIndexInput(path="/eneeds/fs/apache-solr-ra-4.0/example/solr/data/index/_5e9_0.frq")
Nagendra Nagarajayya created SOLR-3408:
--
Summary: org.apache.lucene.store.AlreadyClosedException:
MMapIndexInput already closed:
MMapIndexInput(path="/eneeds/fs/apache-solr-ra-4.0/example/solr/data/index/_5e9_0.frq")
Key: SOLR-3408
URL: https://issues.apache.org/jira/browse/SOLR-3408
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 4.0
Environment: Linux Fedora 12 (2.6.32.16-141.fc12.x86_64 #1 SMP)
JDK 1.6.0_17-b04
Reporter: Nagendra Nagarajayya
Fix For: 4.0
Apr 21, 2012 2:22:22 PM org.apache.solr.core.SolrCore execute
INFO: [] webapp=/solr path=/select/
params={facet=true&debugQuery=true&start=0&q=*:*&facet.field=action_str&wt=xml&rows=10}
hits=8136707 status=500 QTime=29339
Apr 21, 2012 2:22:22 PM org.apache.solr.common.SolrException log
SEVERE: null:org.apache.lucene.store.AlreadyClosedException: MMapIndexInput
already closed:
MMapIndexInput(path="/eneeds/fs/apache-solr-ra-4.0/example/solr/data/index/_5e9_0.frq")
at
org.apache.lucene.store.MMapDirectory$MMapIndexInput.getFilePointer(MMapDirectory.java:380)
at
org.apache.lucene.codecs.lucene40.Lucene40PostingsReader$SegmentDocsEnumBase.(Lucene40PostingsReader.java:321)
at
org.apache.lucene.codecs.lucene40.Lucene40PostingsReader$AllDocsSegmentDocsEnum.(Lucene40PostingsReader.java:501)
at
org.apache.lucene.codecs.lucene40.Lucene40PostingsReader.newDocsEnum(Lucene40PostingsReader.java:239)
at
org.apache.lucene.codecs.lucene40.Lucene40PostingsReader.docs(Lucene40PostingsReader.java:220)
at
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum.docs(BlockTreeTermsReader.java:2123)
at org.apache.lucene.index.MultiTermsEnum.docs(MultiTermsEnum.java:400)
at
org.apache.lucene.search.FieldCacheImpl$DocTermsIndexCache.createValue(FieldCacheImpl.java:1176)
at
org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:248)
at
org.apache.lucene.search.FieldCacheImpl.getTermsIndex(FieldCacheImpl.java:1081)
at
org.apache.lucene.search.FieldCacheImpl.getTermsIndex(FieldCacheImpl.java:1077)
at
org.apache.solr.request.SimpleFacets.getFieldCacheCounts(SimpleFacets.java:463)
at
org.apache.solr.request.SimpleFacets.getTermCounts(SimpleFacets.java:310)
at
org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:396)
at
org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:205)
at
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:81)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:212)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1541)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:435)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:256)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261241#comment-13261241 ] Benson Margulies commented on SOLR-3405: You might be surprised by this, but I agree with you. I could build that plugin for you, mostly. Here's what I can't do for you. I can't arrange for you to declare a dependency in terms of the URL to a JAR. I'm sorry, but I can't undo the narrow-minded thinking of the founder of maven. What I can do is make it possible to have a two-pass maven build: the first run of maven would use such a plugin to download things (and, if you like, patch and build them from source), so that the second run would just find them in the local repo. Actually, I'm not quite being truthful. Maven has an extension architecture for talking to repos called 'wagons'. I think that I could set up an wagon that defined a 'repository' in terms of that CSV file I described above. Not too awful, come to think of it. You add a declaration of that wagon to the pom, and a rather funny element to the pom ... but consumers might not thank you. The central tenant of maven thinking (who does not pay enough rent) is that it's never a big deal to grab a jar and stick it in some convenient repo and use it, so why do we need to allow for getting jars from anywhere else? And lots of people all over find this tolerable. You don't, and I'm not particularly motivated to tell you that you're wrong. Still and all, given a days' warning of the need, Steve or I or anyone else who cared to do the reading could get noggit or anything else onto Central via OSSRH. If we want to ask the author first, we need time for a response. If we just want to push it under our own coordinates (I'd use 'us.dchbk'), then it's just the time it takes the jar to wander out there. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3393) Implement an optimized LFUCache
[ https://issues.apache.org/jira/browse/SOLR-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261203#comment-13261203 ] Shawn Heisey commented on SOLR-3393: Hoss, thanks for your comments. Since I was the one who wrote the previous version of this, I just opted to completely replace LFUCache rather than go with a "Fast" appendage. I hadn't considered the naming problem in quite the same light as "yet another fast*" name, but it did seem like a bad idea. Yonik had the same concern about stats being preserved forever on SOLR-2906, and he helped with a decay option to deal with that. I think the decay is a good idea. There was only one kind of decay before, applied to all elements anytime there were evictions, defaulted to on. In a new version of the patch for this issue (which I have not yet uploaded) I have now included two kinds of decay. There is the kind applied at eviction, now defaulting to off, and one applied at warming, defaulting to on. I will expand the documentation on the Wiki, making it clear that turning off the decay option will probably lead to an undesirable cache state. Currently the decay is implemented with a bit shift (>>> 1), I may make another option available that just subtracts one, and we can bikeshed about which option should be default. > Implement an optimized LFUCache > --- > > Key: SOLR-3393 > URL: https://issues.apache.org/jira/browse/SOLR-3393 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 3.6, 4.0 >Reporter: Shawn Heisey >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3393.patch, SOLR-3393.patch > > > SOLR-2906 gave us an inefficient LFU cache modeled on > FastLRUCache/ConcurrentLRUCache. It could use some serious improvement. The > following project includes an Apache 2.0 licensed O(1) implementation. The > second link is the paper (PDF warning) it was based on: > https://github.com/chirino/hawtdb > http://dhruvbird.com/lfu.pdf > Using this project and paper, I will attempt to make a new O(1) cache called > FastLFUCache that is modeled on LRUCache.java. This will (for now) leave the > existing LFUCache/ConcurrentLFUCache implementation in place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3393) Implement an optimized LFUCache
[
https://issues.apache.org/jira/browse/SOLR-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261197#comment-13261197
]
Hoss Man commented on SOLR-3393:
bq. I will attempt to make a new O(1) cache called FastLFUCache
{{#OhDearGodPleaseNotAnotherClassWithFastInTheName}}
Please, please, please lets end the madness of subjective adjectives in class
names ... if it's an LFU cache wrapped around a "hawtdb" why don't we just call
it "HawtDbLFUCache" ?
bq. I've been working on this. I've come to realize that I don't completely
understand how CacheRegenerator works. I suspect that it is geared around LRU
caches and that the new cache won't have any of the frequency information from
the old one, it will just put the entries into the cache as if they were new.
Can anyone confirm this?
The idea behind the CacheRegenerator API is to be as simple as possible and
agnostic to:
* the Cache Impl (ie: LRUCache vs LFUCache vs HawtDbLFUCache)
* the cache usage (ie: Query->DocSets vs Query->DocList vs
String->MyCustomClass)
* the means of generating values from keys (ie: how do you know which
MyCustomClass should be cached for which String)
... so you can have a custom (named) cache instance declared in your
solrconfig.xml with your own MySpecialCacheRegenerator that knows about your
usecase and might do something special with the keys/values (like: short-circut
part of the generation if it can see the data hasn't changed, or read from
authoritative data files outside of solr, etc...) and then use *any* Cache impl
class that you're heart desires, and things will still work right.
bq. After the new cache is regenerated, should I go through the new cache, grab
the frequency information from the old cache with each key, and fix the new
cache up?
you certainly could -- when {{(new HawtDbLFUCache(...)).warm(...)}} is called,
it needs to delegate to the regenerator for pulling values from the "old"
cache, but that doesn't mean it can't also directly ask the "old" cache
instance for stats about each of the old keys as it loops over them --
remember: the "new" cache is the one inspecting the "old" cache and deciding
what things to ask the regenerator to generate.
But i question whether you really want any sort of stats from the "old" cache
copied over to the "new" cache. it is, after all, a completely new cache --
with new usage. should the stats really be preserved forever? regardless of
how popular an object was in the "old" cache instance, should we automatically
assume it's equally popular in the "new" cache instance?
> Implement an optimized LFUCache
> ---
>
> Key: SOLR-3393
> URL: https://issues.apache.org/jira/browse/SOLR-3393
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 3.6, 4.0
>Reporter: Shawn Heisey
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-3393.patch, SOLR-3393.patch
>
>
> SOLR-2906 gave us an inefficient LFU cache modeled on
> FastLRUCache/ConcurrentLRUCache. It could use some serious improvement. The
> following project includes an Apache 2.0 licensed O(1) implementation. The
> second link is the paper (PDF warning) it was based on:
> https://github.com/chirino/hawtdb
> http://dhruvbird.com/lfu.pdf
> Using this project and paper, I will attempt to make a new O(1) cache called
> FastLFUCache that is modeled on LRUCache.java. This will (for now) leave the
> existing LFUCache/ConcurrentLFUCache implementation in place.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3407) Field names with leading digits cause strange behavior when used with "fl" param
[ https://issues.apache.org/jira/browse/SOLR-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261159#comment-13261159 ] Erick Erickson edited comment on SOLR-3407 at 4/25/12 12:09 AM: OK, but this means that perfectly valid schemas in 3.x do NOT work in trunk. Seems arbitrary and like a pettifogging change by arrogant devs. Sorry, but really this seems like an unnecessary change that serves no purpose. Just because it's documented does not excuse poor decisions. was (Author: erickerickson): OK, but this means that perfectly valid schemas in 3.x do NOT work in trunk. Seems arbitrary and like a pettifogging change by arrogant devs. Sorry, but really this seems like an unnecessary change that serves no purpose. Just because it's documents does not excuse poor decisions. > Field names with leading digits cause strange behavior when used with "fl" > param > > > Key: SOLR-3407 > URL: https://issues.apache.org/jira/browse/SOLR-3407 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0 > Environment: apache-solr-4.0-2012-04-24_08-27-47 >Reporter: Chris Bleakley > > When specifying a field name that starts with a digit (or digits) in the "fl" > parameter solr returns both the field name and field value as the those > digits. For example, using nightly build > "apache-solr-4.0-2012-04-24_08-27-47" I run: > java -jar start.jar > and > java -jar post.jar solr.xml monitor.xml > If I then add a field to the field list that starts with a digit ( > localhost:8983/solr/select?q=*:*&fl=24 ) the results look like: > ... > > 24 > > ... > if I try fl=24_7 it looks like everything after the underscore is truncated > ... > > 24 > > ... > and if I try fl=3test it looks like everything after the last digit is > truncated > ... > > 3 > > ... > If I have an actual value for that field (say I've indexed 24_7 to be "true" > ) I get back that value as well as the behavior above. > ... > > true > 24 > > ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3407) Field names with leading digits cause strange behavior when used with "fl" param
[ https://issues.apache.org/jira/browse/SOLR-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261159#comment-13261159 ] Erick Erickson edited comment on SOLR-3407 at 4/25/12 12:08 AM: OK, but this means that perfectly valid schemas in 3.x do NOT work in trunk. Seems arbitrary and like a pettifogging change by arrogant devs. Sorry, but really this seems like an unnecessary change that serves no purpose. Just because it's documents does not excuse poor decisions. was (Author: erickerickson): OK, but this means that perfectly valid schemas in 3.x do NOT work in trunk. Seems arbitrary and like a pettifogging change by arrogant devs. Sorry, but really this seems like an unnecessary change that serves no purpose. > Field names with leading digits cause strange behavior when used with "fl" > param > > > Key: SOLR-3407 > URL: https://issues.apache.org/jira/browse/SOLR-3407 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0 > Environment: apache-solr-4.0-2012-04-24_08-27-47 >Reporter: Chris Bleakley > > When specifying a field name that starts with a digit (or digits) in the "fl" > parameter solr returns both the field name and field value as the those > digits. For example, using nightly build > "apache-solr-4.0-2012-04-24_08-27-47" I run: > java -jar start.jar > and > java -jar post.jar solr.xml monitor.xml > If I then add a field to the field list that starts with a digit ( > localhost:8983/solr/select?q=*:*&fl=24 ) the results look like: > ... > > 24 > > ... > if I try fl=24_7 it looks like everything after the underscore is truncated > ... > > 24 > > ... > and if I try fl=3test it looks like everything after the last digit is > truncated > ... > > 3 > > ... > If I have an actual value for that field (say I've indexed 24_7 to be "true" > ) I get back that value as well as the behavior above. > ... > > true > 24 > > ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3407) Field names with leading digits cause strange behavior when used with "fl" param
[ https://issues.apache.org/jira/browse/SOLR-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261159#comment-13261159 ] Erick Erickson commented on SOLR-3407: -- OK, but this means that perfectly valid schemas in 3.x do NOT work in trunk. Seems arbitrary and like a pettifogging change by arrogant devs. Sorry, but really this seems like an unnecessary change that serves no purpose. > Field names with leading digits cause strange behavior when used with "fl" > param > > > Key: SOLR-3407 > URL: https://issues.apache.org/jira/browse/SOLR-3407 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0 > Environment: apache-solr-4.0-2012-04-24_08-27-47 >Reporter: Chris Bleakley > > When specifying a field name that starts with a digit (or digits) in the "fl" > parameter solr returns both the field name and field value as the those > digits. For example, using nightly build > "apache-solr-4.0-2012-04-24_08-27-47" I run: > java -jar start.jar > and > java -jar post.jar solr.xml monitor.xml > If I then add a field to the field list that starts with a digit ( > localhost:8983/solr/select?q=*:*&fl=24 ) the results look like: > ... > > 24 > > ... > if I try fl=24_7 it looks like everything after the underscore is truncated > ... > > 24 > > ... > and if I try fl=3test it looks like everything after the last digit is > truncated > ... > > 3 > > ... > If I have an actual value for that field (say I've indexed 24_7 to be "true" > ) I get back that value as well as the behavior above. > ... > > true > 24 > > ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3406) Support grouped range and query facets.
[
https://issues.apache.org/jira/browse/SOLR-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261140#comment-13261140
]
David commented on SOLR-3406:
-
{quote}
There are already collectors in the grouping module that compute a grouped
count for a query.
{quote}
Do you mean that this grouping is already functional on facet.query ?
> Support grouped range and query facets.
> ---
>
> Key: SOLR-3406
> URL: https://issues.apache.org/jira/browse/SOLR-3406
> Project: Solr
> Issue Type: New Feature
>Reporter: David
>Priority: Critical
> Fix For: 4.0
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> Need the ability to support grouped range and query facets. Grouped facet
> fields have already been implemented in SOLR-2898 but we still need the
> ability to compute grouped range and query facets.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4020) Tests may not be repeatable across different platforms/ JVMs due to different locale/ timezone being picked.
[
https://issues.apache.org/jira/browse/LUCENE-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261132#comment-13261132
]
Robert Muir commented on LUCENE-4020:
-
don't we need to also take care to still consume the same number of random bits
when these params are specified?
> Tests may not be repeatable across different platforms/ JVMs due to different
> locale/ timezone being picked.
>
>
> Key: LUCENE-4020
> URL: https://issues.apache.org/jira/browse/LUCENE-4020
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4020.diff
>
>
> This is because the source array can be/ is different for each system/ JVM.
> So this pick is not repeatable for example:
> {code}
> /**
>* Return a random Locale from the available locales on the system.
>*/
> public static Locale randomLocale(Random random) {
> Locale locales[] = Locale.getAvailableLocales();
> return locales[random.nextInt(locales.length)];
> }
> {code}
> I don't think there is much we can do to make it repeatable (other than maybe
> enforcing locale using system property).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261131#comment-13261131 ] Steven Rowe commented on SOLR-3405: --- bq. http://evgeny-goldin.com/wiki/Ivy-maven-plugin Licensed under Apache License v2.0: [https://github.com/evgeny-goldin/maven-plugins/blob/master/ivy-maven-plugin/src/main/resources/license.txt], so it could be forked if necessary. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261118#comment-13261118 ] Steven Rowe commented on SOLR-3405: --- Re: maven-antivirus-plugin - looks like it's already been built: http://evgeny-goldin.com/wiki/Ivy-maven-plugin > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261113#comment-13261113
]
Steven Rowe commented on SOLR-3405:
---
RE: maven-antivirus-plugin, as an experiment, I added the following to the
Lucene/Solr grandfather POM, and Maven (v2.2.1 & v3.0.4) didn't barf:
{code:xml}
http://example.org/maven-antivirus-plugin";
...>
...
http://example.com/somewhere/commons-csv-1.0-dev-r609327.jar
http://example.com/somewhere/commons-csv-1.0-dev-r609327.pom
...
{code}
So this is a syntactically valid way to shoehorn download links for such a
plugin into a POM.
> maven artifacts should be equivalent to binary packaging
>
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4020) Tests may not be repeatable across different platforms/ JVMs due to different locale/ timezone being picked.
[
https://issues.apache.org/jira/browse/LUCENE-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-4020:
Attachment: LUCENE-4020.diff
Ok, this time it's right.
> Tests may not be repeatable across different platforms/ JVMs due to different
> locale/ timezone being picked.
>
>
> Key: LUCENE-4020
> URL: https://issues.apache.org/jira/browse/LUCENE-4020
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 4.0
>
> Attachments: LUCENE-4020.diff
>
>
> This is because the source array can be/ is different for each system/ JVM.
> So this pick is not repeatable for example:
> {code}
> /**
>* Return a random Locale from the available locales on the system.
>*/
> public static Locale randomLocale(Random random) {
> Locale locales[] = Locale.getAvailableLocales();
> return locales[random.nextInt(locales.length)];
> }
> {code}
> I don't think there is much we can do to make it repeatable (other than maybe
> enforcing locale using system property).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4020) Tests may not be repeatable across different platforms/ JVMs due to different locale/ timezone being picked.
[
https://issues.apache.org/jira/browse/LUCENE-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261101#comment-13261101
]
Dawid Weiss commented on LUCENE-4020:
-
Oops, sorry, wrong thinking. It has to be the actual Locale, not the passed
property.
> Tests may not be repeatable across different platforms/ JVMs due to different
> locale/ timezone being picked.
>
>
> Key: LUCENE-4020
> URL: https://issues.apache.org/jira/browse/LUCENE-4020
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 4.0
>
>
> This is because the source array can be/ is different for each system/ JVM.
> So this pick is not repeatable for example:
> {code}
> /**
>* Return a random Locale from the available locales on the system.
>*/
> public static Locale randomLocale(Random random) {
> Locale locales[] = Locale.getAvailableLocales();
> return locales[random.nextInt(locales.length)];
> }
> {code}
> I don't think there is much we can do to make it repeatable (other than maybe
> enforcing locale using system property).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4020) Tests may not be repeatable across different platforms/ JVMs due to different locale/ timezone being picked.
[
https://issues.apache.org/jira/browse/LUCENE-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-4020:
Attachment: LUCENE-4020.diff
Suggested patch.
> Tests may not be repeatable across different platforms/ JVMs due to different
> locale/ timezone being picked.
>
>
> Key: LUCENE-4020
> URL: https://issues.apache.org/jira/browse/LUCENE-4020
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 4.0
>
>
> This is because the source array can be/ is different for each system/ JVM.
> So this pick is not repeatable for example:
> {code}
> /**
>* Return a random Locale from the available locales on the system.
>*/
> public static Locale randomLocale(Random random) {
> Locale locales[] = Locale.getAvailableLocales();
> return locales[random.nextInt(locales.length)];
> }
> {code}
> I don't think there is much we can do to make it repeatable (other than maybe
> enforcing locale using system property).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4020) Tests may not be repeatable across different platforms/ JVMs due to different locale/ timezone being picked.
[
https://issues.apache.org/jira/browse/LUCENE-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-4020:
Attachment: (was: LUCENE-4020.diff)
> Tests may not be repeatable across different platforms/ JVMs due to different
> locale/ timezone being picked.
>
>
> Key: LUCENE-4020
> URL: https://issues.apache.org/jira/browse/LUCENE-4020
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 4.0
>
>
> This is because the source array can be/ is different for each system/ JVM.
> So this pick is not repeatable for example:
> {code}
> /**
>* Return a random Locale from the available locales on the system.
>*/
> public static Locale randomLocale(Random random) {
> Locale locales[] = Locale.getAvailableLocales();
> return locales[random.nextInt(locales.length)];
> }
> {code}
> I don't think there is much we can do to make it repeatable (other than maybe
> enforcing locale using system property).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 - Failure
: > so we just changed the test to only test that the objects returned have
: > hte same rules.
:
: I think the test is better now because I don't think there is a
: guarantee all TimeZone implementations (and there is more than one...)
: need a consistent equals(). Who knows what else was lurking in there.
maybe not, but the fucking ID is suppose to always be normalized...
>>> When creating a TimeZone, the specified custom time zone ID is
>>> normalized in the following syntax: ... For example,
>>> TimeZone.getTimeZone("GMT-8").getID() returns "GMT-08:00". "
...which is fucking broken in the JVMs jenkins runs.
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3393) Implement an optimized LFUCache
[ https://issues.apache.org/jira/browse/SOLR-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261098#comment-13261098 ] Shawn Heisey commented on SOLR-3393: Further work, but no patch yet because it requires a bunch of test tweaks: I have split timeDecay into evictDecay and warmDecay. The timeDecay option still works, and sets both to true. In the absence of the timeDecay option, I've made evictDecay default to false and warmDecay default to true. In order to cause elements to decay over time, every entry in the cache must be removed from one LinkedHashSet and added to another. This is probably pretty fast for this implementation, but it does still require time. My use case scenario will have commits relatively often, up to once a minute. For me, doing the decay at warm time is enough, and results in fewer items to touch. To have it happen at eviction time is overhead I don't need, but it would be correct for some use cases. What are some other people's opinions about the default settings? > Implement an optimized LFUCache > --- > > Key: SOLR-3393 > URL: https://issues.apache.org/jira/browse/SOLR-3393 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 3.6, 4.0 >Reporter: Shawn Heisey >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3393.patch, SOLR-3393.patch > > > SOLR-2906 gave us an inefficient LFU cache modeled on > FastLRUCache/ConcurrentLRUCache. It could use some serious improvement. The > following project includes an Apache 2.0 licensed O(1) implementation. The > second link is the paper (PDF warning) it was based on: > https://github.com/chirino/hawtdb > http://dhruvbird.com/lfu.pdf > Using this project and paper, I will attempt to make a new O(1) cache called > FastLFUCache that is modeled on LRUCache.java. This will (for now) leave the > existing LFUCache/ConcurrentLFUCache implementation in place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 - Failure
: Since the last openjdk6,7 ports upgrades, the timezones update may
: change with every single FreeBSD update, because JDK timezone files are
: now a separate package shared across all ports. So it does not depend on
: the JDK version. Die to a bug in the openjdk port this is disabled for
: openjdk6 at the moment, but will come back!
again: the data in the tzdata file should have no barring on this
particular test failures, because the failure has nothing to do with
lookups of "available ids" -- the failure came from asking for a "custom
id" in which case only the GMT offset should matter -- but two successive
calls to TimeZone.getTimeZone("GMT-00") were returning objects which were
not .equals() because the "getId()" returned a diff string for each
("GMT-00:00" in one and "GMT+00:00" in the other) even though the TImeZone
class javadocs say that hte ID will always be normalized)
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 - Failure
> the bottom line with that test is that on that machine, sometimes asking > for "GMT-00" would return a diff object then asking for "GMT-00" again 2 > ms later -- same "rules" for the object, but a different String "id" value Yes, a different ID, I noticed. It's strange. > so we just changed the test to only test that the objects returned have > hte same rules. I think the test is better now because I don't think there is a guarantee all TimeZone implementations (and there is more than one...) need a consistent equals(). Who knows what else was lurking in there. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 - Failure
: I think the problem with repeatability here may be this, Chris: : https://issues.apache.org/jira/browse/LUCENE-4020 I agree that LUCENE-4020 is a problem, but honestly i don't think it has anything to do with this particular bug -- the test never picks a random timezone from the list of available timezones, it generates random "custom id" strings (of the GMT+/-\d+ format) and asks TimeZone for it. : Enforcing these on my machine still didn't result in that original : error though. I tried on Jenkins though (with the same original JVM) : and: Exactly. the bottom line with that test is that on that machine, sometimes asking for "GMT-00" would return a diff object then asking for "GMT-00" again 2 ms later -- same "rules" for the object, but a different String "id" value (even though the javadocs say the ID values will always be normalized) so we just changed the test to only test that the objects returned have hte same rules. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 - Failure
I think the locale/ timezone used should be simply dumped as part of
repeat string. That array we pick from doesn't need to be sorted, it
can contain different entries depending on the JVM, etc.
D.
On Wed, Apr 25, 2012 at 12:26 AM, Uwe Schindler wrote:
> Hi,
>
> Since the last openjdk6,7 ports upgrades, the timezones update may change
> with every single FreeBSD update, because JDK timezone files are now a
> separate package shared across all ports. So it does not depend on the JDK
> version. Die to a bug in the openjdk port this is disabled for openjdk6 at
> the moment, but will come back!
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of
>> Dawid Weiss
>> Sent: Wednesday, April 25, 2012 12:22 AM
>> To: dev@lucene.apache.org
>> Subject: Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 -
>> Failure
>>
>> I think the problem with repeatability here may be this, Chris:
>> https://issues.apache.org/jira/browse/LUCENE-4020
>>
>> The log on Jenkins for this seed says:
>>
>> NOTE: test params are: codec=Lucene40: {},
>> sim=RandomSimilarityProvider(queryNorm=false,coord=false): {},
>> locale=th_TH_TH_#u-nu-thai, timezone=Asia/Karachi
>>
>> and on my machine:
>>
>> NOTE: test params are: codec=Lucene40: {},
>> sim=RandomSimilarityProvider(queryNorm=false,coord=false): {},
>> locale=zh_CN, timezone=Australia/Yancowinna
>>
>> Enforcing these on my machine still didn't result in that original error
>> though. I
>> tried on Jenkins though (with the same original JVM)
>> and:
>>
>> ant test-core -Dtests.class=*.TimeZoneUtilsTest -Dtests.method=testRandom -
>> Dtests.seed=A928CC75CAAEE111
>> -Dtests.multiplier=3 -Dargs="-Dfile.encoding=US-ASCII"
>> -Dtests.locale=th_TH_TH#u-nu-thai -Dtests.timezone=Asia/Karachi
>>
>> sure does reproduce every single time...
>>
>> Dawid
>>
>> On Tue, Apr 24, 2012 at 7:46 PM, Chris Hostetter
>> wrote:
>> >
>> > : FWIW: I can not reproduce this using hte specified seed...
>> >
>> > Even when i added explicit checks for the input that the test
>> > complained about ("GMT-00") i still can't reproduce ... but i'm using
>> > Java6 and i don't have Java7.
>> >
>> > I double checked the code, and i seriously don't understand how this
>> > failure could happen -- unless multiple calls to
>> > TimeZone.getTimeZone("GMT-00") return diff objects. Â (the only diff
>> > between the expected and actual code paths are that in the "actual"
>> > path, the helper method can return null instead of calling
>> > TimeZone.getTimeZone if the input string doesn't match some rules.
>> >
>> > Can anybody reproduce this failure?
>> >
>> > you shouldn't even need to trust the seed, just run the entire
>> > TimeZoneUtilsTest class with the changes to "testCustom" i just
>> > committed that explicitly test "GMT-00"
>> >
>> > : ant test -Dtests.class=*.TimeZoneUtilsTest -Dtests.method=testRandom -
>> Dtests.seed=A928CC75CAAEE111 -Dtests.multiplier=3 -Dargs="-
>> Dfile.encoding=US-ASCII"
>> > :
>> > : And the same test passed on the latest trunk (non java7) jenkins build...
>> > :
>> > : https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13455/
>> >
>> > -Hoss
>> >
>> > -
>> > 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
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 - Failure
Hi,
Since the last openjdk6,7 ports upgrades, the timezones update may change with
every single FreeBSD update, because JDK timezone files are now a separate
package shared across all ports. So it does not depend on the JDK version. Die
to a bug in the openjdk port this is disabled for openjdk6 at the moment, but
will come back!
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of
> Dawid Weiss
> Sent: Wednesday, April 25, 2012 12:22 AM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 -
> Failure
>
> I think the problem with repeatability here may be this, Chris:
> https://issues.apache.org/jira/browse/LUCENE-4020
>
> The log on Jenkins for this seed says:
>
> NOTE: test params are: codec=Lucene40: {},
> sim=RandomSimilarityProvider(queryNorm=false,coord=false): {},
> locale=th_TH_TH_#u-nu-thai, timezone=Asia/Karachi
>
> and on my machine:
>
> NOTE: test params are: codec=Lucene40: {},
> sim=RandomSimilarityProvider(queryNorm=false,coord=false): {},
> locale=zh_CN, timezone=Australia/Yancowinna
>
> Enforcing these on my machine still didn't result in that original error
> though. I
> tried on Jenkins though (with the same original JVM)
> and:
>
> ant test-core -Dtests.class=*.TimeZoneUtilsTest -Dtests.method=testRandom -
> Dtests.seed=A928CC75CAAEE111
> -Dtests.multiplier=3 -Dargs="-Dfile.encoding=US-ASCII"
> -Dtests.locale=th_TH_TH#u-nu-thai -Dtests.timezone=Asia/Karachi
>
> sure does reproduce every single time...
>
> Dawid
>
> On Tue, Apr 24, 2012 at 7:46 PM, Chris Hostetter
> wrote:
> >
> > : FWIW: I can not reproduce this using hte specified seed...
> >
> > Even when i added explicit checks for the input that the test
> > complained about ("GMT-00") i still can't reproduce ... but i'm using
> > Java6 and i don't have Java7.
> >
> > I double checked the code, and i seriously don't understand how this
> > failure could happen -- unless multiple calls to
> > TimeZone.getTimeZone("GMT-00") return diff objects. (the only diff
> > between the expected and actual code paths are that in the "actual"
> > path, the helper method can return null instead of calling
> > TimeZone.getTimeZone if the input string doesn't match some rules.
> >
> > Can anybody reproduce this failure?
> >
> > you shouldn't even need to trust the seed, just run the entire
> > TimeZoneUtilsTest class with the changes to "testCustom" i just
> > committed that explicitly test "GMT-00"
> >
> > : ant test -Dtests.class=*.TimeZoneUtilsTest -Dtests.method=testRandom -
> Dtests.seed=A928CC75CAAEE111 -Dtests.multiplier=3 -Dargs="-
> Dfile.encoding=US-ASCII"
> > :
> > : And the same test passed on the latest trunk (non java7) jenkins build...
> > :
> > : https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13455/
> >
> > -Hoss
> >
> > -
> > 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: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 - Failure
I think the problem with repeatability here may be this, Chris:
https://issues.apache.org/jira/browse/LUCENE-4020
The log on Jenkins for this seed says:
NOTE: test params are: codec=Lucene40: {},
sim=RandomSimilarityProvider(queryNorm=false,coord=false): {},
locale=th_TH_TH_#u-nu-thai, timezone=Asia/Karachi
and on my machine:
NOTE: test params are: codec=Lucene40: {},
sim=RandomSimilarityProvider(queryNorm=false,coord=false): {},
locale=zh_CN, timezone=Australia/Yancowinna
Enforcing these on my machine still didn't result in that original
error though. I tried on Jenkins though (with the same original JVM)
and:
ant test-core -Dtests.class=*.TimeZoneUtilsTest
-Dtests.method=testRandom -Dtests.seed=A928CC75CAAEE111
-Dtests.multiplier=3 -Dargs="-Dfile.encoding=US-ASCII"
-Dtests.locale=th_TH_TH#u-nu-thai -Dtests.timezone=Asia/Karachi
sure does reproduce every single time...
Dawid
On Tue, Apr 24, 2012 at 7:46 PM, Chris Hostetter
wrote:
>
> : FWIW: I can not reproduce this using hte specified seed...
>
> Even when i added explicit checks for the input that the test complained
> about ("GMT-00") i still can't reproduce ... but i'm using Java6 and i
> don't have Java7.
>
> I double checked the code, and i seriously don't understand how this
> failure could happen -- unless multiple calls to
> TimeZone.getTimeZone("GMT-00") return diff objects. Â (the only diff
> between the expected and actual code paths are that in the "actual" path,
> the helper method can return null instead of calling TimeZone.getTimeZone
> if the input string doesn't match some rules.
>
> Can anybody reproduce this failure?
>
> you shouldn't even need to trust the seed, just run the entire
> TimeZoneUtilsTest class with the changes to "testCustom" i just committed
> that explicitly test "GMT-00"
>
> : ant test -Dtests.class=*.TimeZoneUtilsTest -Dtests.method=testRandom
> -Dtests.seed=A928CC75CAAEE111 -Dtests.multiplier=3
> -Dargs="-Dfile.encoding=US-ASCII"
> :
> : And the same test passed on the latest trunk (non java7) jenkins build...
> :
> : https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13455/
>
> -Hoss
>
> -
> 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: Spatial contrib bug fixing
Before we start, I almost forgot, we need to make sure that it can actually be ported into the project, according to ASF guidelines. I *think* it should be okay, because it's licensed under the Apache 2.0 license, but we should get some feedback from our mentors, on whether this is okay. Stefan, are there any problems with porting code from a non-apache project that is licensed under the Apache 2.0 license? On Tue, Apr 24, 2012 at 2:14 PM, Itamar Syn-Hershko wrote: > Great > > The actual library lives outside of Lucene ( > https://github.com/spatial4j/spatial4j ) and only some integration classes > are within the Lucene project itself. I linked to the (long) discussions > about this in my previous message. I will be following that approach with > this port, and really hope there will be no API differences I won't be able > to overcome. > > I'm going to start doing this sometime tomorrow, but my main efforts will > be on Thursday. I can certainly use any help in dividing work etc - please > anyone who can join on Thursday for live collaboration or later chip in the > discussion. > > I'll keep you posted. > > On Wed, Apr 25, 2012 at 12:00 AM, Christopher Currens < > currens.ch...@gmail.com> wrote: > > > Yes, the contrib is a MESS. I've been favoring complete > re-implementations > > over porting changes, since contrib has been in such a poor, overlooked > > state for so long. > > > > I'm not opposed to porting LSP over the Spatial contrib project in Java, > > though it will might some porting challenges both now, since Lucene > > versions are different, and as Lucene.NET evolves. It also might not, > I'm > > not familiar with the LSP code. Contrib is just that, contributed > software > > that is not part of the core library, and there will be projects in Java > we > > can't port over. In fact, I think there are .NET specific contrib > projects > > that aren't in java. Either way, my point is that I'm am happy and > willing > > to have LSP included if that's going to wind up being better than > Spatial. > > I think we can use all the help and contributions we can get in > > Lucene.NET. > > > > Of course, we'd need to look and see what is possible, with porting over > > LSP (not sure if it relies on any version specific features that may not > > yet be in 3.0.3). So, I say let's go for it, and if you need any > help/want > > to divide work between other committers, we can arrange that, and create > > issues for it, that is, if the other committers don't object to this. > > > > On Tue, Apr 24, 2012 at 1:45 PM, Itamar Syn-Hershko > >wrote: > > > > > Thanks for your reply. > > > > > > > > > > Aside from the original port which had many divergences from java, > the > > > > only other issue applied to spatial is LUCENENET-431, which would be > > easy > > > > to include. > > > > > > > > > > > That is not correct. LUCENENET-431 was committed, but some fixed from > > Java > > > Lucene 3.0.3 are in as well. The whole thing is a mess. > > > > > > The reason for this mess is the amount of bugs in the original Java > > > implementation of Spatial. This is also why it has been deprecated in > > 3.6: > > > https://issues.apache.org/jira/browse/LUCENE-2599 > > > > > > I think the best route at this point is to port LSP aka Spatial4j to > .NET > > > and start using it as the Spatial module for Lucene.NET > > > https://issues.apache.org/jira/browse/LUCENE-3795 > > > > > > This is a Java Lucene 4 feature, but the current spatial implementation > > is > > > pretty unisable. > > > > > > I'm going to start looking into this, and would definitely appreciate > > your > > > input. > > > > > > Itamar. > > > > > >
[jira] [Commented] (LUCENE-4020) Tests may not be repeatable across different platforms/ JVMs due to different locale/ timezone being picked.
[
https://issues.apache.org/jira/browse/LUCENE-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261075#comment-13261075
]
Dawid Weiss commented on LUCENE-4020:
-
I think the "reproduce with" line should explicitly state the timezone and
locale picked for the test. Granted, certain combinations will be invalid on
other JVMs/ systems, but at least it's explicit what should be used?
> Tests may not be repeatable across different platforms/ JVMs due to different
> locale/ timezone being picked.
>
>
> Key: LUCENE-4020
> URL: https://issues.apache.org/jira/browse/LUCENE-4020
> Project: Lucene - Java
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 4.0
>
>
> This is because the source array can be/ is different for each system/ JVM.
> So this pick is not repeatable for example:
> {code}
> /**
>* Return a random Locale from the available locales on the system.
>*/
> public static Locale randomLocale(Random random) {
> Locale locales[] = Locale.getAvailableLocales();
> return locales[random.nextInt(locales.length)];
> }
> {code}
> I don't think there is much we can do to make it repeatable (other than maybe
> enforcing locale using system property).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4020) Tests may not be repeatable across different platforms/ JVMs due to different locale/ timezone being picked.
Dawid Weiss created LUCENE-4020:
---
Summary: Tests may not be repeatable across different platforms/
JVMs due to different locale/ timezone being picked.
Key: LUCENE-4020
URL: https://issues.apache.org/jira/browse/LUCENE-4020
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Minor
Fix For: 4.0
This is because the source array can be/ is different for each system/ JVM. So
this pick is not repeatable for example:
{code}
/**
* Return a random Locale from the available locales on the system.
*/
public static Locale randomLocale(Random random) {
Locale locales[] = Locale.getAvailableLocales();
return locales[random.nextInt(locales.length)];
}
{code}
I don't think there is much we can do to make it repeatable (other than maybe
enforcing locale using system property).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2605) CoreAdminHandler, different Output while 'defaultCoreName' is specified
[
https://issues.apache.org/jira/browse/SOLR-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-2605.
Resolution: Fixed
Assignee: Hoss Man
Committed revision 1330028.
> CoreAdminHandler, different Output while 'defaultCoreName' is specified
> ---
>
> Key: SOLR-2605
> URL: https://issues.apache.org/jira/browse/SOLR-2605
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: Stefan Matheis (steffkes)
>Assignee: Hoss Man
>Priority: Minor
> Fix For: 4.0
>
> Attachments: SOLR-2399-admin-cores-default.xml,
> SOLR-2399-admin-cores.xml, SOLR-2605.patch, SOLR-2605.patch
>
>
> The attached XML-Files show the little difference between a defined
> {{defaultCoreName}}-Attribute and a non existing one.
> Actually the new admin ui checks for an core with empty name to set single- /
> multicore-settings .. it's a quick change to count the number of defined
> cores instead.
> But, will it be possible, to get the core-name (again)? One of both
> attributes would be enough, if that makes a difference :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4016) Check if all the packaging/ development tasks work with latest Ant 1.8.x and switch to ant 1.8.x as the "officially supported" build platform.
[
https://issues.apache.org/jira/browse/LUCENE-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261052#comment-13261052
]
Dawid Weiss commented on LUCENE-4016:
-
I'll check Ubuntu tomorrow. If anybody wants to give Mac a try, go ahead. I
don't think there will be any differences, really -- if it passed without any
glitches on my Windows machine I don't expect any problems on other platforms
(typically it's windows that causes problems).
> Check if all the packaging/ development tasks work with latest Ant 1.8.x and
> switch to ant 1.8.x as the "officially supported" build platform.
> --
>
> Key: LUCENE-4016
> URL: https://issues.apache.org/jira/browse/LUCENE-4016
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Diff the outputs between ant 1.8.2 and ant 1.7.1.
> {noformat}
> Target Windows UbuntuMac Jenkins
>
> /
> ivy-bootstrap OK ? ? ?
> jar-checksums OK ? ? ?
> validate OK ? ? ?
> test OK ? ? ?
> lucene/
> prepare-relea* OK ? ? ?
> solr/
> prepare-relea* OK ? ? ?
> {noformat}
> Check consistency with release instructions:
> http://wiki.apache.org/lucene-java/ReleaseTodo and
> http://wiki.apache.org/solr/HowToRelease
> Differences log:
> - ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
> so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and
> is the expected behavior.
> - manifest timestamps are slightly different (Created-By - jvm version is
> formatted differently, I think more human-friendly in 1.8).
> {noformat}
> 1.7: Created-By: 22.1-b02 (Oracle Corporation)
> 1.8: Created-By: 1.7.0_03-b05 (Oracle Corporation)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261043#comment-13261043
]
Steven Rowe commented on SOLR-3405:
---
bq. If you want to avoid jars in svn, you'll need my download idea
Not really - just use {{ant resolve}} prior to running the maven build.
> maven artifacts should be equivalent to binary packaging
>
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261040#comment-13261040 ] Steven Rowe commented on SOLR-3405: --- bq. Would it really be so bad if someone adds a maven plugin that can just download a jar file from any http location? I could call it 'maven-antivirus-plugin'? +1 > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3406) Support grouped range and query facets.
[
https://issues.apache.org/jira/browse/SOLR-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261038#comment-13261038
]
David commented on SOLR-3406:
-
{quote}
Yes I am using group.truncate since facet.query doesn't have grouping
functionality yet.
{quote}
We could start on grouped facet queries since this really is my main priority.
Do you use IRC or any other type of IM software to communicate? Might make
development easier.
> Support grouped range and query facets.
> ---
>
> Key: SOLR-3406
> URL: https://issues.apache.org/jira/browse/SOLR-3406
> Project: Solr
> Issue Type: New Feature
>Reporter: David
>Priority: Critical
> Fix For: 4.0
>
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> Need the ability to support grouped range and query facets. Grouped facet
> fields have already been implemented in SOLR-2898 but we still need the
> ability to compute grouped range and query facets.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3407) Field names with leading digits cause strange behavior when used with "fl" param
[
https://issues.apache.org/jira/browse/SOLR-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261037#comment-13261037
]
Yonik Seeley commented on SOLR-3407:
See the comment in the schema.xml:
{code}
{code}
> Field names with leading digits cause strange behavior when used with "fl"
> param
>
>
> Key: SOLR-3407
> URL: https://issues.apache.org/jira/browse/SOLR-3407
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.0
> Environment: apache-solr-4.0-2012-04-24_08-27-47
>Reporter: Chris Bleakley
>
> When specifying a field name that starts with a digit (or digits) in the "fl"
> parameter solr returns both the field name and field value as the those
> digits. For example, using nightly build
> "apache-solr-4.0-2012-04-24_08-27-47" I run:
> java -jar start.jar
> and
> java -jar post.jar solr.xml monitor.xml
> If I then add a field to the field list that starts with a digit (
> localhost:8983/solr/select?q=*:*&fl=24 ) the results look like:
> ...
>
> 24
>
> ...
> if I try fl=24_7 it looks like everything after the underscore is truncated
> ...
>
> 24
>
> ...
> and if I try fl=3test it looks like everything after the last digit is
> truncated
> ...
>
> 3
>
> ...
> If I have an actual value for that field (say I've indexed 24_7 to be "true"
> ) I get back that value as well as the behavior above.
> ...
>
> true
> 24
>
> ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261032#comment-13261032 ] Benson Margulies commented on SOLR-3405: There is some work to do before you can 'commit today and release tomorrow.' Steve didn't claim to the contrary and neither did I. It's not a ton of work, and it's not complex. If you want to avoid jars in svn, you'll need my download idea, if you don't mind jars in svn (and I've lost track of the Apache politics rules of those, then you just reactivate the old scheme. if any of those jars are patched, my suggestion to avoid controversy is true > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261031#comment-13261031
]
Steven Rowe commented on SOLR-3405:
---
{quote}
So then i can commit my patch, and we could release tomorrow and maven should
work? great!
But i suspect this isnt the case, you are conflating the 'maven build' with
'maven artifacts' no?
{quote}
I am not conflating the two; as Benson mentioned, marking those non-mavenized
dependencies as optional in the POMs of modules that need them would allow
"maven artifacts" on Maven Central to be useable.
The mode of use, however, would be:
* checkout the tagged release, including dev-tools, from subversion (or maybe
from git instead?)
* run {{ant get-maven-poms resolve ; mvn -N -Pbootstrap install}} in order to
put the non-mavenized jars in one's local maven repository
* add *optional* dependencies, using Benson's
"groupId-invented/artifactId-invented" coordinates, to one's own project's POMs.
> maven artifacts should be equivalent to binary packaging
>
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3406) Support grouped range and query facets.
[ https://issues.apache.org/jira/browse/SOLR-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261030#comment-13261030 ] Martijn van Groningen commented on SOLR-3406: - bq. I just realized that computing stats on an ungrouped docset still wouldn't work since I still need to do query facets on price ranges. I don't follow this completely. If you use query or range facets this just should work, right? Or are you using group.facet or group.truncate in the same request? bq. Have you started on GroupedFacets? Nope. I created group facet collector in the Lucene grouping module which is used by Solr in the SimpleFacets. If I remember correctly both query facets and range facets in Solr are queries being executed on a top level searcher. For each queries a count is computed (based on the facet and main query result) and put in the response. For range facets multiple queries are executed based on the start, end and gap. I think grouped variant just needs to compute a grouped count for each query being executed. There are already collectors in the grouping module that compute a grouped count for a query. The only thing I'm worried about is caching. For each query or range facet a docset is computed and this stored in the filter cache and possible used for future requests. This docset is intersected with the docset matching with the main query, which result in the count being used in the response. We would need to do something similar. > Support grouped range and query facets. > --- > > Key: SOLR-3406 > URL: https://issues.apache.org/jira/browse/SOLR-3406 > Project: Solr > Issue Type: New Feature >Reporter: David >Priority: Critical > Fix For: 4.0 > > Original Estimate: 504h > Remaining Estimate: 504h > > Need the ability to support grouped range and query facets. Grouped facet > fields have already been implemented in SOLR-2898 but we still need the > ability to compute grouped range and query facets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3407) Field names with leading digits cause strange behavior when used with "fl" param
[ https://issues.apache.org/jira/browse/SOLR-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261024#comment-13261024 ] Erick Erickson commented on SOLR-3407: -- This does NOT happen on 3.6, but DOES happen on trunk. > Field names with leading digits cause strange behavior when used with "fl" > param > > > Key: SOLR-3407 > URL: https://issues.apache.org/jira/browse/SOLR-3407 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 4.0 > Environment: apache-solr-4.0-2012-04-24_08-27-47 >Reporter: Chris Bleakley > > When specifying a field name that starts with a digit (or digits) in the "fl" > parameter solr returns both the field name and field value as the those > digits. For example, using nightly build > "apache-solr-4.0-2012-04-24_08-27-47" I run: > java -jar start.jar > and > java -jar post.jar solr.xml monitor.xml > If I then add a field to the field list that starts with a digit ( > localhost:8983/solr/select?q=*:*&fl=24 ) the results look like: > ... > > 24 > > ... > if I try fl=24_7 it looks like everything after the underscore is truncated > ... > > 24 > > ... > and if I try fl=3test it looks like everything after the last digit is > truncated > ... > > 3 > > ... > If I have an actual value for that field (say I've indexed 24_7 to be "true" > ) I get back that value as well as the behavior above. > ... > > true > 24 > > ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2898) Support grouped faceting
[ https://issues.apache.org/jira/browse/SOLR-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261023#comment-13261023 ] David commented on SOLR-2898: - ok sounds good > Support grouped faceting > > > Key: SOLR-2898 > URL: https://issues.apache.org/jira/browse/SOLR-2898 > Project: Solr > Issue Type: New Feature >Reporter: Martijn van Groningen > Fix For: 4.0 > > Attachments: SOLR-2898.patch, SOLR-2898.patch, SOLR-2898.patch, > SOLR-2898.patch > > > Support grouped faceting. As described in LUCENE-3097 (matrix counts). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4016) Check if all the packaging/ development tasks work with latest Ant 1.8.x and switch to ant 1.8.x as the "officially supported" build platform.
[
https://issues.apache.org/jira/browse/LUCENE-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-4016:
Description:
Diff the outputs between ant 1.8.2 and ant 1.7.1.
{noformat}
Target Windows UbuntuMac Jenkins
/
ivy-bootstrap OK ? ? ?
jar-checksums OK ? ? ?
validate OK ? ? ?
test OK ? ? ?
lucene/
prepare-relea* OK ? ? ?
solr/
prepare-relea* OK ? ? ?
{noformat}
Check consistency with release instructions:
http://wiki.apache.org/lucene-java/ReleaseTodo and
http://wiki.apache.org/solr/HowToRelease
Differences log:
- ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and is
the expected behavior.
- manifest timestamps are slightly different (Created-By - jvm version is
formatted differently, I think more human-friendly in 1.8).
{noformat}
1.7: Created-By: 22.1-b02 (Oracle Corporation)
1.8: Created-By: 1.7.0_03-b05 (Oracle Corporation)
{noformat}
was:
Diff the outputs between ant 1.8.2 and ant 1.7.1.
{noformat}
Target Windows UbuntuMac Jenkins
/
ivy-bootstrap OK ? ? ?
jar-checksums OK ? ? ?
validate OK ? ? ?
test OK ? ? ?
lucene/
clover ? ? ? ?
prepare-relea* OK ? ? ?
solr/
clover ? ? ? ?
run-example ? ? ? ?
prepare-relea* ? ? ? ?
{noformat}
Check consistency with release instructions:
http://wiki.apache.org/lucene-java/ReleaseTodo and
http://wiki.apache.org/solr/HowToRelease
Differences log:
- ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and is
the expected behavior.
> Check if all the packaging/ development tasks work with latest Ant 1.8.x and
> switch to ant 1.8.x as the "officially supported" build platform.
> --
>
> Key: LUCENE-4016
> URL: https://issues.apache.org/jira/browse/LUCENE-4016
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Diff the outputs between ant 1.8.2 and ant 1.7.1.
> {noformat}
> Target Windows UbuntuMac Jenkins
>
> /
> ivy-bootstrap OK ? ? ?
> jar-checksums OK ? ? ?
> validate OK ? ? ?
> test OK ? ? ?
> lucene/
> prepare-relea* OK ? ? ?
> solr/
> prepare-relea* OK ? ? ?
> {noformat}
> Check consistency with release instructions:
> http://wiki.apache.org/lucene-java/ReleaseTodo and
> http://wiki.apache.org/solr/HowToRelease
> Differences log:
> - ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
> so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and
> is the expected behavior.
> - manifest timestamps are slightly different (Created-By - jvm version is
> formatted differently, I think more human-friendly in 1.8).
> {noformat}
> 1.7: Created-By: 22.1-b02 (Oracle Corporation)
> 1.8: Created-By: 1.7.0_03-b05 (Oracle Corporation)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2898) Support grouped faceting
[ https://issues.apache.org/jira/browse/SOLR-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261017#comment-13261017 ] Martijn van Groningen commented on SOLR-2898: - bq. At any rate I am new to Solr development. Do you think you could point me in the right direction or give me your vision of how you see this implementation happening. Sure. Lets do this in SOLR-3406 > Support grouped faceting > > > Key: SOLR-2898 > URL: https://issues.apache.org/jira/browse/SOLR-2898 > Project: Solr > Issue Type: New Feature >Reporter: Martijn van Groningen > Fix For: 4.0 > > Attachments: SOLR-2898.patch, SOLR-2898.patch, SOLR-2898.patch, > SOLR-2898.patch > > > Support grouped faceting. As described in LUCENE-3097 (matrix counts). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261016#comment-13261016 ] Robert Muir commented on SOLR-3405: --- So then i can commit my patch, and we could release tomorrow and maven should work? great! But i suspect this isnt the case, you are conflating the 'maven build' with 'maven artifacts' no? > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261012#comment-13261012
]
Steven Rowe commented on SOLR-3405:
---
{quote}
If noggit is out there on central, then the fix will be a trivial adjustment to
the template pom. If it's not, then my suggestion for a relatively painless
solution is
1) to add a CSV file to the top of the tree, where each line consists of:
URL,GROUP-ID-INVENTED,ARTIFACT-ID-INVENTED,VERSION
2) To add each one as a dependency to the corresponding pom with
true
3) implement code in the 'ant get-maven-poms' target to download them and run
maven install:install-file on them using the information in the CSV.
{quote}
Benson, the Maven build used to be able to deal with "non-Mavenized" 3rd party
jars, using a mechanism like you suggest (except that it pulled jars, &
optionally POMs, from the local file system instead of from a URL). That
capability was removed in preparation for the 3.6 release.
You can see what it used to look like [in r1298247 of the Lucene/Solr
grandfather
POM|http://svn.apache.org/viewvc/lucene/dev/trunk/dev-tools/maven/pom.xml.template?revision=1298192&view=markup#l601]
- it was a profile that listed all of the necessary jars to pull from {{lib/}}
directories and put into the local maven repository. Users were instructed to
invoke it prior to using the Maven build: {{mvn -N -Pbootstrap install}}.
Fixing this aspect would simply require putting that stuff back for
non-Mavenized jars. This is how the Maven build worked before the era of Fake
Maven Releases of Other People's Software (FMROOPS).
> maven artifacts should be equivalent to binary packaging
>
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4016) Check if all the packaging/ development tasks work with latest Ant 1.8.x and switch to ant 1.8.x as the "officially supported" build platform.
[
https://issues.apache.org/jira/browse/LUCENE-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261008#comment-13261008
]
Dawid Weiss commented on LUCENE-4016:
-
We misunderstood each other. These package-info.class files are generated for
package-info.java (which are a way to put annotations on a package). There are
three such files in Lucene (in spatial).
> Check if all the packaging/ development tasks work with latest Ant 1.8.x and
> switch to ant 1.8.x as the "officially supported" build platform.
> --
>
> Key: LUCENE-4016
> URL: https://issues.apache.org/jira/browse/LUCENE-4016
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Diff the outputs between ant 1.8.2 and ant 1.7.1.
> {noformat}
> Target Windows UbuntuMac Jenkins
>
> /
> ivy-bootstrap OK ? ? ?
> jar-checksums OK ? ? ?
> validate OK ? ? ?
> test OK ? ? ?
> lucene/
> clover ? ? ? ?
> prepare-relea* OK ? ? ?
> solr/
> clover ? ? ? ?
> run-example ? ? ? ?
> prepare-relea* ? ? ? ?
> {noformat}
> Check consistency with release instructions:
> http://wiki.apache.org/lucene-java/ReleaseTodo and
> http://wiki.apache.org/solr/HowToRelease
> Differences log:
> - ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
> so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and
> is the expected behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3407) Field names with leading digits cause strange behavior when used with "fl" param
Chris Bleakley created SOLR-3407: Summary: Field names with leading digits cause strange behavior when used with "fl" param Key: SOLR-3407 URL: https://issues.apache.org/jira/browse/SOLR-3407 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0 Environment: apache-solr-4.0-2012-04-24_08-27-47 Reporter: Chris Bleakley When specifying a field name that starts with a digit (or digits) in the "fl" parameter solr returns both the field name and field value as the those digits. For example, using nightly build "apache-solr-4.0-2012-04-24_08-27-47" I run: java -jar start.jar and java -jar post.jar solr.xml monitor.xml If I then add a field to the field list that starts with a digit ( localhost:8983/solr/select?q=*:*&fl=24 ) the results look like: ... 24 ... if I try fl=24_7 it looks like everything after the underscore is truncated ... 24 ... and if I try fl=3test it looks like everything after the last digit is truncated ... 3 ... If I have an actual value for that field (say I've indexed 24_7 to be "true" ) I get back that value as well as the behavior above. ... true 24 ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4016) Check if all the packaging/ development tasks work with latest Ant 1.8.x and switch to ant 1.8.x as the "officially supported" build platform.
[
https://issues.apache.org/jira/browse/LUCENE-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261003#comment-13261003
]
Robert Muir commented on LUCENE-4016:
-
So that means if i have a package, with only a package.html and no classes...
that its package.html is now visible?
I'm just trying to think about how my checker will cope :)
> Check if all the packaging/ development tasks work with latest Ant 1.8.x and
> switch to ant 1.8.x as the "officially supported" build platform.
> --
>
> Key: LUCENE-4016
> URL: https://issues.apache.org/jira/browse/LUCENE-4016
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Diff the outputs between ant 1.8.2 and ant 1.7.1.
> {noformat}
> Target Windows UbuntuMac Jenkins
>
> /
> ivy-bootstrap OK ? ? ?
> jar-checksums OK ? ? ?
> validate OK ? ? ?
> test OK ? ? ?
> lucene/
> clover ? ? ? ?
> prepare-relea* OK ? ? ?
> solr/
> clover ? ? ? ?
> run-example ? ? ? ?
> prepare-relea* ? ? ? ?
> {noformat}
> Check consistency with release instructions:
> http://wiki.apache.org/lucene-java/ReleaseTodo and
> http://wiki.apache.org/solr/HowToRelease
> Differences log:
> - ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
> so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and
> is the expected behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4016) Check if all the packaging/ development tasks work with latest Ant 1.8.x and switch to ant 1.8.x as the "officially supported" build platform.
[
https://issues.apache.org/jira/browse/LUCENE-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-4016:
Description:
Diff the outputs between ant 1.8.2 and ant 1.7.1.
{noformat}
Target Windows UbuntuMac Jenkins
/
ivy-bootstrap OK ? ? ?
jar-checksums OK ? ? ?
validate OK ? ? ?
test OK ? ? ?
lucene/
clover ? ? ? ?
prepare-relea* OK ? ? ?
solr/
clover ? ? ? ?
run-example ? ? ? ?
prepare-relea* ? ? ? ?
{noformat}
Check consistency with release instructions:
http://wiki.apache.org/lucene-java/ReleaseTodo and
http://wiki.apache.org/solr/HowToRelease
Differences log:
- ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and is
the expected behavior.
was:
Diff the outputs between ant 1.8.2 and ant 1.7.1.
{noformat}
Target Windows UbuntuMac Jenkins
/
ivy-bootstrap OK ? ? ?
jar-checksums OK ? ? ?
validate OK ? ? ?
test OK ? ? ?
lucene/
clover ? ? ? ?
documentation ? ? ? ?
javadocs? ? ? ?
package-tgz ? ? ? ?
package-zip ? ? ? ?
package-tgz-src ? ? ? ?
package-all-b* ? ? ? ?
solr/
clover ? ? ? ?
create-package ? ? ? ?
dist? ? ? ?
example ? ? ? ?
javadocs? ? ? ?
package-src-tgz ? ? ? ?
run-example ? ? ? ?
{noformat}
Check consistency with release instructions:
http://wiki.apache.org/lucene-java/ReleaseTodo and
http://wiki.apache.org/solr/HowToRelease
Differences log:
- ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and is
the expected behavior.
> Check if all the packaging/ development tasks work with latest Ant 1.8.x and
> switch to ant 1.8.x as the "officially supported" build platform.
> --
>
> Key: LUCENE-4016
> URL: https://issues.apache.org/jira/browse/LUCENE-4016
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Diff the outputs between ant 1.8.2 and ant 1.7.1.
> {noformat}
> Target Windows UbuntuMac Jenkins
>
> /
> ivy-bootstrap OK ? ? ?
> jar-checksums OK ? ? ?
> validate OK ? ? ?
> test OK ? ? ?
> lucene/
> clover ? ? ? ?
> prepare-relea* OK ? ? ?
> solr/
> clover ? ? ? ?
> run-example ? ? ? ?
> prepare-relea* ? ? ? ?
> {noformat}
> Check consistency with release instructions:
> http://wiki.apache.org/lucene-java/ReleaseTodo and
> http://wiki.apache.org/solr/HowToRelease
> Differences log:
> - ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
> so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and
> is the expected behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4016) Check if all the packaging/ development tasks work with latest Ant 1.8.x and switch to ant 1.8.x as the "officially supported" build platform.
[
https://issues.apache.org/jira/browse/LUCENE-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260996#comment-13260996
]
Dawid Weiss commented on LUCENE-4016:
-
I only see "package-info.class" generated for source files like
spatial\src\java\org\apache\lucene\spatial\package-info.java. This is generated
with Ant 1.8 but is not with Ant 1.7.
There are no other differences other than timestamps (builds executed at
different time).
> Check if all the packaging/ development tasks work with latest Ant 1.8.x and
> switch to ant 1.8.x as the "officially supported" build platform.
> --
>
> Key: LUCENE-4016
> URL: https://issues.apache.org/jira/browse/LUCENE-4016
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Diff the outputs between ant 1.8.2 and ant 1.7.1.
> {noformat}
> Target Windows UbuntuMac Jenkins
>
> /
> ivy-bootstrap OK ? ? ?
> jar-checksums OK ? ? ?
> validate OK ? ? ?
> test OK ? ? ?
> lucene/
> clover ? ? ? ?
> documentation ? ? ? ?
> javadocs? ? ? ?
> package-tgz ? ? ? ?
> package-zip ? ? ? ?
> package-tgz-src ? ? ? ?
> package-all-b* ? ? ? ?
> solr/
> clover ? ? ? ?
> create-package ? ? ? ?
> dist? ? ? ?
> example ? ? ? ?
> javadocs? ? ? ?
> package-src-tgz ? ? ? ?
> run-example ? ? ? ?
> {noformat}
> Check consistency with release instructions:
> http://wiki.apache.org/lucene-java/ReleaseTodo and
> http://wiki.apache.org/solr/HowToRelease
> Differences log:
> - ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
> so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and
> is the expected behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Spatial contrib bug fixing
Thanks for your reply. > Aside from the original port which had many divergences from java, the > only other issue applied to spatial is LUCENENET-431, which would be easy > to include. > > That is not correct. LUCENENET-431 was committed, but some fixed from Java Lucene 3.0.3 are in as well. The whole thing is a mess. The reason for this mess is the amount of bugs in the original Java implementation of Spatial. This is also why it has been deprecated in 3.6: https://issues.apache.org/jira/browse/LUCENE-2599 I think the best route at this point is to port LSP aka Spatial4j to .NET and start using it as the Spatial module for Lucene.NET https://issues.apache.org/jira/browse/LUCENE-3795 This is a Java Lucene 4 feature, but the current spatial implementation is pretty unisable. I'm going to start looking into this, and would definitely appreciate your input. Itamar.
[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260994#comment-13260994 ] Chris Russell commented on SOLR-2894: - I figured out the unit test. It's because facet_pivot is different from the other facet_blah in that it only comes back when you request pivots, whereas the others always come back. In Dan's patch he had facet_pivot coming back even when it was empty or not requested, and this did not match the behavior of pivots in a non-distributed setting. I am working on an update to my patch. > Implement distributed pivot faceting > > > Key: SOLR-2894 > URL: https://issues.apache.org/jira/browse/SOLR-2894 > Project: Solr > Issue Type: Improvement >Reporter: Erik Hatcher > Fix For: 4.0 > > Attachments: SOLR-2894.patch, distributed_pivot.patch > > > Following up on SOLR-792, pivot faceting currently only supports > undistributed mode. Distributed pivot faceting needs to be implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260892#comment-13260892
]
Robert Muir commented on SOLR-3405:
---
{quote}
Rob, my experience here is that you pose a very specific question (e.g. do war
files force public dependencies) and when I answer it, you switch the subject
to a different question. Not an illegitimate or uninteresting question, but a
different question.
{quote}
I agree its somewhat off-topic, I'm just trying to point out that these
'implementation-detail' jars have real costs and are not free. By maven
exposing them the way it does, it more than doubles the surface area of
responsibility of third party jars as compared to the binary packaging.
And by maven not being able to download jar files from anywhere except maven
itself, it really boxes you into a corner as far as managing dependencies.
Would it really be so bad if someone adds a maven plugin that can just download
a jar file from any http location? I could call it 'maven-antivirus-plugin'? :)
> maven artifacts should be equivalent to binary packaging
>
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260888#comment-13260888 ] Benson Margulies commented on SOLR-3405: Rob, my experience here is that you pose a very specific question (e.g. do _war_ files force public dependencies) and when I answer it, you switch the subject to a different question. Not an illegitimate or uninteresting question, but a different question. The instantaneous effect of committing that patch will be to break the convenience maven build until someone else does something else. If noggit is out there on central, then the fix will be a trivial adjustment to the template pom. If it's not, then my suggestion for a relatively painless solution is 1) to add a CSV file to the top of the tree, where each line consists of: URL,GROUP-ID-INVENTED,ARTIFACT-ID-INVENTED,VERSION 2) To add each one as a dependency to the corresponding pom with true 3) implement code in the 'ant get-maven-poms' target to download them and run maven install:install-file on them using the information in the CSV. If you all *want* one of these to be a non-optional dependency, then it's a job for someone to coax it onto central, probably via ossrh. That's work, but it doesn't have to happen in a hurry. The CXF file could be created by scraping the ivy files, but that seems a lot of work. Steve, of course, gets first dibs on solving the problem, and he might not like my proposal. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4016) Check if all the packaging/ development tasks work with latest Ant 1.8.x and switch to ant 1.8.x as the "officially supported" build platform.
[
https://issues.apache.org/jira/browse/LUCENE-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260889#comment-13260889
]
Robert Muir commented on LUCENE-4016:
-
{quote}
ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do so.
This is documented at http://ant.apache.org/manual/Tasks/javac.html and is the
expected behavior.
{quote}
What is the effect of this on javadocs? I intentionally added checks to flush
out 'secret' javadocs for packages that had no classes, because its a sign they
should really be in overview.html or restructured somehow
(http://svn.apache.org/viewvc?rev=1328844&view=rev). Will this break that?
I know, its funky how the check works, by *allowing* it
(includenosourcepackages="true"), we cause a javadocs warning
to occur as a side effect (versus silently discarding the documentation),
failing the build :)
> Check if all the packaging/ development tasks work with latest Ant 1.8.x and
> switch to ant 1.8.x as the "officially supported" build platform.
> --
>
> Key: LUCENE-4016
> URL: https://issues.apache.org/jira/browse/LUCENE-4016
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Diff the outputs between ant 1.8.2 and ant 1.7.1.
> {noformat}
> Target Windows UbuntuMac Jenkins
>
> /
> ivy-bootstrap OK ? ? ?
> jar-checksums OK ? ? ?
> validate OK ? ? ?
> test OK ? ? ?
> lucene/
> clover ? ? ? ?
> documentation ? ? ? ?
> javadocs? ? ? ?
> package-tgz ? ? ? ?
> package-zip ? ? ? ?
> package-tgz-src ? ? ? ?
> package-all-b* ? ? ? ?
> solr/
> clover ? ? ? ?
> create-package ? ? ? ?
> dist? ? ? ?
> example ? ? ? ?
> javadocs? ? ? ?
> package-src-tgz ? ? ? ?
> run-example ? ? ? ?
> {noformat}
> Check consistency with release instructions:
> http://wiki.apache.org/lucene-java/ReleaseTodo and
> http://wiki.apache.org/solr/HowToRelease
> Differences log:
> - ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
> so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and
> is the expected behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13461 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13461/ All tests passed Build Log (for compile errors): [...truncated 21720 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260885#comment-13260885 ] Robert Muir commented on SOLR-3405: --- The issue goes much deeper. The issue also involves taking responsibility for third party jars also being in maven. Is it a requirement, that if i commit a patch, that the dependency MUST be in maven? what if its not? What if i commit https://issues.apache.org/jira/secure/attachment/12521033/SOLR-3296_noggit.patch right now? How will maven work? If everyone wants to pretend that maven is totally ok here, then I'll go commit that patch and lets see! > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4016) Check if all the packaging/ development tasks work with latest Ant 1.8.x and switch to ant 1.8.x as the "officially supported" build platform.
[
https://issues.apache.org/jira/browse/LUCENE-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-4016:
Description:
Diff the outputs between ant 1.8.2 and ant 1.7.1.
{noformat}
Target Windows UbuntuMac Jenkins
/
ivy-bootstrap OK ? ? ?
jar-checksums OK ? ? ?
validate OK ? ? ?
test OK ? ? ?
lucene/
clover ? ? ? ?
documentation ? ? ? ?
javadocs? ? ? ?
package-tgz ? ? ? ?
package-zip ? ? ? ?
package-tgz-src ? ? ? ?
package-all-b* ? ? ? ?
solr/
clover ? ? ? ?
create-package ? ? ? ?
dist? ? ? ?
example ? ? ? ?
javadocs? ? ? ?
package-src-tgz ? ? ? ?
run-example ? ? ? ?
{noformat}
Check consistency with release instructions:
http://wiki.apache.org/lucene-java/ReleaseTodo and
http://wiki.apache.org/solr/HowToRelease
Differences log:
- ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and is
the expected behavior.
was:
Diff the output artifacts compared to what was produced by ant 1.7.
{noformat}
Target Windows UbuntuMac Jenkins
/
ivy-bootstrap ? ? ? ?
jar-checksums ? ? ? ?
javadocs? ? ? ?
validate? ? ? ?
test OK ? ? ?
lucene/
clover ? ? ? ?
documentation ? ? ? ?
javadocs? ? ? ?
package-tgz ? ? ? ?
package-zip ? ? ? ?
package-tgz-src ? ? ? ?
package-all-b* ? ? ? ?
solr/
clover ? ? ? ?
create-package ? ? ? ?
dist? ? ? ?
example ? ? ? ?
javadocs? ? ? ?
package-src-tgz ? ? ? ?
run-example ? ? ? ?
{noformat}
Check consistency with release instructions:
http://wiki.apache.org/lucene-java/ReleaseTodo and
http://wiki.apache.org/solr/HowToRelease
Differences log:
- ant 1.8.0 creates empty package-info.class where ant 1.7.x would fail to do
so. This is documented at http://ant.apache.org/manual/Tasks/javac.html
> Check if all the packaging/ development tasks work with latest Ant 1.8.x and
> switch to ant 1.8.x as the "officially supported" build platform.
> --
>
> Key: LUCENE-4016
> URL: https://issues.apache.org/jira/browse/LUCENE-4016
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Diff the outputs between ant 1.8.2 and ant 1.7.1.
> {noformat}
> Target Windows UbuntuMac Jenkins
>
> /
> ivy-bootstrap OK ? ? ?
> jar-checksums OK ? ? ?
> validate OK ? ? ?
> test OK ? ? ?
> lucene/
> clover ? ? ? ?
> documentation ? ? ? ?
> javadocs? ? ? ?
> package-tgz ? ? ? ?
> package-zip ? ? ? ?
> package-tgz-src ? ? ? ?
> package-all-b* ? ? ? ?
> solr/
> clover ? ? ? ?
> create-package ? ? ? ?
> dist? ? ? ?
> example ? ? ? ?
> javadocs? ? ? ?
> package-src-tgz ? ? ? ?
> run-example ? ? ? ?
> {noformat}
> Check consistency with release instructions:
> http://wiki.apache.org/lucene-java/ReleaseTodo and
> http://wiki.apache.org/solr/HowToRelease
> Differences log:
> - ant 1.8.x creates empty package-info.class where ant 1.7.x would fail to do
> so. This is documented at http://ant.apache.org/manual/Tasks/javac.html and
> i
[jira] [Issue Comment Edited] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260879#comment-13260879 ] Benson Margulies edited comment on SOLR-3405 at 4/24/12 7:44 PM: - Wait, who said "putting your war application in maven means we must expose it as if it were an API and take responsibility"? It's not true. It might be a default behavior of the maven-war-plugin in simple cases, but that's different. Anyway, to answer the previous question, no, of course I can't do that with the binary package. The issue here should *not* be the war file. If there's an issue, it's the dependency tree of solr-core as an ordinary dependency, and whether we want it to list (a) ordinary released versions of third party stuff, (b) patched versions of third party stuff, or (c) no versions of third party stuff. If you want (c), then true makes sense to me, as it allows Steve's maven build to work and leaves the dependency management for these things to the end user. Inconvenient but safe. was (Author: bmargulies): Wait, who said "putting your war application in maven means we must expose it as if it were an API and take responsibility"? It's not true. It might be a default behavior of the maven-war-plugin in simple cases, but that's different. Anyway, to answer the previous question, no, of course I can't do that with the binary package. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260879#comment-13260879 ] Benson Margulies commented on SOLR-3405: Wait, who said "putting your war application in maven means we must expose it as if it were an API and take responsibility"? It's not true. It might be a default behavior of the maven-war-plugin in simple cases, but that's different. Anyway, to answer the previous question, no, of course I can't do that with the binary package. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4016) Check if all the packaging/ development tasks work with latest Ant 1.8.x and switch to ant 1.8.x as the "officially supported" build platform.
[
https://issues.apache.org/jira/browse/LUCENE-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-4016:
Description:
Diff the output artifacts compared to what was produced by ant 1.7.
{noformat}
Target Windows UbuntuMac Jenkins
/
ivy-bootstrap ? ? ? ?
jar-checksums ? ? ? ?
javadocs? ? ? ?
validate? ? ? ?
test OK ? ? ?
lucene/
clover ? ? ? ?
documentation ? ? ? ?
javadocs? ? ? ?
package-tgz ? ? ? ?
package-zip ? ? ? ?
package-tgz-src ? ? ? ?
package-all-b* ? ? ? ?
solr/
clover ? ? ? ?
create-package ? ? ? ?
dist? ? ? ?
example ? ? ? ?
javadocs? ? ? ?
package-src-tgz ? ? ? ?
run-example ? ? ? ?
{noformat}
Check consistency with release instructions:
http://wiki.apache.org/lucene-java/ReleaseTodo and
http://wiki.apache.org/solr/HowToRelease
Differences log:
- ant 1.8.0 creates empty package-info.class where ant 1.7.x would fail to do
so. This is documented at http://ant.apache.org/manual/Tasks/javac.html
was:
Diff the output artifacts compared to what was produced by ant 1.7.
{noformat}
Target Windows UbuntuMac Jenkins
/
ivy-bootstrap ? ? ? ?
jar-checksums ? ? ? ?
javadocs? ? ? ?
validate? ? ? ?
test? ? ? ?
lucene/
clover ? ? ? ?
documentation ? ? ? ?
javadocs? ? ? ?
package-tgz ? ? ? ?
package-zip ? ? ? ?
package-tgz-src ? ? ? ?
package-all-b* ? ? ? ?
solr/
clover ? ? ? ?
create-package ? ? ? ?
dist? ? ? ?
example ? ? ? ?
javadocs? ? ? ?
package-src-tgz ? ? ? ?
run-example ? ? ? ?
{noformat}
Check consistency with release instructions:
http://wiki.apache.org/lucene-java/ReleaseTodo and
http://wiki.apache.org/solr/HowToRelease
> Check if all the packaging/ development tasks work with latest Ant 1.8.x and
> switch to ant 1.8.x as the "officially supported" build platform.
> --
>
> Key: LUCENE-4016
> URL: https://issues.apache.org/jira/browse/LUCENE-4016
> Project: Lucene - Java
> Issue Type: Task
> Components: general/build
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 4.0
>
>
> Diff the output artifacts compared to what was produced by ant 1.7.
> {noformat}
> Target Windows UbuntuMac Jenkins
>
> /
> ivy-bootstrap ? ? ? ?
> jar-checksums ? ? ? ?
> javadocs? ? ? ?
> validate? ? ? ?
> test OK ? ? ?
> lucene/
> clover ? ? ? ?
> documentation ? ? ? ?
> javadocs? ? ? ?
> package-tgz ? ? ? ?
> package-zip ? ? ? ?
> package-tgz-src ? ? ? ?
> package-all-b* ? ? ? ?
> solr/
> clover ? ? ? ?
> create-package ? ? ? ?
> dist? ? ? ?
> example ? ? ? ?
> javadocs? ? ? ?
> package-src-tgz ? ? ? ?
> run-example ? ? ? ?
> {noformat}
> Check consistency with release instructions:
> http://wiki.apache.org/lucene-java/ReleaseTodo and
> http://wiki.apache.org/solr/HowToRelease
> Differences log:
> - ant 1.8.0 creates empty package-info.class where ant 1.7.x would fail to do
> so. This is documented at http://ant.apache.org/manual/Tasks/javac.html
--
This message is automatically generated by JIRA.
If you think it was sent
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260878#comment-13260878 ] Steven Rowe commented on SOLR-3405: --- bq. Lets either drop maven artifacts for solr completely, or package maven artifacts like everything else to prevent problems like commons-csv in the future! Robert, the only difference between solr binary distribution and maven artifacts is the POMs, not the jars or the war. When you say "packaging" you imply that the Solr Maven artifacts "include" 3rd party jars. They don't. Their POMs say that those 3rd party jars are required via non-optional dependency declarations. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 13460 - Still Failing
: All tests passed javadoc typo ... fixed. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13460 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13460/ All tests passed Build Log (for compile errors): [...truncated 21722 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260866#comment-13260866 ] Robert Muir commented on SOLR-3405: --- The binary release simply doesn't include any third party libraries. its different packaging. I think for most people, if maven supporters had honestly said up front: _putting your war application in maven means we must expose it as if it were an API and take responsibility that also all its 100+ jars are also themselves in maven (even patched, renamed, etc)_ That nobody in their right mind would have agreed to this. Lets either drop maven artifacts for solr completely, or package maven artifacts like everything else to prevent problems like commons-csv in the future! > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260865#comment-13260865
]
Steven Rowe commented on SOLR-3405:
---
bq. there is no guava.jar in the binary package, nor any lucene jars.
In the 3.6.0 binary dist, there are lucene jars under
{{contrib/analysis-extras/lucene-libs/}}. Assuming the uima contrib follows
the same pattern, it too will have a {{lucene-libs/}} directory containing the
Lucene uima module's jar.
> maven artifacts should be equivalent to binary packaging
>
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260865#comment-13260865
]
Steven Rowe edited comment on SOLR-3405 at 4/24/12 7:27 PM:
bq. there is no guava.jar in the binary package, nor any lucene jars.
In the 3.6.0 binary dist, there are lucene jars under
{{contrib/analysis-extras/lucene-libs/}}. In the 4.0 release, assuming the
uima contrib follows the same pattern, it too will have a {{lucene-libs/}}
directory containing the Lucene uima module's jar.
was (Author: steve_rowe):
bq. there is no guava.jar in the binary package, nor any lucene jars.
In the 3.6.0 binary dist, there are lucene jars under
{{contrib/analysis-extras/lucene-libs/}}. Assuming the uima contrib follows
the same pattern, it too will have a {{lucene-libs/}} directory containing the
Lucene uima module's jar.
> maven artifacts should be equivalent to binary packaging
>
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260856#comment-13260856 ] Steven Rowe commented on SOLR-3405: --- bq. It can't be: we release solr as an application on lucene.apache.org, but separately/differently as an API over on sonatype.com I disagree. The official Solr binary distribution includes the API jars outside of the .war. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260844#comment-13260844 ] Robert Muir commented on SOLR-3405: --- Benson, but you cannot do this with the binary release right? surely not? there is no guava.jar in the binary package, nor any lucene jars. Like i said, the release should be the same. It can't be: we release solr as an application on lucene.apache.org, but separately/differently as an API over on sonatype.com > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260841#comment-13260841
]
Benson Margulies edited comment on SOLR-3405 at 4/24/12 7:08 PM:
-
It might be helpful to note the following: with 3.5.0, 3.6.0, and 4.0-SNAPSHOT,
I can create a Maven project with a dependency on solr-core, and have all the
necessaries show up to sucessfully use EmbeddedSolrServer. The result is:
{noformat}
[INFO] +- org.apache.solr:solr-core:jar:3.5.0:provided
[INFO] | +- org.apache.solr:solr-solrj:jar:3.5.0:provided
[INFO] | | \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:provided
[INFO] | +- org.apache.solr:solr-noggit:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-core:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-analyzers:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-highlighter:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-memory:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-misc:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-queries:jar:3.5.0:provided
[INFO] | | \- jakarta-regexp:jakarta-regexp:jar:1.4:provided
[INFO] | +- org.apache.lucene:lucene-spatial:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-spellchecker:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-grouping:jar:3.5.0:provided
[INFO] | +- org.apache.solr:solr-commons-csv:jar:3.5.0:provided
[INFO] | +- commons-codec:commons-codec:jar:1.5:provided
[INFO] | +- commons-fileupload:commons-fileupload:jar:1.2.1:provided
[INFO] | +- commons-httpclient:commons-httpclient:jar:3.1:provided
[INFO] | +- org.slf4j:jcl-over-slf4j:jar:1.6.3:provided
[INFO] | +- commons-io:commons-io:jar:1.4:provided
[INFO] | +- commons-lang:commons-lang:jar:2.4:provided
[INFO] | +- com.google.guava:guava:jar:r05:provided
[INFO] | \- javax.servlet:servlet-api:jar:2.4:provided
{noformat}
was (Author: bmargulies):
It might be helpful to note the following: with 3.5.0, 3.6.0, and
4.0-SNAPSHOT, I can create a Maven project with a dependency on solr-core, and
have all the necessaries show up to sucessfully use EmbeddedSolrServer. The
result is:
{noformat}
[INFO] | +- org.apache.solr:solr-solrj:jar:3.5.0:provided
[INFO] | | \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:provided
[INFO] | +- org.apache.solr:solr-noggit:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-core:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-analyzers:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-highlighter:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-memory:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-misc:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-queries:jar:3.5.0:provided
[INFO] | | \- jakarta-regexp:jakarta-regexp:jar:1.4:provided
[INFO] | +- org.apache.lucene:lucene-spatial:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-spellchecker:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-grouping:jar:3.5.0:provided
[INFO] | +- org.apache.solr:solr-commons-csv:jar:3.5.0:provided
[INFO] | +- commons-codec:commons-codec:jar:1.5:provided
[INFO] | +- commons-fileupload:commons-fileupload:jar:1.2.1:provided
[INFO] | +- commons-httpclient:commons-httpclient:jar:3.1:provided
[INFO] | +- org.slf4j:jcl-over-slf4j:jar:1.6.3:provided
[INFO] | +- commons-io:commons-io:jar:1.4:provided
[INFO] | +- commons-lang:commons-lang:jar:2.4:provided
[INFO] | +- com.google.guava:guava:jar:r05:provided
[INFO] | \- javax.servlet:servlet-api:jar:2.4:provided
{noformat}
> maven artifacts should be equivalent to binary packaging
>
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260840#comment-13260840 ] Ryan McKinley commented on SOLR-3405: - bq. it publishes it as if it were an _api_, not an application. solr-core.jar is an API (how would anyone write RequestHandlers,Components,etc,etc w/o it!) solr.war is an application > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[
https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260841#comment-13260841
]
Benson Margulies commented on SOLR-3405:
It might be helpful to note the following: with 3.5.0, 3.6.0, and 4.0-SNAPSHOT,
I can create a Maven project with a dependency on solr-core, and have all the
necessaries show up to sucessfully use EmbeddedSolrServer. The result is:
{noformat}
[INFO] | +- org.apache.solr:solr-solrj:jar:3.5.0:provided
[INFO] | | \- org.codehaus.woodstox:wstx-asl:jar:3.2.7:provided
[INFO] | +- org.apache.solr:solr-noggit:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-core:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-analyzers:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-highlighter:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-memory:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-misc:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-queries:jar:3.5.0:provided
[INFO] | | \- jakarta-regexp:jakarta-regexp:jar:1.4:provided
[INFO] | +- org.apache.lucene:lucene-spatial:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-spellchecker:jar:3.5.0:provided
[INFO] | +- org.apache.lucene:lucene-grouping:jar:3.5.0:provided
[INFO] | +- org.apache.solr:solr-commons-csv:jar:3.5.0:provided
[INFO] | +- commons-codec:commons-codec:jar:1.5:provided
[INFO] | +- commons-fileupload:commons-fileupload:jar:1.2.1:provided
[INFO] | +- commons-httpclient:commons-httpclient:jar:3.1:provided
[INFO] | +- org.slf4j:jcl-over-slf4j:jar:1.6.3:provided
[INFO] | +- commons-io:commons-io:jar:1.4:provided
[INFO] | +- commons-lang:commons-lang:jar:2.4:provided
[INFO] | +- com.google.guava:guava:jar:r05:provided
[INFO] | \- javax.servlet:servlet-api:jar:2.4:provided
{noformat}
> maven artifacts should be equivalent to binary packaging
>
>
> Key: SOLR-3405
> URL: https://issues.apache.org/jira/browse/SOLR-3405
> Project: Solr
> Issue Type: Task
> Components: Build
>Reporter: Robert Muir
> Fix For: 4.0
>
>
> Lets take the commons-csv scenario:
> * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar
> anywhere,
> in fact it contains no third party jars (the stuff present in solr/lib) at
> all.
> * binary distribution contains only the jars necessary for *solrj* and
> *contrib plugins*, and a solr.war
> I think the maven artifacts should match whats in the binary release (no
> third party jars
> inside the .war are "exposed", we just publish the .war itself). This exposes
> a lot less surface area.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2325 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2325/ 1 tests failed. REGRESSION: org.apache.solr.util.TimeZoneUtilsTest.testCustom Error Message: GMT-00 expected: but was: Stack Trace: java.lang.AssertionError: GMT-00 expected: but was: at __randomizedtesting.SeedInfo.seed([2E29A34B43595269:FCAFE2E510E3B678]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.apache.solr.util.TimeZoneUtilsTest.testCustom(TimeZoneUtilsTest.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1913) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:805) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:866) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:880) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:759) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:681) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:614) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:653) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:812) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:668) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:687) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:723) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:734) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:604) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:550) Build Log (for compile errors): [...truncated 8836 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260832#comment-13260832 ] Robert Muir commented on SOLR-3405: --- Well i think so, I mean the way maven publishes solr, it publishes it as if it were an _api_, not an application. But the binary release treats solr as an application. This is a big difference! Because of this we previously also published some war dependencies (commons-csv) also as _api_ in maven too. This is what got people all upset, but if you look at our binary package we don't ever package their stuff up this way. Releasing an application is easier. we don't care about dependencies (except that they are legal): just that our .war works. and if the .war also wants to be in maven, then it should declare no dependencies (it works by itself). > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260831#comment-13260831 ] Steven Rowe commented on SOLR-3405: --- bq. 2. with its "guts exposed" on maven hmm, by "guts exposed" you mean: the Solr Maven artifacts' POMs document their dependencies. Right? > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3393) Implement an optimized LFUCache
[ https://issues.apache.org/jira/browse/SOLR-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260828#comment-13260828 ] Shawn Heisey edited comment on SOLR-3393 at 4/24/12 6:59 PM: - New patch that does not touch SolrInfoMBeanTest. I figured out what FastLRUCache does to avoid failing this test and did the same. The getStatistics method now immediately returns an empty NamedList if the cache has not been initialized. This could be done for LRUCache as well. was (Author: elyograg): New patch that does not touch SolrInfoMBeanTest. I figured out what FastLRUCache does to avoid failing this test and did the same. The getStatistics method now immediately returns null if the cache has not been initialized. This could be done for LRUCache as well. > Implement an optimized LFUCache > --- > > Key: SOLR-3393 > URL: https://issues.apache.org/jira/browse/SOLR-3393 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 3.6, 4.0 >Reporter: Shawn Heisey >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3393.patch, SOLR-3393.patch > > > SOLR-2906 gave us an inefficient LFU cache modeled on > FastLRUCache/ConcurrentLRUCache. It could use some serious improvement. The > following project includes an Apache 2.0 licensed O(1) implementation. The > second link is the paper (PDF warning) it was based on: > https://github.com/chirino/hawtdb > http://dhruvbird.com/lfu.pdf > Using this project and paper, I will attempt to make a new O(1) cache called > FastLFUCache that is modeled on LRUCache.java. This will (for now) leave the > existing LFUCache/ConcurrentLFUCache implementation in place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3393) Implement an optimized LFUCache
[ https://issues.apache.org/jira/browse/SOLR-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-3393: --- Attachment: SOLR-3393.patch New patch that does not touch SolrInfoMBeanTest. I figured out what FastLRUCache does to avoid failing this test and did the same. The getStatistics method now immediately returns null if the cache has not been initialized. This could be done for LRUCache as well. > Implement an optimized LFUCache > --- > > Key: SOLR-3393 > URL: https://issues.apache.org/jira/browse/SOLR-3393 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 3.6, 4.0 >Reporter: Shawn Heisey >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3393.patch, SOLR-3393.patch > > > SOLR-2906 gave us an inefficient LFU cache modeled on > FastLRUCache/ConcurrentLRUCache. It could use some serious improvement. The > following project includes an Apache 2.0 licensed O(1) implementation. The > second link is the paper (PDF warning) it was based on: > https://github.com/chirino/hawtdb > http://dhruvbird.com/lfu.pdf > Using this project and paper, I will attempt to make a new O(1) cache called > FastLFUCache that is modeled on LRUCache.java. This will (for now) leave the > existing LFUCache/ConcurrentLFUCache implementation in place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260825#comment-13260825 ] Steven Rowe commented on SOLR-3405: --- bq. the fact that they are different I think is the worst. Stated another way: POMs for Solr jars/war published on Maven Central should never require (i.e., have a non-optional dependency on) a third party artifact if that third party dependency is not directly included in the binary package; the contents of the war don't count as "inclusion in the binary package". > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260819#comment-13260819 ] Robert Muir commented on SOLR-3405: --- Or just said another way, we are currently releasing solr two different ways as binary: 1. as an "app" (war file) in the .zip 2. with its "guts exposed" on maven we should be able to come to an agreement about what needs to be in the binary release, and how it will be packaged, whether solr is an application or not, etc. we have to. its absurd to be releasing it two completely different ways. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Spatial contrib bug fixing
Robert Chapman ported Spatial to Lucene.NET, shown here in this issue: https://issues.apache.org/jira/browse/LUCENENET-199. DIGY only committed the patch, and the only thing I've seen Prescott do was to modify/apply LUCENENET-431 to trunk from 2.9.4g. Spatial, along with the rest of Contrib, was barely touched since Lucene.NET was resurrected into the incubator. Most, if not all, of the code is the exact same as the patch contributed by Robert, which itself differed a decent amount from the java code, so much of the reasons why it wasn't an exact port are either lost, or the more likely case, never answered. As far as I'm concerned, I have no qualms with you rewriting the thing from scratch, if you wanted to pursue a more direct port from the java code. Aside from the original port which had many divergences from java, the only other issue applied to spatial is LUCENENET-431, which would be easy to include. Thanks, Christopher On Tue, Apr 24, 2012 at 10:31 AM, Itamar Syn-Hershko wrote: > Uhm.. I was referring to the .NET port, which I can see DIGY ported > > Nevermind I will get it from the original commit > > @Prescott any idea re " CartesianPolyFilterBuilder.GetBoxShape() is not an > exact port - do you remember why? "? > > On Tue, Apr 24, 2012 at 12:26 AM, Christopher Currens < > currens.ch...@gmail.com> wrote: > > > It's in a weird place. And for the 3.0.3 version, its easiest to find > the > > code in the tags, rather than branches. > > > > > > > http://svn.apache.org/viewvc/lucene/java/tags/lucene_3_0_3/contrib/misc/src/java/org/apache/lucene/misc/ > > > > > > On Mon, Apr 23, 2012 at 2:20 PM, Prescott Nasser > >wrote: > > > > > > > > I'm having trouble finding chained filter in the java lucene svn... > > > > > > http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/contrib/?pathrev=990167amIlooking > around in the wrong place? > > > > Date: Mon, 23 Apr 2012 11:19:51 +0300 > > > > Subject: Re: Spatial contrib bug fixing > > > > From: ita...@code972.com > > > > To: lucene-net-...@lucene.apache.org > > > > > > > > One more thing - what's the deal with ChainedFilter? I can see a > commit > > > by > > > > DIGY on 7/7/2011 but it seems to have been removed since? > > > > > > > > On Mon, Apr 23, 2012 at 11:06 AM, Itamar Syn-Hershko < > > ita...@code972.com > > > >wrote: > > > > > > > > > For starters - CartesianPolyFilterBuilder.GetBoxShape() is not an > > exact > > > > > port - do you remember why? > > > > > > > > > > Anyway, if it was never fully ported as you say maybe I'll just go > > > ahead > > > > > and complete that > > > > > > > > > > For your reference, here are 2 failing tests which pass in Java > > Lucene > > > > > (can send the java file) - > > > > > > > > > > > https://github.com/synhershko/lucene.net/commit/234da7eca7cb08be5a0c2a7375ffc3f4a03bfd92 > > > > > > > > > > > > > > > > > > > > On Mon, Apr 23, 2012 at 1:39 AM, Prescott Nasser < > > > geobmx...@hotmail.com>wrote: > > > > > > > > > >> > > > > >> I think that was a while ago, and I don't even recall if I fully > > > ported > > > > >> it or just put up the start. I had some other stuff to deal with > the > > > last > > > > >> few months, so my memory is a bit lacking. I'll review the code, > > > meanwhile > > > > >> ask whatever questions you have - lets get this fixed up. ~P > > > > >> > Date: Sun, 22 Apr 2012 22:10:27 +0300 > > > > >> > Subject: Spatial contrib bug fixing > > > > >> > From: ita...@code972.com > > > > >> > To: lucene-net-...@lucene.apache.org > > > > >> > > > > > >> > Hi all, > > > > >> > > > > > >> > We encountered several bugs with the Sparial contrb, and the > ones > > we > > > > >> tested > > > > >> > with Java Lucene worked there (with 2.9.4). There are about 3 > open > > > > >> tickets > > > > >> > in the Jira bug tracker on similar issues. > > > > >> > > > > > >> > I'm now sitting with the ultimate goal of fixing this once and > for > > > all, > > > > >> but > > > > >> > some code parts are commented out in favor of other not > > line-by-line > > > > >> port > > > > >> > of some implementations, without a comment giving reasons. I was > > > > >> wondering > > > > >> > if there's anyone who could answer a few questions there, > instead > > > of me > > > > >> > changing things back and forth? > > > > >> > > > > > >> > Git history (I use the Git mirror, yes) tells me Prescott Nasser > > is > > > > >> behind > > > > >> > porting this - maybe he will have the answers? > > > > >> > > > > > >> > Cheers, > > > > >> > > > > > >> > Itamar. > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > >
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260814#comment-13260814 ] Robert Muir commented on SOLR-3405: --- yeah: i mean we can look at this two ways: 1) that the solr binary package is broken by just shipping solr-core.jar without its dependnecies 2) that the maven package is over-reaching by needing to specify them. I think, more importantly than anything else (as mentioned on this issue title), that they should match. if its so important to use solr-core.jar (but not the war), we could add these dependencies to the binary release too. However we should think seriously about this: because we are talking about a lot of third party dependencies, a lot more to be responsible for, and trickier handling of patched dependencies. And i've never heard anyone complain about e.g. guava.jar not being in the binary package, ever. but maybe i'm missing something. I hope this makes sense: the fact that they are different I think is the worst. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13459 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13459/ 1 tests failed. REGRESSION: org.apache.solr.util.TimeZoneUtilsTest.testRandom Error Message: GMT-00 expected: but was: Stack Trace: java.lang.AssertionError: GMT-00 expected: but was: at __randomizedtesting.SeedInfo.seed([BABF40DF059A2EB3:C8F365D0B4FA98C0]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.apache.solr.util.TimeZoneUtilsTest.testRandom(TimeZoneUtilsTest.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1913) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:805) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:866) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:880) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:759) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:681) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:614) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:653) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:812) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:668) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:687) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:723) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:734) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:604) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:550) Build Log (for compile errors): [...truncated 7997 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3178) Versioning - optimistic locking
[
https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260579#comment-13260579
]
Per Steffensen edited comment on SOLR-3178 at 4/24/12 6:38 PM:
---
Find attached SOLR_3173_3178_3382_plus.patch which should fit on top of
revision 1327417.
Patch includes:
- All our code-changes done during the work with SOLR-3173, SOLR-3178 and
SOLR-3382. How it is supposed to work in more detail, is described on
http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics and is of
course also expressed in included tests.
- Also includes
-- Misc clean-up
--- E.g. removing constants redundant OVERWRITE = "overwrite" so that only
UpdateParams.OVERWRITE is left. You need very good arguments to ever use
different "names" for the same thing (overwrite) among XML, JSON, HTTP request
params etc, so it is kind of wrong to have the constant defined for each of
those.
-- "Unimportant changes" - e.g.
--- Corrected spelling errors
--- Removed unnecessary imports
Not implemented yet
- Error propagation for redistributed updates. That is, the responses from the
redistributed updates in DistributedUpdateProcessor using SolrCmdDistributor,
have to be collected an merged into a combined response from "this"
DistributedUpdateProcessor.
-- Both implementation and tests are missing.
- Tests verifying that updates using JSON and CSV requests as described on
http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics also works as
described. Especially transfer of partRefs in JSON and CSV requests.
- Tests verifying that semanticsMode "consistency" works as it is supposed to -
just like ClassicConsistencyHybridXXXTests tests this for
"classic-consistency-hybrid" semanticsMode and like ClassicUpdateSemanticsTest
shortly tests it when semanticsMode is explicitly set to "classic" ("classic"
is the default so this mode is already tested a lot using all the others tests
in the project)
Other stuff not done yet
- Add Apache 2.0 Licence to all new files
- Check correct indenting
- JavaDoc for public methods
was (Author: steff1193):
Find attached SOLR_3173_3178_3382_plus.patch which should fit on top of
revision 1327417.
Patch includes:
- All our code-changes done during the work with SOLR-3173, SOLR-3178 and
SOLR-3382. How it is supposed to work in more detail, is described on
http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics and is of
course also expressed in included tests.
- Also includes
-- Misc clean-up
--- E.g. removing constants redundant OVERWRITE = "overwrite" so that only
UpdateParams.OVERWRITE is left. You need very good arguments to ever use
different "names" for the same thing (overwrite) among XML, JSON, HTTP request
params etc, so it is kind of wrong to have the constant defined for each of
those.
-- "Unimportant changes" - e.g.
--- Corrected spelling errors
--- Removed unnecessary imports
Not implemented yet
- Error propagation for redistributed updates. That is, the responses from the
redistributed updates in DistributedUpdateProcessor using SolrCmdDistributor,
have to be collected an merged into a combined response from "this"
DistributedUpdateProcessor.
-- Both implementation and tests are missing.
- Tests verifying that updates using JSON and CSV requests as described on
http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics also works as
described. Especially transfer of partRefs in JSON and CSV requests.
- Tests verifying that semanticsMode "consistency" works as it is supposed to -
just like ClassicConsistencyHybridXXXTests tests this for
"classic-consistency-hybrid" semanticsMode and like ClassicUpdateSemanticsTest
shortly tests it when semanticsMode is explicitly set to "classic" ("classic"
is the default so this mode is already tested a lot using all the others tests
in the project)
Other stuff not done yet
- Add Apache 2.0 Licence to all new files
- Check correct indenting
> Versioning - optimistic locking
> ---
>
> Key: SOLR-3178
> URL: https://issues.apache.org/jira/browse/SOLR-3178
> Project: Solr
> Issue Type: New Feature
> Components: update
>Affects Versions: 3.5
> Environment: All
>Reporter: Per Steffensen
>Assignee: Per Steffensen
> Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey,
> update, versioning
> Fix For: 4.0
>
> Attachments: SOLR-3178.patch, SOLR_3173_3178_3382_plus.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> In order increase the ability of Solr to be used as a NoSql database (lots of
> concurrent inserts, updates, deletes and queries in the entire lifetime of
> the index) instead of just a search index (first: everything indexed (in one
> thre
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13458 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13458/ 1 tests failed. REGRESSION: org.apache.solr.util.TimeZoneUtilsTest.testCustom Error Message: GMT-00 expected: but was: Stack Trace: java.lang.AssertionError: GMT-00 expected: but was: at __randomizedtesting.SeedInfo.seed([A0A8EB5DE817E3D4:722EAAF3BBAD07C5]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.apache.solr.util.TimeZoneUtilsTest.testCustom(TimeZoneUtilsTest.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1913) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:805) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:866) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:880) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:759) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:681) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:614) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:653) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:812) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:668) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:687) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:723) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:734) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:604) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:550) Build Log (for compile errors): [...truncated 7971 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260789#comment-13260789 ] Steven Rowe commented on SOLR-3405: --- bq. But the maven artifacts expose these inner details: http://search.maven.org/remotecontent?filepath=org/apache/solr/solr-core/3.6.0/solr-core-3.6.0.pom bq. I think the contribs are actually in our package (along with their third party dependencies!) So in my opinion, they should also be in maven: it should match. Ok, so if I understand correctly, the problem as you see it is not the binary jars/war that are published on Maven Central (AFAICT, the set of jars/war in Maven Central are the same as in Solr's binary distribution), but rather the POMs associated with them that refer to third-party artifacts, like commons-csv. Right? > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 13457 - Still Failing
: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13457/ : Error Message: GMT-00 : expected: : but : was: This build contained my changes to "testCustom" in the same class that explicitly called the exact same methods on "GMT-00"... http://svn.apache.org/viewvc?view=revision&revision=1329887 ...and yet testCustom passed. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13457 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13457/ 1 tests failed. FAILED: org.apache.solr.util.TimeZoneUtilsTest.testRandom Error Message: GMT-00 expected: but was: Stack Trace: java.lang.AssertionError: GMT-00 expected: but was: at __randomizedtesting.SeedInfo.seed([A9EA46A2EE8B7B24:DBA663AD5FEBCD57]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.apache.solr.util.TimeZoneUtilsTest.testRandom(TimeZoneUtilsTest.java:99) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1913) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:805) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:866) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:880) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:759) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:681) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:614) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:653) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:812) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:668) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:687) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:723) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:734) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:604) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:550) Build Log (for compile errors): [...truncated 7936 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3406) Support grouped range and query facets.
[ https://issues.apache.org/jira/browse/SOLR-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David updated SOLR-3406: Description: Need the ability to support grouped range and query facets. Grouped facet fields have already been implemented in SOLR-2898 but we still need the ability to compute grouped range and query facets. (was: Need the ability for range and pivot facet queries to operate over a grouped docset. We can already get the grouped counts for facet.field but still need the ability for facet.query to operate on a grouped docset.) Summary: Support grouped range and query facets. (was: Compute facet queries over grouped docsets) > Support grouped range and query facets. > --- > > Key: SOLR-3406 > URL: https://issues.apache.org/jira/browse/SOLR-3406 > Project: Solr > Issue Type: New Feature >Reporter: David >Priority: Critical > Fix For: 4.0 > > Original Estimate: 504h > Remaining Estimate: 504h > > Need the ability to support grouped range and query facets. Grouped facet > fields have already been implemented in SOLR-2898 but we still need the > ability to compute grouped range and query facets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-2898) Support grouped faceting
[
https://issues.apache.org/jira/browse/SOLR-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260763#comment-13260763
]
David edited comment on SOLR-2898 at 4/24/12 6:03 PM:
--
I just realized that computing stats on an ungrouped docset still wouldn't work
since I still need to do query facets on price ranges. I have created issue
SOLR-3406 to address the problems described with not having the ability to use
facet.query over a grouped docset.
Martijn: This functionality is critical to my implementation of Solr and I
would like to help develop a solution. You mention in a previous post
{quote}
The idea I had in mind was to support grouped facets for all facet types and
methods. However this requires a lot of changes in the current code
(SimpleFacets class) and I think the code becomes even more complex then it
already is. I was thinking about creating GroupedFacets class and then
step-by-step support more facet types with grouping. But this is just an idea.
{quote}
Have you started on GroupedFacets? I don't see it in the trunk but wasn't sure
if you had started something locally. I do see a GroupedFacetHit.class commited
to trunk but I'm not sure if that is related.
At any rate I am new to Solr development. Do you think you could point me in
the right direction or give me your vision of how you see this implementation
happening.
Also to anybody reading this post that would like to see this feature
implemented please vote for issue SOLR-3406
was (Author: dboychuck):
I just realized that computing stats on an ungrouped docset still wouldn't
work since I still need to do query facets on price ranges. I have created
issue SOLR-3406 to address the problems described with not having the ability
to use facet.query over a grouped docset.
Martijn: This functionality is critical to my implementation of Solr and I
would like to help develop a solution. You mention in a previous post
{quote}
The idea I had in mind was to support grouped facets for all facet types and
methods. However this requires a lot of changes in the current code
(SimpleFacets class) and I think the code becomes even more complex then it
already is. I was thinking about creating GroupedFacets class and then
step-by-step support more facet types with grouping. But this is just an idea.
{quote}
Have you started on GroupedFacets? I don't see it in the trunk but wasn't sure
if you had started something locally. I do see a GroupedFacetHit.class commited
to trunk but I'm not sure if that is related.
At any rate I am new to Solr development. Do you think you could point me in
the right direction or give me your vision of how you see this implementation
happening.
> Support grouped faceting
>
>
> Key: SOLR-2898
> URL: https://issues.apache.org/jira/browse/SOLR-2898
> Project: Solr
> Issue Type: New Feature
>Reporter: Martijn van Groningen
> Fix For: 4.0
>
> Attachments: SOLR-2898.patch, SOLR-2898.patch, SOLR-2898.patch,
> SOLR-2898.patch
>
>
> Support grouped faceting. As described in LUCENE-3097 (matrix counts).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2898) Support grouped faceting
[
https://issues.apache.org/jira/browse/SOLR-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260763#comment-13260763
]
David commented on SOLR-2898:
-
I just realized that computing stats on an ungrouped docset still wouldn't work
since I still need to do query facets on price ranges. I have created issue
SOLR-3406 to address the problems described with not having the ability to use
facet.query over a grouped docset.
Martijn: This functionality is critical to my implementation of Solr and I
would like to help develop a solution. You mention in a previous post
{quote}
The idea I had in mind was to support grouped facets for all facet types and
methods. However this requires a lot of changes in the current code
(SimpleFacets class) and I think the code becomes even more complex then it
already is. I was thinking about creating GroupedFacets class and then
step-by-step support more facet types with grouping. But this is just an idea.
{quote}
Have you started on GroupedFacets? I don't see it in the trunk but wasn't sure
if you had started something locally. I do see a GroupedFacetHit.class commited
to trunk but I'm not sure if that is related.
At any rate I am new to Solr development. Do you think you could point me in
the right direction or give me your vision of how you see this implementation
happening.
> Support grouped faceting
>
>
> Key: SOLR-2898
> URL: https://issues.apache.org/jira/browse/SOLR-2898
> Project: Solr
> Issue Type: New Feature
>Reporter: Martijn van Groningen
> Fix For: 4.0
>
> Attachments: SOLR-2898.patch, SOLR-2898.patch, SOLR-2898.patch,
> SOLR-2898.patch
>
>
> Support grouped faceting. As described in LUCENE-3097 (matrix counts).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260762#comment-13260762 ] Robert Muir commented on SOLR-3405: --- I think the contribs are actually in our package (along with their third party dependencies!) So in my opinion, they should also be in maven: it should match. > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3406) Compute facet queries over grouped docsets
David created SOLR-3406: --- Summary: Compute facet queries over grouped docsets Key: SOLR-3406 URL: https://issues.apache.org/jira/browse/SOLR-3406 Project: Solr Issue Type: New Feature Reporter: David Priority: Critical Fix For: 4.0 Need the ability for range and pivot facet queries to operate over a grouped docset. We can already get the grouped counts for facet.field but still need the ability for facet.query to operate on a grouped docset. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3405) maven artifacts should be equivalent to binary packaging
[ https://issues.apache.org/jira/browse/SOLR-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260754#comment-13260754 ] Steven Rowe commented on SOLR-3405: --- So under this proposal, which of these would NOT be published on maven central?: * solr-core-X.Y.Z.jar * solr-test-framework-X.Y.Z.jar * solr--X.Y.Z.jar If I understand properly, under this proposal, the Solr war would be published on maven central, but several maven proponents have said that that is not useful. By contrast, I believe there are people who currently depend on solr-core and solr-test-framework via Maven. For solrj, to make maven artifacts consistent with the binary distribution, I think the POM should mark as optional those dependencies that don't ship with the binary distribution (that may already be the case, I haven't checked). > maven artifacts should be equivalent to binary packaging > > > Key: SOLR-3405 > URL: https://issues.apache.org/jira/browse/SOLR-3405 > Project: Solr > Issue Type: Task > Components: Build >Reporter: Robert Muir > Fix For: 4.0 > > > Lets take the commons-csv scenario: > * apache-solr-3.5.0 binary distribution contains no actual commons-csv.jar > anywhere, > in fact it contains no third party jars (the stuff present in solr/lib) at > all. > * binary distribution contains only the jars necessary for *solrj* and > *contrib plugins*, and a solr.war > I think the maven artifacts should match whats in the binary release (no > third party jars > inside the .war are "exposed", we just publish the .war itself). This exposes > a lot less surface area. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3393) Implement an optimized LFUCache
[ https://issues.apache.org/jira/browse/SOLR-3393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-3393: --- Attachment: SOLR-3393.patch Patch for new LFUCache implementation. It should be pretty close to O(1). ConcurrentLFUCache is removed. TestLFUCache and SolrInfoMBeanTest have been updated as well. All tests pass. > Implement an optimized LFUCache > --- > > Key: SOLR-3393 > URL: https://issues.apache.org/jira/browse/SOLR-3393 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 3.6, 4.0 >Reporter: Shawn Heisey >Priority: Minor > Fix For: 4.0 > > Attachments: SOLR-3393.patch > > > SOLR-2906 gave us an inefficient LFU cache modeled on > FastLRUCache/ConcurrentLRUCache. It could use some serious improvement. The > following project includes an Apache 2.0 licensed O(1) implementation. The > second link is the paper (PDF warning) it was based on: > https://github.com/chirino/hawtdb > http://dhruvbird.com/lfu.pdf > Using this project and paper, I will attempt to make a new O(1) cache called > FastLFUCache that is modeled on LRUCache.java. This will (for now) leave the > existing LFUCache/ConcurrentLFUCache implementation in place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13456 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13456/ 1 tests failed. REGRESSION: org.apache.solr.util.TimeZoneUtilsTest.testRandom Error Message: GMT-00 expected: but was: Stack Trace: java.lang.AssertionError: GMT-00 expected: but was: at __randomizedtesting.SeedInfo.seed([F85A3B527E57DF48:8A161E5DCF37693B]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.apache.solr.util.TimeZoneUtilsTest.testRandom(TimeZoneUtilsTest.java:96) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1913) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:805) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:866) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:880) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:759) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:681) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:614) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:653) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:812) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:668) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:687) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:723) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:734) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:604) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:550) Build Log (for compile errors): [...truncated 7991 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 - Failure
: FWIW: I can not reproduce this using hte specified seed...
Even when i added explicit checks for the input that the test complained
about ("GMT-00") i still can't reproduce ... but i'm using Java6 and i
don't have Java7.
I double checked the code, and i seriously don't understand how this
failure could happen -- unless multiple calls to
TimeZone.getTimeZone("GMT-00") return diff objects. (the only diff
between the expected and actual code paths are that in the "actual" path,
the helper method can return null instead of calling TimeZone.getTimeZone
if the input string doesn't match some rules.
Can anybody reproduce this failure?
you shouldn't even need to trust the seed, just run the entire
TimeZoneUtilsTest class with the changes to "testCustom" i just committed
that explicitly test "GMT-00"
: ant test -Dtests.class=*.TimeZoneUtilsTest -Dtests.method=testRandom
-Dtests.seed=A928CC75CAAEE111 -Dtests.multiplier=3
-Dargs="-Dfile.encoding=US-ASCII"
:
: And the same test passed on the latest trunk (non java7) jenkins build...
:
: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13455/
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3382) Finegrained error propagation (focus on multi-document updates)
[ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260742#comment-13260742 ] Per Steffensen commented on SOLR-3382: -- See patch attached to SOLR-3178 > Finegrained error propagation (focus on multi-document updates) > --- > > Key: SOLR-3382 > URL: https://issues.apache.org/jira/browse/SOLR-3382 > Project: Solr > Issue Type: New Feature > Components: clients - java, Response Writers, update >Affects Versions: 3.5 >Reporter: Per Steffensen >Assignee: Per Steffensen > Labels: client, documents, error, multiple, propagation, update > Fix For: 4.0 > > > Today when an error occurs on server side during the handling of a request, > the handling of the request will stop at the point when the error occured, > and only a error-message (reason part of HTTP status line) and error-code > (HTTP response code) is pushed back to the sender of the request. > This can be improved in several ways > - Reacting as a client on errors, solely based on a textual message and a > HTTP response code is hard. The error ought have some kind of type telling > the client which kind of error happened. > - When handling multi-document updates the error might happen during the > handling of one of the documents - potentially not the first document and > potentially not the last document. > -- The client ought to get information about which documents where > successfully updated (the ones comming before the document creating the > error). > -- If the error updating a document is not due to a general problem, it could > very well be that some of the documents not yet handled at the time of the > error (the documents comming after the document creating the error), could be > successfully updated - so why not try that. > -- If continuing the updating of documents, even after one document-update > resulted in an error (as suggested above), the updating of some of those > documents might also result in an error. This leads to another improvement, > namely being able to send information about more than one error back to the > client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260741#comment-13260741 ] Per Steffensen commented on SOLR-3173: -- See patch attached to SOLR-3178 > Database semantics - insert and update > -- > > Key: SOLR-3173 > URL: https://issues.apache.org/jira/browse/SOLR-3173 > Project: Solr > Issue Type: New Feature > Components: update >Affects Versions: 3.5 > Environment: All >Reporter: Per Steffensen >Assignee: Per Steffensen > Labels: RDBMS, insert, nosql, uniqueKey, update > Fix For: 4.0 > > Original Estimate: 168h > Remaining Estimate: 168h > > In order increase the ability of Solr to be used as a NoSql database (lots of > concurrent inserts, updates, deletes and queries in the entire lifetime of > the index) instead of just a search index (first: everything indexed (in one > thread), after: only queries), I would like Solr to support the following > features inspired by RDBMSs and other NoSql databases. > * Given a solr-core with a schema containing a uniqueKey-field "uniqueField" > and a document Dold, when trying to INSERT a new document Dnew where > Dold.uniqueField is equal to Dnew.uniqueField, then I want a > DocumentAlredyExists error. If no such document Dold exists I want Dnew > indexed into the solr-core. > * Given a solr-core with a schema containing a uniqueKey-field "uniqueField" > and a document Dold, when trying to UPDATE a document Dnew where > Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and > Dnew added to the index (just as it is today).If no such document Dold exists > I want nothing to happen (Dnew is not added to the index) > The essence of this issue is to be able to state your intent (insert or > update) and have slightly different semantics (from each other and the > existing update) depending on you intent. > The functionality provided by this issue is only really meaningfull when you > run with "updateLog" activated. > This issue might be solved more or less at the same time as SOLR-3178, and > only one single SVN patch might be given to cover both issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2324 - Failure
: The crazything: unless i have a serious bug in the test, both of those
: TimeZone objects came from calling TimeZone.getTimeZone("GMT-00") ... the
: only difference is that the "actual" call went through some string
: validation first to ensure it matcheda regex.
:
: spooky fucking shit.
FWIW: I can not reproduce this using hte specified seed...
ant test -Dtests.class=*.TimeZoneUtilsTest -Dtests.method=testRandom
-Dtests.seed=A928CC75CAAEE111 -Dtests.multiplier=3
-Dargs="-Dfile.encoding=US-ASCII"
And the same test passed on the latest trunk (non java7) jenkins build...
https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13455/
-Hoss
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Spatial contrib bug fixing
Uhm.. I was referring to the .NET port, which I can see DIGY ported Nevermind I will get it from the original commit @Prescott any idea re " CartesianPolyFilterBuilder.GetBoxShape() is not an exact port - do you remember why? "? On Tue, Apr 24, 2012 at 12:26 AM, Christopher Currens < currens.ch...@gmail.com> wrote: > It's in a weird place. And for the 3.0.3 version, its easiest to find the > code in the tags, rather than branches. > > > http://svn.apache.org/viewvc/lucene/java/tags/lucene_3_0_3/contrib/misc/src/java/org/apache/lucene/misc/ > > > On Mon, Apr 23, 2012 at 2:20 PM, Prescott Nasser >wrote: > > > > > I'm having trouble finding chained filter in the java lucene svn... > > > http://svn.apache.org/viewvc/lucene/dev/branches/branch_3x/lucene/contrib/?pathrev=990167amI > looking around in the wrong place? > > > Date: Mon, 23 Apr 2012 11:19:51 +0300 > > > Subject: Re: Spatial contrib bug fixing > > > From: ita...@code972.com > > > To: lucene-net-...@lucene.apache.org > > > > > > One more thing - what's the deal with ChainedFilter? I can see a commit > > by > > > DIGY on 7/7/2011 but it seems to have been removed since? > > > > > > On Mon, Apr 23, 2012 at 11:06 AM, Itamar Syn-Hershko < > ita...@code972.com > > >wrote: > > > > > > > For starters - CartesianPolyFilterBuilder.GetBoxShape() is not an > exact > > > > port - do you remember why? > > > > > > > > Anyway, if it was never fully ported as you say maybe I'll just go > > ahead > > > > and complete that > > > > > > > > For your reference, here are 2 failing tests which pass in Java > Lucene > > > > (can send the java file) - > > > > > > > https://github.com/synhershko/lucene.net/commit/234da7eca7cb08be5a0c2a7375ffc3f4a03bfd92 > > > > > > > > > > > > > > > > On Mon, Apr 23, 2012 at 1:39 AM, Prescott Nasser < > > geobmx...@hotmail.com>wrote: > > > > > > > >> > > > >> I think that was a while ago, and I don't even recall if I fully > > ported > > > >> it or just put up the start. I had some other stuff to deal with the > > last > > > >> few months, so my memory is a bit lacking. I'll review the code, > > meanwhile > > > >> ask whatever questions you have - lets get this fixed up. ~P > > > >> > Date: Sun, 22 Apr 2012 22:10:27 +0300 > > > >> > Subject: Spatial contrib bug fixing > > > >> > From: ita...@code972.com > > > >> > To: lucene-net-...@lucene.apache.org > > > >> > > > > >> > Hi all, > > > >> > > > > >> > We encountered several bugs with the Sparial contrb, and the ones > we > > > >> tested > > > >> > with Java Lucene worked there (with 2.9.4). There are about 3 open > > > >> tickets > > > >> > in the Jira bug tracker on similar issues. > > > >> > > > > >> > I'm now sitting with the ultimate goal of fixing this once and for > > all, > > > >> but > > > >> > some code parts are commented out in favor of other not > line-by-line > > > >> port > > > >> > of some implementations, without a comment giving reasons. I was > > > >> wondering > > > >> > if there's anyone who could answer a few questions there, instead > > of me > > > >> > changing things back and forth? > > > >> > > > > >> > Git history (I use the Git mirror, yes) tells me Prescott Nasser > is > > > >> behind > > > >> > porting this - maybe he will have the answers? > > > >> > > > > >> > Cheers, > > > >> > > > > >> > Itamar. > > > >> > > > >> > > > > > > > > > > > > >
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13455 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13455/ 1 tests failed. REGRESSION: org.apache.solr.handler.TestReplicationHandler.test Error Message: expected:<1> but was:<0> Stack Trace: java.lang.AssertionError: expected:<1> but was:<0> at __randomizedtesting.SeedInfo.seed([52421F76851D8330:DA1620AC2BE1EEC8]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.handler.TestReplicationHandler.doTestBackup(TestReplicationHandler.java:807) at org.apache.solr.handler.TestReplicationHandler.test(TestReplicationHandler.java:254) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1913) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:805) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:866) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:880) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:759) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:681) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:614) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:653) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:812) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:668) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:687) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:723) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:734) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:604) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:131) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:550) Build Log (for compile errors): [...truncated 7986 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: guestimation on -pre nuget package.
If it is known to be stable for actual use, we RavenDB dev team will update to it in a branch and provide feedback. A -Pre nuget package released for every RC can definitely help here. On Tue, Apr 24, 2012 at 5:25 PM, Michael Herndon < mhern...@wickedsoftware.net> wrote: > Do you all think we're at a point to do a -pre nuget package that users can > tinker with and provide feedback? The -pre flag means that it is only > meant to be a pre release in order to get feedback. We might get more > feedback if we package the binaries. > > Those that pushed the last package, what do you think the amount of effort > / time that will take to get something like this done? (I'm asking so that > I can block off enough time in my schedule to do this. ) > > I'm guessing shouldn't be as rigorous as a typical apache release as its > meant just to package a alpha/beta binaries, not an official RTW. > > - michael. >
