Re: Welcome Stefan Vodita as Lucene committter

[Martin Gainty]

Congratulations Stefan!

I look forward to reading your posts

~martin

From: Michael McCandless 
Sent: Thursday, January 18, 2024 10:53 AM
To: dev@lucene.apache.org 
Subject: Welcome Stefan Vodita as Lucene committter

Hi Team,

I'm pleased to announce that Stefan Vodita has accepted the Lucene PMC's 
invitation to become a committer!

Stefan, the tradition is that new committers introduce themselves with a brief 
bio.

Congratulations, welcome, and thank you for all your improvements to Lucene and 
our community,

Mike McCandless

http://blog.mikemccandless.com

Re: Welcome Luca Cavanna to the Lucene PMC

[Martin Gainty]

Welcome Luca!

-martin

From: Uwe Schindler 
Sent: Monday, October 23, 2023 3:49 AM
To: dev@lucene.apache.org 
Subject: Re: Welcome Luca Cavanna to the Lucene PMC


Welcome Luca,

Uwe

Am 20.10.2023 um 07:50 schrieb Adrien Grand:
I'm pleased to announce that Luca Cavanna has accepted an invitation to join 
the Lucene PMC!

Congratulations Luca, and welcome aboard!

--
Adrien

--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de

Re: Welcome Ben Trent as Lucene committer

[Martin Gainty]

congratulations ben!
m.g.

From: Mikhail Khludnev 
Sent: Friday, January 27, 2023 3:39 PM
To: dev@lucene.apache.org 
Subject: Re: Welcome Ben Trent as Lucene committer

Congratulations, Ben.

On Fri, Jan 27, 2023 at 8:40 PM Benjamin Trent 
mailto:ben.w.tr...@gmail.com>> wrote:
Hey y'all!

This is truly an honor!

Well, I am Ben Trent and have been writing code for over a decade now. Which I 
know is not a very long time compared to most folks. I originally wanted to do 
research and work in pure mathematics (my baccalaureate), but quickly realized 
I am nowhere near smart enough to make money at that. So, like many folks, I 
switched to computing and haven't looked back.

In my spare time (when not wrangling one of my children), I enjoy movies 
(especially old kung fu, anything Golden Harvest or Shaw Brothers), good beer, 
reading, playing guitar, and hiking.

Thank you all for the warm welcome! See you online!

Ben

On Fri, Jan 27, 2023 at 10:26 AM Ishan Chattopadhyaya 
mailto:ichattopadhy...@gmail.com>> wrote:
Welcome and congratulations, Ben!

On Fri, Jan 27, 2023 at 8:48 PM Adrien Grand 
mailto:jpou...@gmail.com>> wrote:
>
> I'm pleased to announce that Ben Trent has accepted the PMC's
> invitation to become a committer.
>
> Ben, the tradition is that new committers introduce themselves with a
> brief bio.
>
> Congratulations and welcome!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: 
> dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: 
> dev-h...@lucene.apache.org
>


--
Sincerely yours
Mikhail Khludnev
https://t.me/MUST_SEARCH
A caveat: Cyrillic!

Re: Welcome Luca Cavanna as Lucene committer

[Martin Gainty]

welcome Luca!

From: David Smiley 
Sent: Wednesday, October 5, 2022 2:34 PM
To: dev@lucene.apache.org 
Cc: cavannal...@gmail.com 
Subject: Re: Welcome Luca Cavanna as Lucene committer

Welcome Luca!

On Wed, Oct 5, 2022 at 12:04 PM Adrien Grand 
mailto:jpou...@gmail.com>> wrote:
I'm pleased to announce that Luca Cavanna has accepted the PMC's
invitation to become a committer.

Luca, the tradition is that new committers introduce themselves with a
brief bio.

Congratulations and welcome!


--
Adrien
--
Sent from Gmail Mobile

Re: Welcome Greg Miller to the Lucene PMC

[Martin Gainty]

Welcome Greg!

~martin

From: Gus Heck 
Sent: Tuesday, June 7, 2022 9:29 PM
To: dev 
Subject: Re: Welcome Greg Miller to the Lucene PMC

Welcome Greg :)


On Tue, Jun 7, 2022 at 5:43 PM David Smiley 
mailto:dsmi...@apache.org>> wrote:
Welcome Greg!

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Tue, Jun 7, 2022 at 2:44 AM Adrien Grand 
mailto:jpou...@gmail.com>> wrote:
I'm pleased to announce that Greg Miller has accepted an invitation to join the 
Lucene PMC!

Congratulations Greg, and welcome aboard!

--
Adrien


--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: Welcome Chris Hegarty as Lucene committer

[Martin Gainty]

Welcome Chris!
martin

From: Tomoko Uchida 
Sent: Wednesday, June 1, 2022 11:05 AM
To: Lucene Dev 
Subject: Re: Welcome Chris Hegarty as Lucene committer

Congratulations and welcome, Chris!

Tomoko


2022年6月1日(水) 23:17 Nhat Nguyen :
Welcome, Chris!

On Wed, Jun 1, 2022 at 8:49 AM Greg Miller 
mailto:gsmil...@gmail.com>> wrote:
Welcome Chris!

On Wed, Jun 1, 2022 at 2:04 PM Mayya Sharipova
mailto:mayya.sharip...@elastic.co>.invalid> wrote:
>
> Welcome and congratulations, Chris!
>
> On Wed, Jun 1, 2022 at 7:53 AM Jan Høydahl 
> mailto:jan@cominvent.com>> wrote:
>>
>> Welcome Chris!
>>
>> Jan
>>
>> > 1. jun. 2022 kl. 09:04 skrev Adrien Grand 
>> > mailto:jpou...@gmail.com>>:
>> >
>> > I'm pleased to announce that Chris Hegarty has accepted the PMC's
>> > invitation to become a committer.
>> >
>> > Chris, the tradition is that new committers introduce themselves with a
>> > brief bio.
>> >
>> > Congratulations and welcome!
>> >
>> > --
>> > Adrien
>>
>>
>> -
>> 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: Lucene PMC Chair Bruno Roustant

[Martin Gainty]

Welcome Bruno !

-martin

From: Adrien Grand 
Sent: Wednesday, March 23, 2022 9:20 AM
To: Lucene Dev 
Subject: Re: Lucene PMC Chair Bruno Roustant

Congratulations Bruno!

On Wed, Mar 23, 2022 at 2:03 PM Michael Sokolov  wrote:
>
> Hello, Lucene developers. Lucene Program Management Committee has
> elected a new chair, Bruno Roustant, and the Board has approved.
> Bruno, thank you for stepping up, and congratulations!
>
> -Mike
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


--
Adrien

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Guo Feng as Lucene committer

[Martin Gainty]

Welcome Guo !

martin-


From: Christian Moen 
Sent: Sunday, January 30, 2022 8:20 AM
To: dev@lucene.apache.org 
Cc: 1796385623 
Subject: Re: Welcome Guo Feng as Lucene committer

Congrats, Feng.

On Tue, Jan 25, 2022 at 6:09 PM Adrien Grand 
mailto:jpou...@gmail.com>> wrote:
I'm pleased to announce that Guo Feng has accepted the PMC's
invitation to become a committer.

Feng, the tradition is that new committers introduce themselves with a
brief bio.

Congratulations and welcome!

--
Adrien

-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Warnings from gradle rat task

[Martin Gainty]

its been my experience gradle takes months to address these type of issues
can be quite frustrating since people seem to be pushing gradle as build-du-jour

martin-


From: Mike Drob 
Sent: Saturday, November 27, 2021 11:20 AM
To: dev@lucene.apache.org 
Subject: Re: Warnings from gradle rat task



On Sat, Nov 27, 2021 at 9:48 AM Dawid Weiss 
mailto:dawid.we...@gmail.com>> wrote:
MG>I suspect you have an ancient javadoc binary in classpath
MG>but there is no way of knowing without looking at contents of antlib.xml

Looking at ant code it seems like it tried to reload tasks for some reason and 
class loaders are different hence the warning. We don't have javadoc on 
classpath - gradle does. I suspect it isolates tasks from each other somehow... 
not really worth looking that deep into, I guess.

D.

I think I looked into using the gradle rat plugin when we were doing the 
migrations but it was missing features. I filed an issue for them and I think 
they fixed it since then but I never went back to check if that would be enough 
for us to switch over. Maybe worth investigating, but also possibly not worth 
the efforts.

Mike

Re: Warnings from gradle rat task

[Martin Gainty]

MG>below

From: Dawid Weiss 
Sent: Friday, November 26, 2021 5:40 AM
To: Lucene Dev 
Subject: Re: Warnings from gradle rat task


Alan - 1029651d121 on main.
D.

On Thu, Nov 25, 2021 at 4:21 PM Dawid Weiss 
mailto:dawid.we...@gmail.com>> wrote:

I am 99.9% sure this warning comes from ant (we use ant's rat task) somewhere - 
not gradle... It looks like loading rat's task defs overrides ant's built-in 
javadoc for some reason - you can see it if you modify rat-sources.gradle:

def generateReport(File reportFile) {
// Set up ant rat task.
logger.lifecycle("Before.")
def ratClasspath = project.rootProject.configurations.ratDeps.asPath
ant.taskdef(resource: 'org/apache/rat/anttasks/antlib.xml', classpath: 
ratClasspath)

MG>I suspect you have an ancient javadoc binary in classpath
MG>but there is no way of knowing without looking at contents of antlib.xml

logger.lifecycle("after.")

the warning will be right there in between...

D.

On Thu, Nov 25, 2021 at 3:37 PM Alan Woodward 
mailto:romseyg...@gmail.com>> wrote:
Hi all,

When running `./gradlew check` against the latest master I get a whole bunch of 
output messages like this:

> Task :lucene:analysis:smartcn:rat
Trying to override old definition of task javadoc

> Task :lucene:analysis:stempel:rat
Trying to override old definition of task javadoc

> Task :lucene:analysis:common:rat
Trying to override old definition of task javadoc

I don’t think it’s breaking anything but it’s a bit disconcerting.  Maybe 
something to do with a gradle upgrade?

- Alan
-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Welcome Zach Chen as Lucene committer

[Martin Gainty]

welcome Zach!

martin​


From: Dawid Weiss 
Sent: Monday, April 19, 2021 12:22 PM
To: Lucene Dev 
Cc: zacharym...@yahoo.com 
Subject: Re: Welcome Zach Chen as Lucene committer

Congratulations and welcome, Zach. Well deserved!

Dawid

On Mon, Apr 19, 2021 at 4:14 PM Adrien Grand  wrote:
>
> I'm pleased to announce that Zach Chen has accepted the PMC's invitation to 
> become a committer.
>
> Zach, the tradition is that new committers introduce themselves with a brief 
> bio.
>
> Congratulations and welcome!
>
> --
> Adrien

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Bruno to the Apache Lucene PMC

[Martin Gainty]

welcome Bruno!
martin

From: Dawid Weiss 
Sent: Thursday, March 11, 2021 10:59 AM
To: Lucene Dev 
Subject: Re: Welcome Bruno to the Apache Lucene PMC

Welcome, Bruno!

On Thu, Mar 11, 2021 at 4:29 PM Gus Heck  wrote:
>
> Welcome :)
>
> On Thu, Mar 11, 2021 at 9:58 AM Houston Putman  
> wrote:
>>
>> Congrats and welcome Bruno!
>>
>> On Thu, Mar 11, 2021 at 8:32 AM David Smiley  wrote:
>>>
>>> Welcome Bruno!
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Wed, Mar 10, 2021 at 7:56 PM Mike Drob  wrote:

 I am pleased to announce that Bruno has accepted an invitation to join the 
 Lucene PMC!

 Congratulations, and welcome aboard!

 Mike
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!

[Martin Gainty]

поздравления!


From: Julie Tibshirani 
Sent: Wednesday, February 17, 2021 9:13 PM
To: Lucene Dev 
Subject: Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!

Congratulations Mike!!

On Wed, Feb 17, 2021 at 3:12 PM Gus Heck 
mailto:gus.h...@gmail.com>> wrote:
Congratulations :)

On Wed, Feb 17, 2021 at 5:42 PM Tomás Fernández Löbbe 
mailto:tomasflo...@gmail.com>> wrote:
Congratulations Mike!

On Wed, Feb 17, 2021 at 2:42 PM Steve Rowe 
mailto:sar...@gmail.com>> wrote:
Congrats Mike!

--
Steve

> On Feb 17, 2021, at 4:31 PM, Anshum Gupta 
> mailto:ans...@anshumgupta.net>> wrote:
>
> Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice 
> President position.
>
> This year we nominated and elected Michael Sokolov as the Chair, a decision 
> that the board approved in its February 2021 meeting.
>
> Congratulations, Mike!
>
> --
> Anshum Gupta


-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org



--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: additional term meta data

[Martin Gainty]

close to finish testing but i need help finding this testcase
RamUsageTester

any ideas?

Thanks John!
martin


From: Martin Gainty 
Sent: Wednesday, January 6, 2021 6:28 AM
To: dev@lucene.apache.org 
Subject: Re: additional term meta data

how to access first and last?
which version will you be merging


From: John Wang 
Sent: Tuesday, January 5, 2021 8:19 PM
To: dev@lucene.apache.org 
Subject: additional term meta data

Hi folks:

We like to propose a feature to add additional per-term metadata to the term 
diction.

Currently, the TermsEnum API returns docFreq as its only meta-data. We needed a 
way to quickly get the first and last doc id in the postings without having to 
scan through the entire postings list.

We have created a PR on our own fork and we would like to contribute this back 
to the community. Please let us know if this is something that's useful and/or 
fits Lucene's roadmap, we would be happy to submit a patch.

https://github.com/dashbase/lucene-solr/pull/1

Thank you

-John

Re: additional term meta data

[Martin Gainty]

appears you are targeting 9.0 for your code
lucene/core/src/java/org/apache/lucene/codecs/lucene90/Lucene90FieldInfosFormat.java<https://github.com/dashbase/lucene-solr/pull/1/files#diff-224246aa19a54dd91fc495a6bbf7d75b26dbeaa3aceab058214d68fcbb38d24c>
(Lucene90FIeldInfosFormat.java is not contained in either 8.4 or 8.7 distros)


someone had the bright idea to nuke ant 8.x build.xml without consulting anyone
not a fan of ant but the execution model of gradle is woefully inflexible in 
comparison to maven


i will try with 90 distro to get the codecs/lucene90/Lucene90FieldInfosFormat 
and recompile and hopefully your TestLucene84PostingsFormat will run w/o fail 
or error

Thx
martin-


From: John Wang 
Sent: Wednesday, January 6, 2021 10:15 AM
To: dev@lucene.apache.org 
Subject: Re: additional term meta data

Hey Martin:

There is a test case in the PR we created on our own fork: 
https://github.com/dashbase/lucene-solr/pull/1, which also contains some 
example code on how to access in the PR description.

Here is the link to the beginning of the tests: 
https://github.com/dashbase/lucene-solr/blob/posting-last-docid/lucene/core/src/test/org/apache/lucene/codecs/lucene84/TestLucene84PostingsFormat.java#L142

I am not sure which version this should be applied to, currently, it was based 
on master as of a few days ago. We intend to patch 8.7 for our own environment.

Any advice or feedback is much appreciated.

Thank you!

-John

On Wed, Jan 6, 2021 at 3:28 AM Martin Gainty 
mailto:mgai...@hotmail.com>> wrote:
how to access first and last?
which version will you be merging


From: John Wang mailto:john.w...@gmail.com>>
Sent: Tuesday, January 5, 2021 8:19 PM
To: dev@lucene.apache.org<mailto:dev@lucene.apache.org> 
mailto:dev@lucene.apache.org>>
Subject: additional term meta data

Hi folks:

We like to propose a feature to add additional per-term metadata to the term 
diction.

Currently, the TermsEnum API returns docFreq as its only meta-data. We needed a 
way to quickly get the first and last doc id in the postings without having to 
scan through the entire postings list.

We have created a PR on our own fork and we would like to contribute this back 
to the community. Please let us know if this is something that's useful and/or 
fits Lucene's roadmap, we would be happy to submit a patch.

https://github.com/dashbase/lucene-solr/pull/1

Thank you

-John

Re: additional term meta data

[Martin Gainty]

how to access first and last?
which version will you be merging


From: John Wang 
Sent: Tuesday, January 5, 2021 8:19 PM
To: dev@lucene.apache.org 
Subject: additional term meta data

Hi folks:

We like to propose a feature to add additional per-term metadata to the term 
diction.

Currently, the TermsEnum API returns docFreq as its only meta-data. We needed a 
way to quickly get the first and last doc id in the postings without having to 
scan through the entire postings list.

We have created a PR on our own fork and we would like to contribute this back 
to the community. Please let us know if this is something that's useful and/or 
fits Lucene's roadmap, we would be happy to submit a patch.

https://github.com/dashbase/lucene-solr/pull/1

Thank you

-John

Re: additional term meta data

[Martin Gainty]

how to access first and last doc-id?
for which lucene version will you be targeting your merge?

Request: please submit testcase to show proper operation

Thanks John!
martin-


From: John Wang 
Sent: Tuesday, January 5, 2021 8:19 PM
To: dev@lucene.apache.org 
Subject: additional term meta data

Hi folks:

We like to propose a feature to add additional per-term metadata to the term 
diction.

Currently, the TermsEnum API returns docFreq as its only meta-data. We needed a 
way to quickly get the first and last doc id in the postings without having to 
scan through the entire postings list.

We have created a PR on our own fork and we would like to contribute this back 
to the community. Please let us know if this is something that's useful and/or 
fits Lucene's roadmap, we would be happy to submit a patch.

https://github.com/dashbase/lucene-solr/pull/1

Thank you

-John

Re: Old programmers do NOT fade away

[Martin Gainty]

Hey Erick

you should've been PMC with the immense amount of work you put into this project
i would be happy to pickup some of the potential slack maybe the 
bad-apple-report ?
BUT MY SCHEDULE CAN BE RANDOMLY FILLED WITH
playing with grandkids
Helping out eldest daughter..(something about father knows best especially when 
it comes to home remodeling)
Taking mandatory breaks for shoveling snow or cleaning out plugged toilet 
(c***py mandatory manual landlord tasks)
i just bought a multi-family in nutley near orange so i am hoping (once this 
silly covid mess is over and done with) we could possibly meet for a coffee on 
sloan street?
I have hired trusty relative to be my site-manager but next time I come down to 
visit the property i'll give you a nudge
I'll admit to being a few years older than yourself but if a 78 year old guy 
can become president then maybe there is hope for us old-timers!

For your squirrel problem...Ring has a nice motion-detect camera advertised here
Ring Floodlight Camera Motion-Activated HD Security Cam Two-Way Talk and Siren 
Alarm 
(amazon.com)
i think its ok to shoot a squirrel but if the homeless are stealing tomatoes.. 
the homeless here are out-of-work-attornies that are itching to sue somebody

l8r
Marty Gainty

From: Erick Erickson 
Sent: Wednesday, December 30, 2020 9:09 AM
To: dev@lucene.apache.org 
Subject: Old programmers do fade away

40 years is enough. OK, it's only been 39 1/2 years. Dear Lord, has it really 
been that long? Programming's been fun, I've gotten to solve puzzles every day. 
The art and science of programming has changed over that time. Let me tell you 
about the joys of debugging with a Z80 stack emulator that required that you to 
look on the stack for variables and trace function calls by knowing how to 
follow frame pointers. Oh the tedium! Oh the (lack of) speed! Not to mention 
that 64K of memory was all you had to work with. I had a co-worker who could 
predict the number of bytes by which the program would shrink based on 
extracting common code to functions. The "good old days"...weren't...

I'd been thinking that I'd treat Lucene/Solr as a hobby, doing occasional work 
on it when I was bored over long winter nights. I've discovered, though, that 
I've been increasingly reluctant to crack open the code. I guess that after 
this much time, I'm ready to hang up my spurs. One major factor is the 
realization that there's so much going on with Lucene/Solr that simply being 
aware of the changes, much less trying to really understand them, isn't 
something I can do casually.

I bought a welder and find myself more interested in playing with that than 
programming. Wait until you see the squirrel-proof garden enclosure I'm 
building with it. If my initial plan doesn't work, next up is an electric fence 
along the top. The laser-sighted automatic machine gun emplacement will take 
more planning...Ahhh, probably won't be able to get a permit from the township 
for that though. Do you think the police would notice? Perhaps I should add 
that the local police station is two blocks away and in the line of fire. But 
an infrared laser powerful enough to "pre-cook" them wouldn't be as obvious 
would it?

Why am I so fixated on squirrels? One of the joys of gardening is fresh 
tomatoes rather than those red things they sell in the store. The squirrels ATE 
EVERY ONE OF MY TOMATOES WHILE THEY WERE STILL GREEN LAST YEAR! And the melons. 
In the words of B. Bunny: "Of course you realize this means war" 
(https://www.youtube.com/watch?v=4XNr-BQgpd0)...

Then there's working in the garden and landscaping, the desk I want to build 
for my wife, travel as soon as I can, maybe seeing if some sailboats need 
crew...you get the idea.

It's been a privilege to work with this group, you're some of the best and 
brightest. Many thanks to all who've generously given me their time and 
guidance. It's been a constant source of amazement to me how willing people are 
to take time out of their own life and work to help me when I've had questions. 
I owe a lot of people beers ;)

I'll be stopping my list subscriptions, Slack channels (dm me if you need 
something), un-assigning any JIRAs and that kind of thing over the next while. 
If anyone's interested in taking over the BadApple report, let me know and I 
can put the code up somewhere. It takes about 10 minutes to do each week. I 
won't disappear entirely, things like the code-reformatting effort are nicely 
self-contained for instance and something I can to casually.

My e-mail address if you need to get in touch with me 

Re: Welcome Houston Putman to the PMC

[Martin Gainty]

congrats Houston
martin​


From: Yonik Seeley 
Sent: Tuesday, December 1, 2020 7:35 PM
To: Solr/Lucene Dev 
Subject: Re: Welcome Houston Putman to the PMC

Congrats Houston!
-Yonik


On Tue, Dec 1, 2020 at 4:19 PM Mike Drob 
mailto:md...@apache.org>> wrote:
I am pleased to announce that Houston Putman has accepted the PMC's invitation 
to join.

Congratulations and welcome, Houston!

-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Gradle build, where's the output?

[Martin Gainty]

travis doc suggests user account does not have 'read access' to dependency 
folder

https://docs.travis-ci.com/user/languages/java/#projects-using-gradle

m-


From: Erick Erickson 
Sent: Tuesday, September 22, 2020 10:48 AM
To: dev@lucene.apache.org 
Subject: Gradle build, where's the output?

The Gradle build used to print out where to find the artifacts for the 
“assemble” and “dev” tasks, but that disappeared sometime. Is this intentional? 
It really helped me the first time I tried to run Solr after building with 
Gradle…

Currently, “gradlew tasks” does print the location of the artifacts for the 
“dev” target, but not the “assemble” target, that might suffice.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Mike Drob to the PMC

[Martin Gainty]

welcome mike!

~martin~


From: Michael McCandless 
Sent: Monday, August 17, 2020 10:15 AM
To: Lucene/Solr dev 
Subject: Re: Welcome Mike Drob to the PMC

Welcome Mike!  So many Mikes now!

Mike McCandless

http://blog.mikemccandless.com


On Sat, Aug 15, 2020 at 11:49 AM Michael Sokolov 
mailto:msoko...@gmail.com>> wrote:
Late add from me too, Mike: Welcome!

On Fri, Jul 31, 2020 at 8:16 AM Noble Paul 
mailto:noble.p...@gmail.com>> wrote:
>
> Welcome Mike!
>
> On Thu, Jul 30, 2020 at 12:33 AM Erik Hatcher 
> mailto:erik.hatc...@gmail.com>> wrote:
> >
> > Oh yeah!   Welcome, Mike!
> >
> > > On Jul 24, 2020, at 3:55 PM, Anshum Gupta 
> > > mailto:ans...@anshumgupta.net>> wrote:
> > >
> > > I am pleased to announce that Mike Drob has accepted the PMC's invitation 
> > > to join.
> > >
> > > Congratulations and welcome, Mike!
> > >
> > > --
> > > Anshum Gupta
> >
> >
> > -
> > To unsubscribe, e-mail: 
> > dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: 
> > dev-h...@lucene.apache.org
> >
>
>
> --
> -
> Noble Paul
>
> -
> 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: Welcome Gus Heck to the PMC

[Martin Gainty]

welcome gus!

~martin~


From: Michael McCandless 
Sent: Wednesday, August 5, 2020 9:59 AM
To: Lucene/Solr dev 
Subject: Re: Welcome Gus Heck to the PMC

Welcome Gus!

Mike McCandless

http://blog.mikemccandless.com


On Tue, Aug 4, 2020 at 5:09 PM David Smiley 
mailto:dsmi...@apache.org>> wrote:
Welcome Gus!

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sun, Aug 2, 2020 at 7:21 PM Ishan Chattopadhyaya 
mailto:ichattopadhy...@gmail.com>> wrote:
I am pleased to announce that Gus Heck has accepted the PMC's invitation to 
join.

Congratulations and welcome, Gus!

Re: Welcome Tomoko Uchida to the PMC

[Martin Gainty]

ウェルコム  ウーキーダー

(second attempt at katakana)
~martin


From: David Smiley 
Sent: Saturday, July 25, 2020 12:30 AM
To: Solr/Lucene Dev 
Subject: Re: Welcome Tomoko Uchida to the PMC

Welcome Tomoko!

~ David


On Fri, Jul 24, 2020 at 4:55 PM Erick Erickson 
mailto:erickerick...@gmail.com>> wrote:
Welcome Tomoko!

> On Jul 24, 2020, at 4:44 PM, Jan Høydahl 
> mailto:jan@cominvent.com>> wrote:
>
> Welcome Tomoko!
>
> Jan Høydahl
>
>> 24. jul. 2020 kl. 19:08 skrev Christine Poerschke (BLOOMBERG/ LONDON) 
>> mailto:cpoersc...@bloomberg.net>>:
>>
>> 
>> Welcome Tomoko!
>>
>> From: dev@lucene.apache.org At: 07/04/20 
>> 08:27:28
>> To:  dev@lucene.apache.org
>> Subject: Re: Welcome Tomoko Uchida to the PMC
>>
>> Thank you Adrien and the whole PMCs, it's a great honour for me!
>>
>> Tomoko
>>
>>
>> 2020年7月4日(土) 15:28 Christian Moen 
>> mailto:c...@atilika.com>>:
>> Congrats, Tomoko-san!
>>
>> On Sat, Jul 4, 2020 at 15:26 Adrien Grand 
>> mailto:jpou...@gmail.com>> wrote:
>> I am pleased to announce that Tomoko Uchida has accepted the PMC's 
>> invitation to join.
>>
>> Welcome Tomoko!
>>
>>
>> --
>> Adrien
>>


-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Welcome Tomoko Uchida to the PMC

[Martin Gainty]

From: David Smiley 
Sent: Saturday, July 25, 2020 12:30 AM
To: Solr/Lucene Dev 
Subject: Re: Welcome Tomoko Uchida to the PMC

Welcome Tomoko!

~ David


On Fri, Jul 24, 2020 at 4:55 PM Erick Erickson 
mailto:erickerick...@gmail.com>> wrote:
Welcome Tomoko!

> On Jul 24, 2020, at 4:44 PM, Jan Høydahl 
> mailto:jan@cominvent.com>> wrote:
>
> Welcome Tomoko!
>
> Jan Høydahl
>
>> 24. jul. 2020 kl. 19:08 skrev Christine Poerschke (BLOOMBERG/ LONDON) 
>> mailto:cpoersc...@bloomberg.net>>:
>>
>> 
>> Welcome Tomoko!
>>
>> From: dev@lucene.apache.org At: 07/04/20 
>> 08:27:28
>> To:  dev@lucene.apache.org
>> Subject: Re: Welcome Tomoko Uchida to the PMC
>>
>> Thank you Adrien and the whole PMCs, it's a great honour for me!
>>
>> Tomoko
>>
>>
>> 2020年7月4日(土) 15:28 Christian Moen 
>> mailto:c...@atilika.com>>:
>> Congrats, Tomoko-san!
>>
>> On Sat, Jul 4, 2020 at 15:26 Adrien Grand 
>> mailto:jpou...@gmail.com>> wrote:
>> I am pleased to announce that Tomoko Uchida has accepted the PMC's 
>> invitation to join.
>>
>> Welcome Tomoko!
>>
>>
>> --
>> Adrien
>>


-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Welcome Mike Drob to the PMC

[Martin Gainty]

Congratulation Mike!
martin


From: Erick Erickson 
Sent: Friday, July 24, 2020 4:55 PM
To: dev@lucene.apache.org 
Subject: Re: Welcome Mike Drob to the PMC

Welcome Mike!

> On Jul 24, 2020, at 4:12 PM, Ilan Ginzburg  wrote:
>
> Congratulations Mike, happy to hear that!
>
> Ilan
>
> On Fri, Jul 24, 2020 at 9:56 PM Anshum Gupta  wrote:
> I am pleased to announce that Mike Drob has accepted the PMC's invitation to 
> join.
>
> Congratulations and welcome, Mike!
>
> --
> Anshum Gupta


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Tomoko Uchida to the PMC

[Martin Gainty]

Subject: Re: Welcome Tomoko Uchida to the PMC

どういたしまして

*attempt at katakana*

From: Christian Moen 
Sent: Saturday, July 4, 2020 2:27 AM
To: dev@lucene.apache.org 
Subject: Re: Welcome Tomoko Uchida to the PMC

Congrats, Tomoko-san!

On Sat, Jul 4, 2020 at 15:26 Adrien Grand 
mailto:jpou...@gmail.com>> wrote:
I am pleased to announce that Tomoko Uchida has accepted the PMC's invitation 
to join.

Welcome Tomoko!


--
Adrien

Re: Welcome Ilan Ginzburg as Lucene/Solr committer

[Martin Gainty]

ברוך הבא!


From: Erick Erickson 
Sent: Sunday, June 21, 2020 3:43 PM
To: dev@lucene.apache.org 
Subject: Re: Welcome Ilan Ginzburg as Lucene/Solr committer

Welcome!

> On Jun 21, 2020, at 3:40 PM, David Smiley  wrote:
>
> Congratulations Ilan!
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Jun 21, 2020 at 5:44 AM Noble Paul  wrote:
> Hi all,
>
> Please join me in welcoming Ilan Ginzburg as the latest Lucene/Solr committer.
> Ilan, it's tradition for you to introduce yourself with a brief bio.
>
> Congratulations and Welcome!
> Noble


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Eric Pugh as a Lucene/Solr committer

[Martin Gainty]

Welcome Eric!

martin


From: David Smiley 
Sent: Monday, April 6, 2020 11:41 AM
To: Solr/Lucene Dev 
Subject: Re: Welcome Eric Pugh as a Lucene/Solr committer

Congratulations Eric!
I'm so glad to see you resuming contributing to Solr after a long hiatus.  Much 
appreciated!

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Mon, Apr 6, 2020 at 8:21 AM Jan Høydahl 
mailto:jan@cominvent.com>> wrote:
Hi all,

Please join me in welcoming Eric Pugh as the latest Lucene/Solr committer!

Eric has been part of the Solr community for over a decade, as a code 
contributor, book author, company founder, blogger and mailing list 
contributor! We look forward to his future contributions!

Congratulations and welcome! It is a tradition to introduce yourself with a 
brief bio, Eric.

Jan Høydahl
-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Docs on our build infrastructure

[Martin Gainty]

https://builds.apache.org/job/Lucene-Solr-Maven-master/lastBuild/

lastBuild on jenkins build spent 1hr 35min waiting
what is it that the build is waiting on?
where is the pom?
where is the gradle?
where is the ant build.xml ?

it is very concerning that these files are perhaps on individual machines but 
not on repos while the build files are
missing
undocumented

?
m-


From: David Smiley 
Sent: Wednesday, March 4, 2020 12:55 AM
To: Solr/Lucene Dev 
Subject: Docs on our build infrastructure

Why do we have CI builds at not just the ASF but also Uwe's machine and also 
Steve Rowe's?  I'm not sure more is better.  Can someone knowledgeable about 
our build situation consider writing a bit of developer documentation on what 
is where and why?  I recently wanted to share this info but didn't find it... 
and I know very little of it.  We've got this old cwiki page: 
https://cwiki.apache.org/confluence/display/LUCENE/NightlyBuilds  and also 
Hossman's page is nice: http://fucit.org/solr-jenkins-reports/

BTW I was chatting with the "Klera" team about their tools and they are 
interested in exploring if their tools can help us put out the build failure 
fires -- e.g. email alerts to pertinent individuals as one example.  I'm 
following up with them.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

Re: Welcome Houston Putman as Lucene/Solr committer

[Martin Gainty]

welcome Houston!
martin-

From: Michael McCandless 
Sent: Sunday, November 17, 2019 10:32 AM
To: dev@lucene.apache.org 
Cc: Houston Putman 
Subject: Re: Welcome Houston Putman as Lucene/Solr committer

Welcome Houston!

Mike

On Thu, Nov 14, 2019 at 3:58 AM Anshum Gupta 
mailto:ans...@anshumgupta.net>> wrote:
Hi all,

Please join me in welcoming Houston Putman as the latest Lucene/Solr committer!

Houston has been involved with the community since 2013, when he first 
contributed the Analytics contrib module. Since then he has been involved with 
the community, participated in conferences and spoken about his work with 
Lucene/Solr. In the recent past, he has been involved with getting Solr to 
scale on Kubernetes.

Looking forward to your commits to the Apache Lucene/Solr project :)

Congratulations and welcome, Houston! It's a tradition to introduce yourself 
with a brief bio.

--
Anshum Gupta
--
Mike McCandless

http://blog.mikemccandless.com

Re: Anyone interested in the Gradle build, please comment on SOLR-13915

[Martin Gainty]

good catch on what happens when my jar is not located in specified lib folder?

public repositories:
==
all jars and model declarators should be discoverable in one of these public 
repositories
maven  https://central.maven.org/
anthttps://repo1.maven.org/maven2/ant/
gradle   https://repo.maven.apache.org/maven2/

local repositories:
=
during a build you will find jars (or redirects) being downloaded to local 
repository such as
maven $user.home/.m2/repository
gradle $user.home/.gradle/caches
ant $user.home/.ant/lib

but be aware gradle likes to reference module name instead of using gav maven 
coords
so say you are compiling minecraft

$user.home/.gradle/caches/minecraft/net/minecraftforge/forge/

be aware the label that gradle will reference to fetch from caches is 
'minecraft'

but adding 'mincecraft' to gradle varies based on which ide you use..reference:
https://stackoverflow.com/questions/53931937/how-to-include-module-to-the-project



[https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-i...@2.png?v=73d79a89bded]
android - How to include module to the project? - Stack 
Overflow
Clone the repository which you want to be included as a module. Provide the 
path of your cloned repository. Now suppose if I want to include Calendar 
module to my project.
stackoverflow.com

resolving version:
=
plugins and dependency without versions in maven default to latest so in maven 
land
com.erickson
erick-1.0
-1.1

 com.erickson
erick

would pull 1.1 version (latest-version) from central repository(s)

when version not specified gradle will apparently resolves to newest (latest 
modification date) e.g.
com.erickson
 -erick
   -1.0 modification date 11/16/2019
   -1.1 modification date 11/01/2019
sans version gradle will auto-select the latest mod-date (version of 1.0 
version)

as this is clear as mud i invite correction

does this help?
M-


From: Erick Erickson 
Sent: Friday, November 15, 2019 9:44 PM
To: dev@lucene.apache.org 
Subject: Anyone interested in the Gradle build, please comment on SOLR-13915

In a nutshell, it doesn’t look like there’s any task that populates:

../solr/server/solr-webapp/webapp/WEB-INF/lib/
../solr/server/lib/ext/
../solr/server/lib/

with jar files. So "solr/bin/solr start” simply can’t start since it defines 
CLASSPATH to point to them. Before I try to mimic the Ant build that populates 
these, should we re-think how these are populated and/or where they live?

“gradlew assemble” pulls the jars down, but I sure can’t find anywhere where 
that task is defined, and the Gradle javadocs say things like:

assemble() - Method in class org.gradle.language.assembler.tasks.Assemble

Assemble - Class in org.gradle.language.assembler.tasks
Translates Assembly language source files into object files.

so I haven’t a clue what’s up with that task.

Thanks,
Erick
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Gradle build

[Martin Gainty]

if for no other reason than to standardise on a sane trunk everyone can work on
+1 for backport to 8



From: Erick Erickson 
Sent: Saturday, November 9, 2019 10:41 AM
To: dev@lucene.apache.org 
Subject: Re: Gradle build

OK, see SOLR-13914. I figure to close SOLR-13452 after I push to master, it’s 
too long.

To Cassandra’s point: I fully sympathize for two reasons:

1> the more we all can use Gradle all the time, the faster it’ll get into its 
final shape

2> the longer we have to add patches, the harder it’ll be to backport

Therefore I’m going to push for back-porting Real Soon Now, next weekend if 
possible. As soon as we have evidence that the Gradle build doesn’t break Solr, 
i.e. Jenkins master builds using Ant don’t start breaking due to this, I 
propose to back-port to 8x.

Let the fun begin!

Erick

> On Nov 8, 2019, at 8:30 PM, Gus Heck  wrote:
>
> +1 to option 2
>
> On Thu, Nov 7, 2019 at 6:23 PM David Smiley  wrote:
>
> Doing 2 doesn’t stop us going to 3 soon if we want.  Easier to fix/improve on 
> one branch while it’s new.
>
> On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand  wrote:
> I'd be fine with option 2 but I have a slight preference for option 3.
> If we see the Gradle build as the future default build, then we need
> to start using it and I wonder that having to use a different workflow
> on branch_8x would be an incentive to keep using the Ant build
> instead.
>
> On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett  
> wrote:
> >
> > I’m fine with Option 2.
> >
> > Putting my project manager hat on, I’d really like to see a central list or 
> > Jira issues of the things we want to make sure to do before we can turn off 
> > Ant. The list/sub-tasks could be compiled after it’s merged to master, but 
> > it would be nice if we could approach this in a coordinated way so we’re 
> > all able to figure out quickly what remains - I think we’ll have a higher 
> > chance of faster success that way. Hopefully also people would sign up for 
> > the things that they will volunteer to drive to completion instead of 
> > hanging back because they aren’t sure what needs to be done.
> >
> > Dawid and I worked on the Ref Guide transition to Gradle in a separate 
> > branch and it’s either finished or very close to it IMO. It includes the PR 
> > I put up last night to remove the PDF build tasks. I just need to merge it 
> > into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to 
> > do by tomorrow.
> >
> > Cassandra
> > On Nov 6, 2019, 3:07 PM -0600, David Smiley , 
> > wrote:
> >
> > Option 2.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson  
> > wrote:
> >>
> >> All:
> >>
> >> re: SOLR-13452. I’m now coming down on both sides of the issue. My motive 
> >> here is if this was pushed, even in its current incomplete state, people 
> >> would have an easier time contributing to the effort. Of course this means 
> >> I would be asking people to use the gradle build at least on master if at 
> >> all possible.
> >>
> >> There are several assumptions I’m making here:
> >>
> >> - we can keep running the Ant build as long as necessary. Ant would be our 
> >> primary build process. The purpose of pushing the current Gradle effort is 
> >> to make it easier for others to contribute and “just try it”.
> >>
> >> - There are no conflicts between the Gradle and Ant builds, so we can 
> >> continue to use Ant as necessary until we make the switch.
> >>
> >> - people will commit up front to putting some effort into this. I flat 
> >> guarantee I won’t carry the load alone. If nobody else steps up, I’ll 
> >> table it. I will volunteer to push fixes from non-committers.
> >> — Yes, people can do this already with the gradle_8 branch, it’d just be 
> >> easier if it was already in the pull.
> >>
> >> - moving to Gradle as our primary workflow won’t happen until we work out 
> >> some of the kinks, things like.
> >> — running on Jenkins.
> >> — Getting the equivalent of “ant server dist” to run.
> >> — Getting the ref guide built.
> >> — I’m sure other things will crop up.
> >>
> >>
> >> So there are several options, please let me know which one you prefer:
> >>
> >> 1. do nothing. People can check out the gradle_8 build and work on it. 
> >> There has been some of this so far, many thanks.
> >>
> >> 2. merge it into master only. TBD is when we take Ant out of master.
> >>
> >> 3. merge into both master and 8x. Assuming we can continue to use both, 
> >> I’m not sure what advantage there is to merging into 8x. This seems like 
> >> something that should come along with a major version release.
> >>
> >> 4. wait until it’s feature-complete. Based on the evidence so far, this 
> >> may be a long time coming.
> >>
> >> Also, the timing is fungible. I don’t see a downside as long as we can 
> >> continue to build with Ant. I certainly _do_ see a downside 

Re: dtd anomaly

[Martin Gainty]

if i delete the invalid host DTD
ENTITY_TermQuery.xml from xslt input folder everything works

thanks uwe

From: Uwe Schindler 
Sent: Monday, November 4, 2019 8:04 AM
To: dev@lucene.apache.org 
Subject: Re: dtd anomaly

This job is ran on every ant build on Jenkins so there is no problem. This task 
you mentioned does not even read that xml file, unless it's somehow misplaced 
in your build directory and detected as build.xml.

We know that there is a bug with ant 1.10 but that was something else as far as 
I remember. Official Ant version to build is 1.8.2, but later ones also work.

Please clean up your build directory (or checkout a new one).

Uwe

Am November 4, 2019 12:07:46 PM UTC schrieb Martin Gainty :
having used xsl parsing in other projects to create HTML I am attempting to
run the ant build script lucene/build.xml
  
  
  
  
  
  
  
  


but the build errors out on lucene\src\main\xml\ENTITY_TermQuery.xml
attempting to find the Unknown host www.bar.xyz<http://www.bar.xyz> in

so maybe my ant 1.10 is too old to parse the input xml?
i tried running xsl thru maven xml-maven-plugin





From: Uwe Schindler 
Sent: Monday, November 4, 2019 6:06 AM
To: dev@lucene.apache.org 
Subject: RE: dtd anomaly


Hi,



I am wondering what you are doing. If you run “ant documentation” from Solr’s 
or Lucene’s root folder, it should not even read those files – they are only 
relevant for the XML queryparser. Could it be that you have accidentally copied 
into some other folder where they are caught by some filename pattern? IMHO, 
the files should only be in XML query parser, but not in Lucene’s core.



The files are there to test correct handling of external entities so they 
should be in some test folder.



What are you exactly doing?



Uwe



-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de



From: Martin Gainty 
Sent: Monday, November 4, 2019 11:54 AM
To: dev@lucene.apache.org
Subject: dtd anomaly



here is a bug i cannot shake in when building lucene/site

inside lucene/src/main/xml/ENTITY_TermQuery.xml





http://www.bar.xyz/external;>

http://www.bar.xyz/param;>


using ant build.xml:
 



  

  

  

  

  

  

  





OR maven pom.xml

  

org.codehaus.mojo

   xml-maven-plugin

   1.0.1

   



 validate

initialize



 transform





   true

   false

   
${project.build.directory}/target

 

   

  src/main/xml

  C:/Maven-plugin/lucene-solr/lucene/site/xsl/index.xsl

  

   

 MyParam

 true

   

   

   

 

   

   

   

   



 net.sf.saxon

 Saxon-HE

 9.9.1-1



   

  



either build executing XSLT i get the same error:

[ERROR] Failed to execute goal 
org.codehaus.mojo:xml-maven-plugin:1.0.1:transform (validate) on project 
analysis: Failed to transform input file 
lucene/src/main/xml/ENTITY_TermQuery.xml: I/O error reported by XML parser 
processing file://lucene/src/main/xml/ENTITY_TermQuery.xml: 
www.bar.xyz<http://www.bar.xyz>:
Unknown host www.bar.xyz<http://www.bar.xyz>

]>

apparently www.bar.xyz<http://www.bar.xyz/> host is supposed to be a placeholder
but for the life of me I cannot see where www.bar.zyz<http://www.bar.zyz/> 
placeholder is replaced by a valid URL

(i havent used DTD in at least 10 years and i am way out of my element when 
trying to resolve)
any suggestions?

martin



--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: dtd anomaly

[Martin Gainty]

but using xml-maven-plugin i got the same error with maven as i did ant
  
org.codehaus.mojo
   xml-maven-plugin
   1.0.1
   

 validate
initialize

 transform


   true
   false
   
${project.build.directory}/target
 
   
  src/main/xml
  C:/Maven-plugin/lucene-solr/lucene/site/xsl/index.xsl
  
   
 MyParam
 true
   
   
   
 
   
   
   
   

 net.sf.saxon
 Saxon-HE
 9.9.1-1

   
  


this is not my build and not my xml so the attempt here is to run
the entire build from start to finish with no errors
if i can get either ant or maven xsl to accept host declaration 
www.bar.xyz<http://www.bar.xyz> then
the entire build will be successful

can we delete lucene\src\main\xml\ENTITY_TermQuery.xml ?
or at least deprecate lucene\src\main\xml\ENTITY_TermQuery.xml ?

if we need to retain lucene\src\main\xml\ENTITY_TermQuery.xml
can we change the offending host declaration: www.bar.xyz<http://www.bar.xyz/>
or edit out these invalid host declarations?

thanks
martin-

____
From: Martin Gainty 
Sent: Monday, November 4, 2019 7:07 AM
To: dev@lucene.apache.org 
Subject: Re: dtd anomaly

having used xsl parsing in other projects to create HTML I am attempting to
run the ant build script lucene/build.xml
  
  
  
  
  
  
  
  


but the build errors out on lucene\src\main\xml\ENTITY_TermQuery.xml
attempting to find the Unknown host www.bar.xyz<http://www.bar.xyz> in

so maybe my ant 1.10 is too old to parse the input xml?
i tried running xsl thru maven xml-maven-plugin





From: Uwe Schindler 
Sent: Monday, November 4, 2019 6:06 AM
To: dev@lucene.apache.org 
Subject: RE: dtd anomaly


Hi,



I am wondering what you are doing. If you run “ant documentation” from Solr’s 
or Lucene’s root folder, it should not even read those files – they are only 
relevant for the XML queryparser. Could it be that you have accidentally copied 
into some other folder where they are caught by some filename pattern? IMHO, 
the files should only be in XML query parser, but not in Lucene’s core.



The files are there to test correct handling of external entities so they 
should be in some test folder.



What are you exactly doing?



Uwe



-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de



From: Martin Gainty 
Sent: Monday, November 4, 2019 11:54 AM
To: dev@lucene.apache.org
Subject: dtd anomaly



here is a bug i cannot shake in when building lucene/site

inside lucene/src/main/xml/ENTITY_TermQuery.xml





http://www.bar.xyz/external;>

http://www.bar.xyz/param;>


using ant build.xml:
 



  

  

  

  

  

  

  





OR maven pom.xml

  

org.codehaus.mojo

   xml-maven-plugin

   1.0.1

   



 validate

initialize



 transform





   true

   false

   
${project.build.directory}/target

 

   

  src/main/xml

  C:/Maven-plugin/lucene-solr/lucene/site/xsl/index.xsl

  

   

 MyParam

 true

   

   

   

 

   

   

   

   



 net.sf.saxon

 Saxon-HE

 9.9.1-1



   

  



either build executing XSLT i get the same error:

[ERROR] Failed to execute goal 
org.codehaus.mojo:xml-maven-plugin:1.0.1:transform (validate) on project 
analysis: Failed to transform input file 
lucene/src/main/xml/ENTITY_TermQuery.xml: I/O error reported by XML parser 
processing file://lucene/src/main/xml/ENTITY_TermQuery.xml: 
www.bar.xyz<http://www.bar.xyz>:
Unknown host www.bar.xyz<http://www.bar.xyz>

]>

apparently www.bar.xyz<http://www.bar.xyz/> host is supposed to be a placeholder
but for the life of me I cannot see where www.bar.zyz<http://www.bar.zyz/> 
placeholder is replaced by a valid URL

(i havent used DTD in at least 10 years and i am way out of my element when 
trying to resolve)
any suggestions?

martin

Re: dtd anomaly

[Martin Gainty]

having used xsl parsing in other projects to create HTML I am attempting to
run the ant build script lucene/build.xml
  
  
  
  
  
  
  
  


but the build errors out on lucene\src\main\xml\ENTITY_TermQuery.xml
attempting to find the Unknown host www.bar.xyz<http://www.bar.xyz> in

so maybe my ant 1.10 is too old to parse the input xml?
i tried running xsl thru maven xml-maven-plugin





From: Uwe Schindler 
Sent: Monday, November 4, 2019 6:06 AM
To: dev@lucene.apache.org 
Subject: RE: dtd anomaly


Hi,



I am wondering what you are doing. If you run “ant documentation” from Solr’s 
or Lucene’s root folder, it should not even read those files – they are only 
relevant for the XML queryparser. Could it be that you have accidentally copied 
into some other folder where they are caught by some filename pattern? IMHO, 
the files should only be in XML query parser, but not in Lucene’s core.



The files are there to test correct handling of external entities so they 
should be in some test folder.



What are you exactly doing?



Uwe



-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

https://www.thetaphi.de

eMail: u...@thetaphi.de



From: Martin Gainty 
Sent: Monday, November 4, 2019 11:54 AM
To: dev@lucene.apache.org
Subject: dtd anomaly



here is a bug i cannot shake in when building lucene/site

inside lucene/src/main/xml/ENTITY_TermQuery.xml





http://www.bar.xyz/external;>

http://www.bar.xyz/param;>


using ant build.xml:
 



  

  

  

  

  

  

  





OR maven pom.xml

  

org.codehaus.mojo

   xml-maven-plugin

   1.0.1

   



 validate

initialize



 transform





   true

   false

   
${project.build.directory}/target

 

   

  src/main/xml

  C:/Maven-plugin/lucene-solr/lucene/site/xsl/index.xsl

  

   

 MyParam

 true

   

   

   

 

   

   

   

   



 net.sf.saxon

 Saxon-HE

 9.9.1-1



   

  



either build executing XSLT i get the same error:

[ERROR] Failed to execute goal 
org.codehaus.mojo:xml-maven-plugin:1.0.1:transform (validate) on project 
analysis: Failed to transform input file 
lucene/src/main/xml/ENTITY_TermQuery.xml: I/O error reported by XML parser 
processing file://lucene/src/main/xml/ENTITY_TermQuery.xml: 
www.bar.xyz<http://www.bar.xyz>:
Unknown host www.bar.xyz<http://www.bar.xyz>

]>

apparently www.bar.xyz<http://www.bar.xyz/> host is supposed to be a placeholder
but for the life of me I cannot see where www.bar.zyz<http://www.bar.zyz/> 
placeholder is replaced by a valid URL

(i havent used DTD in at least 10 years and i am way out of my element when 
trying to resolve)
any suggestions?

martin

dtd anomaly

[Martin Gainty]

here is a bug i cannot shake in when building lucene/site

inside lucene/src/main/xml/ENTITY_TermQuery.xml



http://www.bar.xyz/external;>
http://www.bar.xyz/param;>


using ant build.xml:
 

  
  
  
  
  
  
  


OR maven pom.xml
  
org.codehaus.mojo
   xml-maven-plugin
   1.0.1
   

 validate
initialize

 transform


   true
   false
   
${project.build.directory}/target
 
   
  src/main/xml
  C:/Maven-plugin/lucene-solr/lucene/site/xsl/index.xsl
  
   
 MyParam
 true
   
   
   
 
   
   
   
   

 net.sf.saxon
 Saxon-HE
 9.9.1-1

   
  

either build executing XSLT i get the same error:

[ERROR] Failed to execute goal 
org.codehaus.mojo:xml-maven-plugin:1.0.1:transform (validate) on project 
analysis: Failed to transform input file 
lucene/src/main/xml/ENTITY_TermQuery.xml: I/O error reported by XML parser 
processing file://lucene/src/main/xml/ENTITY_TermQuery.xml: www.bar.xyz:
Unknown host www.bar.xyz
]>

apparently www.bar.xyz host is supposed to be a placeholder
but for the life of me I cannot see where www.bar.zyz 
placeholder is replaced by a valid URL

(i havent used DTD in at least 10 years and i am way out of my element when 
trying to resolve)
any suggestions?
martin

Re: SolrCloud is sick.

[Martin Gainty]

here is a bug i cannot shake in when building lucne/site

inside lucene/src/main/xml/ENTITY_TermQuery.xml



http://www.bar.xyz/external;>
http://www.bar.xyz/param;>


using ant build.xml:
 

  
  
  
  
  
  
  


OR maven pom.xml
  
org.codehaus.mojo
   xml-maven-plugin
   1.0.1
   

 validate
initialize

 transform


   true
   false
   
${project.build.directory}/target
 
   
  src/main/xml
  C:/Maven-plugin/lucene-solr/lucene/site/xsl/index.xsl
  
   
 MyParam
 true
   
   
   
 
   
   
   
   

 net.sf.saxon
 Saxon-HE
 9.9.1-1

   
  

either build executing XSLT i get the same error:

[ERROR] Failed to execute goal 
org.codehaus.mojo:xml-maven-plugin:1.0.1:transform (validate) on project 
analysis: Failed to transform input file 
lucene/src/main/xml/ENTITY_TermQuery.xml: I/O error reported by XML parser 
processing file://lucene/src/main/xml/ENTITY_TermQuery.xml: www.bar.xyz:
Unknown host www.bar.xyz
]>

apparently www.bar.xyz host is supposed to be a placeholder
but for the life of me I cannot see where www.bar.zyz 
placeholder is replaced by a valid URL

(i havent used DTD in at least 10 years and i am way out of my element when 
trying to resolve)
any suggestions?
martin

From: David Smiley 
Sent: Sunday, November 3, 2019 12:32 AM
To: Solr/Lucene Dev 
Cc: Mark Miller 
Subject: Re: SolrCloud is sick.

Yeah we do a bad job of the things you listed Noble.  :-(   My colleagues want 
pointers to internal docs but the sad reality is there isn't any.  You may 
notice I'm a stickler in my code reviews for requiring javadocs on all top 
level classes.  I think more javadocs and code comments would be very helpful 
-- especially for the major classes.  This might help us all and others a lot 
more.  For example I think Lucene does a rather fine job of this for its major 
classes -- IndexWriter being a good example.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Sat, Nov 2, 2019 at 7:32 PM Noble Paul 
mailto:noble.p...@gmail.com>> wrote:
Hi,

I believe there is a consensus on what is wrong with the way we have built the 
cluster state and overseer. We need to focus a bit more on the design aspect. 
Design, according to me, has the following elements:

* How does it work?

* What are the performance characteristics? Can it be done more efficiently?

* What are the public touch points?

** Which are the files we store in ZK? Are they expected to be watched always?

** Or are they read on demand?

** The public APIs. Does it make sense to the user? Can it be further 
simplified? How does it compare to the other APIs in the system?


We, as a community, do a bad job in dealing with these. While we focus on 
internal things, these are not discussed before it is too late. We usually do 
coding, tests, code review (sometimes) and commit. This leads to huge technical 
debt.


This is not to put blame on one person or a group of people. (I occasionally 
see people discussing design issues upfront, I just hope that is the norm.)


Now, why am I discussing this in this thread?


While we agree there are problems, we are trying to solve the problem using the 
same process we used to create these problems. Again, I'm not questioning the 
intent or competence of anyone. Unless we set the process right, we are doomed 
to make the same mistakes again.


I whole heartedly endorse any effort to improve SolrCloud/overseer. At the same 
time I fail to see us leveraging the collective experience of our community 
through meaningful discussion.


I hope we don't resort to personal attacks and use this as an opportunity to 
improve our processes.
Thanks

On Sun, Nov 3, 2019, 9:52 AM Scott Blum 
mailto:dragonsi...@gmail.com>> wrote:
Very much agreed.  I've been trying to figure out for a long time what is the 
point in having a replica DOWN state that has to be toggled (DOWN and then UP!) 
every time a node restarts.  Considering that we could just combine ACTIVE and 
`live_nodes` to understand whether a replica is available.  It's not even 
foolproof since kill -9 on a solr node won't mark all the replicas DOWN-- that 
doesn't happen until the node comes back up (perversely).

What would it take to get to a state where restarting a node would require a 
minimal amount of ZK work in most cases?

On Sat, Nov 2, 2019 at 5:44 PM Mark Miller 
mailto:markrmil...@gmail.com>> wrote:
Give me a short bit to follow up and I will lay out my case and proposal.

Everyone is then free to decide that we need to do something drastic or that 
I'm 

Re: The Lucene Solr Gradle Build Game plan

[Martin Gainty]

agree with david
as your schedule gets packed there are more than a few that are willing to 
pickup the slack
if the branch is checked-in and labelled we can tackle what needs to be done

From: David Smiley 
Sent: Monday, October 21, 2019 2:13 AM
To: Mark Miller 
Cc: Lucene Dev 
Subject: Re: The Lucene Solr Gradle Build Game plan

Thanks for your efforts Mark!

Why has the migration to Gradle somehow been blocked by performance 
improvements to Solr's tests?
What are the blockers to the Gradle branch being merged to master?  It's an 
experimental shadow build, so... none?

I appreciate you want everything to be great from the beginning but I think 
it's better to try and find that subjective line where it's good enough to be 
committed then iterated on in follow-up issues.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Mon, Oct 21, 2019 at 1:30 AM Mark Miller 
mailto:markrmil...@gmail.com>> wrote:
Hello Dawid, I'm sorry about the absence. I had a two week trip to SF and that 
tends to steal my mind, thank god something does.

Yes, I have local changes that you should likely wait for.

There is a substantial issue with how I was mapping our directory names to 
project names. That issue led to allowing some funny things and so addressing 
it makes the build a bit to a lot less silly. Sorry Tomoko Uchida :(

Anyway, I had to pause Gradle when I remembered that Solr tests are only slow 
for silly or broken reasons.

So I worked on that and then I remember that about a year and a half ago I had 
realized SolrCloud was seriously rotting in come very core and key areas. At 
the time I spent a lot of effort on my Starburst branch addressing some 
fundamental problems and patterns. I then had a 6 week sabbatical and 3 week 
movie making trip. Though my own lack of care, I lost all that work and mostly 
forgot about the whole thing.

Coming back to that, after wasting a lot of effort trying to find my previous 
work, I set off to duplicate that work and hopefully take it a bit further. I 
really can't work on anything unless until that is on a clear path to being 
addressed unless someone attached to my livelihood forces me.

Meanwhile, I'll be gone half of November on across the world vacation and 
December is always a mess.

On the plus side, the gradle build has gotten some great testing, but I'm 
little fuzzy on when I'm ready. I will certainly be separating out these 
efforts. So I'll be extracting the gradle changes to the gradle branch and 
keeping my new state as a separate branch.

- Mark

Re: Re:Welcome Kevin Risden to the PMC

[Martin Gainty]

welcome Kevin!


From: Christine Poerschke (BLOOMBERG/ LONDON) 
Sent: Friday, June 28, 2019 4:00 PM
To: dev@lucene.apache.org
Subject: Re:Welcome Kevin Risden to the PMC

Welcome Kevin!

From: dev@lucene.apache.org At: 06/27/19 13:04:23
To: dev@lucene.apache.org
Subject: Welcome Kevin Risden to the PMC

I am pleased to announce that Kevin Risden has accepted the PMC's invitation to
join.

Welcome Kevin!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com


-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Martin Gainty]

Удачи Майкл!


From: Erick Erickson 
Sent: Monday, May 13, 2019 4:11 PM
To: dev@lucene.apache.org
Subject: Re: Welcome Michael Sokolov as Lucene/ Solr committer

Welcome Michael!

> On May 13, 2019, at 2:48 PM, Dawid Weiss  wrote:
>
>> I am pretty sure my first interaction with the Apache Solr/Lucene community 
>> was back in 2012,
>
> Yeah... I really don't know how it happened you haven't been
> invited earlier. Everyone just kind of assumed you
> have committer rights already! :)
>
>
> D.
>
> On Mon, May 13, 2019 at 9:23 PM Michael Sokolov  wrote:
>>
>> Thanks Dawid, and thank you to everyone who voted to grant me access
>> to this awesome project!
>>
>> I spent many years building full text search web applications serving
>> large texts (especially dictionaries, encyclopedias, and academic
>> journals). I cut my teeth with AltaVista back in 1998, and tried many
>> other search engines before finally coming around to Solr/Lucene.
>>
>> I am pretty sure my first interaction with the Apache Solr/Lucene
>> community was back in 2012, when I was looking to solve a performance
>> problem we encountered highlighting gigantic documents. Since then
>> I've worked on many projects involving Solr and Lucene, and
>> ElasticSearch, and made various contributions, implemented some of my
>> own extensions, made a separate XML query engine based on Solr (Lux -
>> no longer active), went to a few Lucene/Solr Revolutions (spoke at
>> one), and always in the back of my mind was the idea of contributing
>> more actively and becoming a full participant in this thriving open
>> source project. Now I'm really excited that has come to pass, and look
>> forward to digging in even deeper, and helping to keep this thing
>> going.
>>
>> -Mike
>>
>> On Mon, May 13, 2019 at 3:12 PM Dawid Weiss  wrote:
>>>
>>> Hello everyone,
>>>
>>> Please join me in welcoming Michael Sokolov as Lucene/ Solr committer!
>>>
>>> Many of you probably know Mike as he's been around for quite a while
>>> -- answering questions, reviewing patches, providing insight and
>>> actively working on new code.
>>>
>>> Congratulations and welcome! It is a tradition to introduce yourself
>>> with a brief bio, Mike.
>>>
>>> Dawid
>
> -
> 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: Socket Timeouts

[Martin Gainty]

both connectionTimeout and socketTimeout are declared in $SOLR_HOME/solr.xml

 
${socketTimeout:60}
${connTimeout:6}
  





From: Gus Heck 
Sent: Sunday, May 5, 2019 1:35 PM
To: dev
Subject: Socket Timeouts

I'm working with a client that's trying to process a lot of data (billions of 
docs) via a streaming expression, and the initial query is (not surprisingly) 
taking a long time. Lots of various types of timeouts have been cropping up and 
I've found myself thinking I solved some only to discover that the settings in 
solr.xml are far less wide reaching than I thought initially. The present 5% 
scale cluster seems to hit one particular time out about 50% of the time which 
has made it particularly confusing. I'm guessing it's probably depending on 
something like how busy the virtualization in Amazon is, just barely making it 
when it gets more resources and timing out if anything is starved.

As I look around the code base I'm finding a LOT of places where timeouts on 
SolrClients and CloudSolrClients are just arbitrarily set to one-off constant 
values. The one bugging me right now is

public abstract class SolrClientBuilder> {

  protected HttpClient httpClient;
  protected ResponseParser responseParser;
  protected Integer connectionTimeoutMillis = 15000;
  protected Integer socketTimeoutMillis = 12;

Which I am unable to change because of this code in SolrStream:

  /**
  * Opens the stream to a single Solr instance.
  **/
  public void open() throws IOException {
if(cache == null) {
  client = new HttpSolrClient.Builder(baseUrl).build();
} else {
  client = cache.getHttpSolrClient(baseUrl);
}

I need to make this particular case configurable, so that I can get results 
from a very long running query, but I sense that there is a much wider problem 
in that we don't seem to have any organized plan for how socket timeouts are 
set/managed in the code.

What thoughts have people had on this front?

-Gus

--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: Re: Authorization fails but api still renders

[Martin Gainty]

Jeremy-
the problem is your DNS lookup algorithm/service

as a test add the missing FQDN to etc/hosts..as a test I would add "localhost" 
to 192.168.1.1
https://www.linuxquestions.org/questions/slackware-14/hostname-fqdn-etc-hosts-setup-302189/
[http://images.linuxquestions.org/lqthumb.png]

hostname, fqdn, /etc/hosts setup - 
linuxquestions.org
Introduction to Linux - A Hands on Guide This guide was created as an overview 
of the Linux Operating System, geared toward new users as an exploration tour 
and getting started guide, with exercises at the end of each chapter.
www.linuxquestions.org



if that works
then populate etc/BIND or whatever nameserver-lookup service that resolves FQDN
https://serverfault.com/questions/18748/overriding-some-dns-entries-in-bind-for-internal-networks
[https://cdn.sstatic.net/Sites/serverfault/img/apple-touch-i...@2.png?v=9b1f48ae296b]

Overriding some DNS entries in BIND for internal networks - Server 
Fault
Stack Exchange network consists of 175 Q communities including Stack 
Overflow, the largest, most trusted online community for developers to learn, 
share their knowledge, and build their careers.. Visit Stack Exchange
serverfault.com



restart BIND service and restart lucene and test your localhost

HTH


From: Branham, Jeremy (Experis) 
Sent: Friday, March 15, 2019 10:18 AM
To: solr-u...@lucene.apache.org
Cc: dev@lucene.apache.org
Subject: Re: Re: Authorization fails but api still renders

// Adding the dev DL, as this may be a bug

Solr v7.7.0

I’m expecting the 401 on all the servers in all 3 clusters using the security 
configuration.
For example, when I access the core or collection APIs without authentication, 
it should return a 401.

On one of the servers, in one of the clusters, the authorization is completely 
ignored. The http response is 200 and the API returns results.
The other server in this cluster works properly, returning a 401 when the 
protected API is accessed without authentication.

Interesting notes –
- If I use the IP or FQDN to access the server, authorization works properly 
and a 401 is returned. It’s only when I use the short hostname to access the 
server, that the authorization is bypassed.
- On the broken server, a 401 is returned correctly when the ‘autoscaling 
suggestions’ api is accessed. This api uses a different resource path, which 
may be a clue to why the others fail.
  https://solr:8443/api/cluster/autoscaling/suggestions

Here is the security.json with sensitive data changed/removed –

{
"authentication":{
   "blockUnknown": false,
   "class":"solr.BasicAuthPlugin",
   "credentials":{
 "admin":"--REDACTED--",
 "reader":"--REDACTED--",
 "writer":"--REDACTED--"
   },
   "realm":"solr"
},
"authorization":{
   "class":"solr.RuleBasedAuthorizationPlugin",
   "permissions":[
 {"name":"security-edit", "role":"admin"},
 {"name":"security-read", "role":"admin"},
 {"name":"schema-edit", "role":"admin"},
 {"name":"config-edit", "role":"admin"},
 {"name":"core-admin-edit", "role":"admin"},
 {"name":"collection-admin-edit", "role":"admin"},
 {"name":"autoscaling-read", "role":"admin"},
 {"name":"autoscaling-write", "role":"admin"},
 {"name":"autoscaling-history-read", "role":"admin"},
 {"name":"read","role":"*"},
 {"name":"schema-read","role":"*"},
 {"name":"config-read","role":"*"},
 {"name":"collection-admin-read", "role":"*"},
 {"name":"core-admin-read","role":"*"},
 {"name":"update", "role":"write"},
 {"collection":null, "path":"/admin/info/system", "role":"admin"}
   ],
   "user-role":{
 "admin": "admin",
 "reader": "read",
 "writer": "write"
   }
}}



Jeremy Branham
jb...@allstate.com

On 3/14/19, 10:06 PM, "Zheng Lin Edwin Yeo"  wrote:

Hi,

Can't really catch your question. Are you facing the error 401 on all the
clusters or just one of them?

Also, which Solr version are you using?

Regards,
Edwin

On Fri, 15 Mar 2019 at 05:15, Branham, Jeremy (Experis) 
wrote:

> I’ve discovered the authorization works properly if I use the FQDN to
> access the Solr node, but the short hostname completely circumvents it.
> They are all internal server clusters, so I’m using self-signed
> certificates [the same exact certificate] on each. The SAN portion of the
> cert contains the IP, short, and FQDN of each server.
>
> I also diff’d the two servers Solr installation directories, and confirmed
> they are identical.
> They are using the same exact versions of Java and zookeeper, with 

Re: Security Contact for Solr?

[Martin Gainty]

svan-

BECAUSE solr can deploy to n number of containers
Jetty/Tomcat/Docker/Websphere/Weblogic (i'm certain i have  omitted a few 
implementation containers)
Implementing comprehensive PKI Infrastructure is heavily dependent on the 
container solr is deployed to

i have  a few spare cycles to help out if need be

martin-


From: s...@apple.com  on behalf of Sven Blumenstein 

Sent: Thursday, March 7, 2019 3:24 PM
To: dev@lucene.apache.org
Subject: Security Contact for Solr?

Hi .*,

what is the proper contact for reporting security vulnerabilities in Solr? Do 
you have a security@ address or a non-public mailing list/bug component? 
Unfortunately I could not find any information in that regard on the Solr 
website, hence my reach out to this mailing list.

Thanks!


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Call for help: moving from ant build to gradle

[Martin Gainty]

your argument that gradle is faster than maven is based on internal caching 
algorithm that gradle references

IF you are *NOT* politically endangered from implementing maven i encourage you 
to take a hard look at

"implementing caching of maven artifacts using cache-proxies"
https://support.sonatype.com/hc/en-us/articles/115010182627-Understanding-Caching-Configuration
[https://theme.zdassets.com/theme_assets/17748/b23a916dda693a523d66cc6230806788eaa710b6.png]

Understanding Caching Configuration – Sonatype 
Support
Proxy repositories use caching to improve build performance. The settings you 
can use to configure caching are described in this article
support.sonatype.com


as you can see speed is achieved when local proxy-cache is referenced BEFORE 
far-flung remote repositories

by properly tuning local cache-proxies you can bypass high-latency remote 
repositories and "accelerate your build process"

/greets/
martin-

From: Gézapeti 
Sent: Monday, March 4, 2019 5:45 PM
To: dev@lucene.apache.org
Cc: markrmil...@gmail.com
Subject: Re: Call for help: moving from ant build to gradle

I'd be happy to help with the gradle migration.
I could not find a jira that covers it, only LUCENE-5755, which was closed a 
long time ago.
Where can I join the discussion about this?

Thanks for the pointers,
gp


On Thu, Feb 7, 2019 at 8:23 PM Vladimir Kroz 
mailto:vladimir.k...@gmail.com>> wrote:
+1 for moving to gradle. I'm happy to help.

On Wed, Dec 19, 2018 at 8:25 AM Mark Miller 
mailto:markrmil...@gmail.com>> wrote:
+1. Gradle is the alpha and the omega of build systems. I will help.

- Mark

On Sun, Nov 4, 2018 at 1:13 PM Đạt Cao Mạnh 
mailto:caomanhdat...@gmail.com>> wrote:
Hi guys,

Recently, I had a chance of working on modifying different build.xml of our 
project. To be honest that was a painful experience, especially the number of 
steps for adding a new module in our project. We reach the limitation point of 
Ant and moving to Gradle seems a good option since it has been widely used in 
many projects. There are several benefits of the moving here that I would like 
to mention
* The capability of caching result in Gradle make running task much faster. 
I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing to 
more than a minute of Ant).
* Adding modules is much easier now.
* Adding dependencies is a pleasure now since we don't have to run ant 
clean-idea and ant idea all over again.
* Natively supported by different IDEs.

On my very boring long flight from Montreal back to Vietnam, I tried to convert 
the Lucene/Solr Ant to Gradle, I finally achieved something here by being able 
to import project and run tests natively from IntelliJ IDEA (branch 
jira/gradle).

I'm converting ant precommit for Lucene to Gradle. But there are a lot of 
things need to be done here and my limitation understanding in our Ant build 
and Gradle may make the work take a lot of time to finish.

Therefore, I really need help from the community to finish the work and we will 
be able to move to a totally new, modern, powerful build tool.

Thanks!



--
- Mark

http://about.me/markrmiller


--
Best regards,

Vladimir Kroz
www.linkedin.com/in/vkroz
Phone: (707) 515-9195

Re: Welcome Ignacio Vera to the PMC

[Martin Gainty]

¡Bienvenidos Ignacio!


From: Dawid Weiss 
Sent: Monday, March 4, 2019 6:45 AM
To: dev@lucene.apache.org
Subject: Re: Welcome Ignacio Vera to the PMC

Welcome, Ignacio!

On Mon, Mar 4, 2019 at 10:09 AM Adrien Grand  wrote:
>
> I am pleased to announce that Ignacio Vera has accepted the PMC's
> invitation to join.
>
> Welcome Ignacio!
>
> --
> Adrien
>
> -
> 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: Welcome Jason Gerlowski to the PMC

[Martin Gainty]

Welcome Jason!

martin-

From: David Smiley 
Sent: Friday, February 22, 2019 11:09 AM
To: dev@lucene.apache.org
Subject: Re: Welcome Jason Gerlowski to the PMC

Welcome Jason!

On Fri, Feb 22, 2019 at 11:03 AM Erick Erickson 
mailto:erickerick...@gmail.com>> wrote:
Welcome!

> On Feb 22, 2019, at 7:39 AM, Kevin Risden 
> mailto:kris...@apache.org>> wrote:
>
> Congrats and welcome!
>
> Kevin Risden
>
>
> On Fri, Feb 22, 2019 at 10:31 AM Đạt Cao Mạnh 
> mailto:caomanhdat...@gmail.com>> wrote:
> Welcome, Jason!
>
> On Fri, 22 Feb 2019 at 15:28, Adrien Grand 
> mailto:jpou...@gmail.com>> wrote:
> Welcome, Jason!
>
> On Fri, Feb 22, 2019 at 4:21 PM Jan Høydahl 
> mailto:jan@cominvent.com>> wrote:
> >
> > I am pleased to announce that Jason Gerlowski has accepted the PMC's 
> > invitation to join.
> >
> > Welcome Jason!
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> >
> > -
> > To unsubscribe, e-mail: 
> > dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: 
> > dev-h...@lucene.apache.org
> >
>
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: 
> dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: 
> dev-h...@lucene.apache.org
>
> --
> Best regards,
> Cao Mạnh Đạt
> D.O.B : 31-07-1991
> Cell: (+84) 946.328.329
> E-mail: caomanhdat...@gmail.com


-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

--
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Re: Welcome Nick Knize to the PMC

[Martin Gainty]

Welcome Nick!

From: Erick Erickson 
Sent: Wednesday, January 9, 2019 10:13 AM
To: dev@lucene.apache.org
Subject: Re: Welcome Nick Knize to the PMC

Welcome Nick!

On Wed, Jan 9, 2019 at 7:12 AM Adrien Grand  wrote:
>
> I am pleased to announce that Nick Knize has accepted the PMC's
> invitation to join.
>
> Welcome Nick!
>
> --
> Adrien
>
> -
> 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: [NOTICE] Mandatory migration of git repositories to gitbox.apache.org

[Martin Gainty]

+1

From: David Smiley 
Sent: Thursday, January 3, 2019 8:45 AM
To: dev@lucene.apache.org
Subject: Re: [NOTICE] Mandatory migration of git repositories to 
gitbox.apache.org

I propose we (me) coordinate with them to do this transition on Wednesday next 
week (Jan 9th).  It appears to be a minor inconvenience.  If there are 
problems, we'll have some work days after to deal with it.  And doing this 
ahead of the mass migration may give us more individual attention from the busy 
infra team if there are problems.  Can I get some +1's?

On Thu, Jan 3, 2019 at 8:18 AM Apache Infrastructure Team 
mailto:infrastruct...@apache.org>> wrote:
Hello, lucene folks.
As stated earlier in 2018, all git repositories must be migrated from
the git-wip-us.apache.org URL to 
gitbox.apache.org, as the old service
is being decommissioned. Your project is receiving this email because
you still have repositories on git-wip-us that needs to be migrated.

The following repositories on git-wip-us belong to your project:
 - lucene-solr.git


We are now entering the mandated (coordinated) move stage of the roadmap,
and you are asked to please coordinate migration with the Apache
Infrastructure Team before February 7th. All repositories not migrated
on February 7th will be mass migrated without warning, and we'd appreciate
it if we could work together to avoid a big mess that day :-).

Moving to gitbox means you will get full write access on GitHub as well,
and be able to close/merge pull requests and much more.

To have your repositories moved, please follow these steps:

- Ensure consensus on the move (a link to a 
lists.apache.org thread will
  suffice for us as evidence).
- Create a JIRA ticket at https://issues.apache.org/jira/browse/INFRA

Your migration should only take a few minutes. If you wish to migrate
at a specific time of day or date, please do let us know in the ticket.

As always, we appreciate your understanding and patience as we move
things around and work to provide better services and features for
the Apache Family.

Should you wish to contact us with feedback or questions, please do so
at: us...@infra.apache.org.


With regards,
Apache Infrastructure


-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

--
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Re: Call for help: moving from ant build to gradle

[Martin Gainty]

any reason for discriminating against a build system that supports customised 
lifecycles (e.g. maven)?

un saludo


From: Diego Ceccarelli (BLOOMBERG/ LONDON) 
Sent: Wednesday, November 21, 2018 5:30 AM
To: dev@lucene.apache.org
Subject: Re: Call for help: moving from ant build to gradle

Hi all,

I just noticed this thread I would be happy to help if I can.

I checked out the jira/gradle branch but I get conflicts if I try to rebase on 
top of the current master..

Do you have a list of subtasks for porting solr to gradle?

Thanks,
Diego




From: dev@lucene.apache.org At: 11/05/18 22:34:50
To: dev@lucene.apache.org
Subject: Re: Call for help: moving from ant build to gradle

Edward:

Of course. You may have to coordinate how to get your contributions
added to the patch is all.

I'd coordinate with Dat first though just for efficiency's sake. Just
work with the branch/gradle version of the code from the main Git
repo.
On Mon, Nov 5, 2018 at 2:22 PM Edward Ribeiro 
mailto:edward.ribe...@gmail.com>> wrote:
>
> Is this work open to contribution of non committers?
>
> Edward
>
>
> Em seg, 5 de nov de 2018 15:01, Gus Heck 
> mailto:gus.h...@gmail.com> escreveu:
>>
>> I'm quite fond of gradle, and even wrote a very simple plugin for uploading
and downloading solr configs to zookeeper from gradle. +1 to use gradle.
>>
>> I'll definitely check it out and give it a whirl, maybe I'll help some if I
can.
>>
>> On Sun, Nov 4, 2018 at 2:13 PM Đạt Cao Mạnh 
>> mailto:caomanhdat...@gmail.com>> wrote:
>>>
>>> Hi guys,
>>>
>>> Recently, I had a chance of working on modifying different build.xml of our
project. To be honest that was a painful experience, especially the number of
steps for adding a new module in our project. We reach the limitation point of
Ant and moving to Gradle seems a good option since it has been widely used in
many projects. There are several benefits of the moving here that I would like
to mention
>>> * The capability of caching result in Gradle make running task much faster.
I.e: rerunning forbiddenApi check in Gradle only takes 5 seconds (comparing to
more than a minute of Ant).
>>> * Adding modules is much easier now.
>>> * Adding dependencies is a pleasure now since we don't have to run ant
clean-idea and ant idea all over again.
>>> * Natively supported by different IDEs.
>>>
>>> On my very boring long flight from Montreal back to Vietnam, I tried to
convert the Lucene/Solr Ant to Gradle, I finally achieved something here by
being able to import project and run tests natively from IntelliJ IDEA (branch
jira/gradle).
>>>
>>> I'm converting ant precommit for Lucene to Gradle. But there are a lot of
things need to be done here and my limitation understanding in our Ant build
and Gradle may make the work take a lot of time to finish.
>>>
>>> Therefore, I really need help from the community to finish the work and we
will be able to move to a totally new, modern, powerful build tool.
>>>
>>> Thanks!
>>>
>>
>>
>> --
>> http://www.the111shift.com

-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Welcome Tim Allison as a Lucene/Solr committer

[Martin Gainty]

A much deserved Welcome  to Tim

Would appreciate to understand how Tika can enhance lucene development

Non refert quo imus quod quandiu prodesse autem nemo homini in via..
martin

From: Uwe Schindler 
Sent: Friday, November 2, 2018 2:58 PM
To: dev@lucene.apache.org; Tim Allison
Subject: Re: Welcome Tim Allison as a Lucene/Solr committer

Welcome Tim!

It's great to have you here. Now you can commit Tika patches on your own. Great 
work with maintaining it.

Ah BTW, I am not a Latin and Greek professor, but before doing open source 
stuff with Lucene - in my previous life, I wrote a software for teaching Latin 
language.  You can still find it on German Amazon... 樂 Maybe I should open 
source it at some point. But my former programming experience with Borland 
Delphi should not be consumed by anybody! 

Uwe

Am November 2, 2018 4:40:44 PM UTC schrieb Tim Allison :

Thank you, Erick!  And, thank you, team!

A bit about me...

I've been working in natural language processing since 2002. Over the
last 5+ years, I've focused on advanced search and content/metadata
extraction. Many years ago, David Smiley inspired me "to quit forking
and start patching" and, generally, to grow up and participate in open
source communities.  I'm now the chair/V.P. of Apache Tika, a
committer and PMC member on Apache POI and Apache PDFBox, and I'm a
member of the ASF.  I am passionate about relevance
engineering/evaluation, and more generally, about testing and
evaluation to protect our codebases from my code[1][2].  In a former
life, I was a professor of Latin and Ancient Greek[3].

I am so very grateful to receive this honor.

Thank you!

Cheers,

Tim

[1] 
http://openpreservation.org/blog/2016/10/04/apache-tikas-regression-corpus-tika-1302
[2] https://www.youtube.com/playlist?list=PLbzoR-pLrL6pLDCyPxByWQwYTL-JrF5Rp
[3] 
https://books.google.com/books/about/Aeschylean_stylistics.html?id=0wweAQAAMAAJ
On Fri, Nov 2, 2018 at 12:20 PM Erick Erickson  wrote:

 Hi all,

 Please join me in welcoming Tim Allison as the latest Lucene/Solr committer!

 Congratulations and Welcome, Tim!

 It's traditional for you to introduce yourself with a brief bio.

 Erick

 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


--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Re: Welcome Gus Heck as Lucene/Solr committer

[Martin Gainty]

Welcome Gus!

Martin

From: Jason Gerlowski 
Sent: Thursday, November 1, 2018 10:18 AM
To: dev@lucene.apache.org
Subject: Re: Welcome Gus Heck as Lucene/Solr committer

Congrats and welcome Gus!
On Thu, Nov 1, 2018 at 10:13 AM Gus Heck  wrote:
>
> Hi all,
>
> Thanks for inviting me to be a committer!
>
> Bio:
> I've enjoyed programming computers for over 30 years now, starting on an 
> Timex Sinclair 2k (with 16k expansion pack!). Until 2002 programming was a 
> hobby and a set of high school and college courses that were fun ways to 
> fulfill requirements. In 2002 faced with extremely low paying and sparse job 
> prospects I switched career paths from Ecology/Evolution/Ornithology to 
> Programming. I've been contributing to open source almost from the start. I 
> contributed several tasks to Apache Ant between 2003 and 2004. In 2010 I 
> first encountered Solr and 2012 I was given the opportunity to work as an 
> independent search consultant, thus I founded Needham Software LLC and been 
> contributing to Lucene/Solr with increasing frequency since 2013 and have 
> attended the last 5 Revolution/Activate conferences.
>
> My other hobbies include the Game of Go and SCCA Solo style Autocross
>
> Again, thanks for inviting me and I look forward to this enhanced opportunity 
> to improve Lucene/Solr.
>
> -Gus
> https://www.linkedin.com/in/gusheck/
>
> On Thu, Nov 1, 2018 at 8:22 AM David Smiley  wrote:
>>
>> Hi all,
>>
>> Please join me in welcoming Gus Heck as the latest Lucene/Solr committer!
>>
>> Congratulations and Welcome, Gus!
>>
>> Gus, it's traditional for you to introduce yourself with a brief bio.
>>
>> ~ David
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
>> http://www.solrenterprisesearchserver.com
>
>
>
> --
> http://www.the111shift.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Academic question about Solr's embedded web server

[Martin Gainty]

From: Christopher Schultz 
Sent: Friday, October 12, 2018 4:30 PM
To: dev@lucene.apache.org
Subject: Re: Academic question about Solr's embedded web server

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Shawn,

On 10/12/18 15:52, Shawn Heisey wrote:
> On 10/12/2018 1:18 PM, Christopher Schultz wrote:
>> I'm curious as to why Solr uses Jetty and not Tomcat.
>
> I wasn't part of the project when that decision was made. Jetty
> was already included with Solr when I first downloaded it -- Solr
> version 1.4.0, back in 2009.  Jetty wasn't quite as integrated as
> it is now, and at that time, Solr was still shipping as a WAR,
> suitable for any container.
>
> I'm going to offer my two cents, which I admit up front is only an
> educated guess.  Others can probably give you concrete information
> about discussions that happened nearly a decade ago.
>
> I think the primary reason is that Jetty is more lightweight than
> Tomcat.

I think this is more of a perception than actual truth.
MG>dead wrong

> And the Jetty that's included with Solr is considerably stripped
> down compared to a standard binary distribution, so its footprint
> is VERY small.  Since Solr 4.0 when Solr's UI completely changed to
> Javascript, even JSP support is missing.

When you consider "footprint", do you mean on-disk or in-memory? I ask
because Tomcat can be used in an embedded mode where you basically
only enable things that you want. For example, if you don't want JSP,
you simply don't bring-up the JSP engine on startup. If Solr doesn't
use Websocket, then you don't have to enable that, either. Tearing-out
the various JAR files might be more tricky and it may be simpler to
leave the unused classes sitting around, unused.
MG>inefficient

It might be safe to drop a few of the stock JAR files to save some
disk space, but it would be best if you/we didn't have to crack
anything open and remove anything from existing artifacts. If there is
a use-case for further-decomposing Tomcat into more JAR files so that
more of them can be removed for e.g. Solr (and anyone else using
Tomcat-embedded), then that is worth considering.

>> We'd like to make Tomcat such that, if you had the choice to
>> make again, you might pick Tomcat instead.
>
> If you can make a very compelling argument about benefits we would
> see from moving to Tomcat, and can help us modify things like our
> testing infrastructure and scripting to make it all work, I see no
> reason we wouldn't give it serious consideration.  It would be VERY
> important for the test infrastructure to use the same container as
> the binary distribution.  That's probably the biggest source of
> inertia that keeps us where we are.
>
> Take a look at SOLR-6733 (and its child SOLR-6734) in Jira for
> some ideas I've been tossing around for embedding the container
> directly into Solr itself, so that Solr is a standalone
> application. I never have the time I need to work on it, and it's a
> really major task.  I know from work I've done using Spring Boot
> that Tomcat can also be embedded.
MG>as you are using the embedded model from Spring

I didn't realize that Solr wasn't using Jetty embedded. I just assumed
that it was. If you are thinking about turning Jetty inside-out so
that you launch Solr and Solr launches Jetty, then actually now might
be a good time to re-consider using Tomcat versus Jetty.
MG>that would only be true if your support didnt spend all their time on 
self-serving evasive answers
MG>look at the 100s of JIRA requests that were torpedoed by MarkTrump

Self-hosting a Tomcat instance (i.e. embedded usage) is fairly
straightforward: create an instance of the Tomcat class and add
connectors (port binding), web applications, etc. Presumably, you'd
add one or maybe two connectors (HTTP and/or HTTPS) and then a single
web application: Solr.
MG>TC drags their feet on SSL conformance
MG>no matter.. TLS v1.3 is the new standard and I guarantee you
MG>TC will never catch up to that standard
MG>implement jetty 9.4.12
https://github.com/eclipse/jetty.project/issues/2711
[https://avatars3.githubusercontent.com/u/414681?s=400=4]

TLS 1.3 compliance · Issue #2711 · 
eclipse/jetty.project
The TLS 1.3 implementation landed in JDK 11-ea+21. We need to make sure that 
SslConnection works well with TLS 1.3. In particular: After ClientHello and 
ServerHello, all other TLS handshake message...
github.com



- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvBBEsACgkQHPApP6U8
pFgNxw//Xd4IZCtNo0/VHDbYlaaFTAjyWDLvsjWZuDFBZqJq9zBHbE00zMbqjFA0
eQF9/gB8wqctCHZttj124GfoaPP80p4/8SW/myBu239D+UvdWWtF1c61ItOrdkU8
46DlVROxkjsjxmguBL5R7EwJqlYB5feVTRGU7aKkiYxI1A2Jv3+NrejtqtmIxgrW
M1TPQfpI7dhyuJ0GqWafmr5oW7hfDt/zrx1f96FiYp2gWnjJXsH7UwfHRWXUvOEa

Re: Explore alternative build systems - LUCENE-5755

[Martin Gainty]

if you're thinking of scoping (modules used only for certain parts of build then
+1 vote for maven

if you're thinking of using multiple implementations for your artifact then
+1 for ivy

Martin Gainty
__

 _ _  _ _  _ ___ _  
  _   _ _   _
|_   _| |_ ___   |  _  |___ ___ ___| |_ ___   |   __|___|  _| |_ _ _ _ ___ ___ 
___   |   __|___ _ _ ___ _| |___| |_|_|___ ___
  | | |   | -_|  | | . | .'|  _|   | -_|  |__   | . |  _|  _| | | | .'|  _| 
-_|  |   __| . | | |   | . | .'|  _| | . |   |
  |_| |_|_|___|  |__|__|  _|__,|___|_|_|___|  |_|___|_| |_| |_|__,|_| 
|___|  |__|  |___|___|_|_|___|__,|_| |_|___|_|_|
   |_|



From: Shawn Heisey 
Sent: Tuesday, July 17, 2018 11:12 AM
To: dev@lucene.apache.org
Subject: Re: Explore alternative build systems - LUCENE-5755

On 7/17/2018 3:35 AM, Diego Ceccarelli (BLOOMBERG/ LONDON) wrote:
> Thanks Dawid, I agree it is a massive job, I was curious to know if
> there is interest and we can put together a group of people interested
> in doing the job.

If that work gives us a build system that is easier for everyone to
understand and change, it would be worth pursuing.  If it doesn't make
things easier, then I don't think we should change it.  Dependency
management is only a small part of what the build system does.

I have no particular attachment to ant/ivy.  The current build system
does work, and it would be important that any new build system be
tortured to make sure it's more robustthan the ant/ivy build.

It would indeed be a big job.  If you tackle it, I would suggest setting
it up so it exists in parallel with the ant build system for at least
all of 8.x.  In the interests of stability, I don't think the work
should affect branch_7x.

I really think that any significant work on the build system, whether we
switch systems or not, should involve some detailed design and howto
documentation, probably on the project wikis.

Thanks,
Shawn


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Status of solr tests

[Martin Gainty]

Erick-


appears that style mis-application may be categorised as INFO
are mixed in with SEVERE errors


Would it make sense to filter the errors based on severity ?


https://docs.oracle.com/javase/7/docs/api/java/util/logging/Level.html

Level (Java Platform SE 7 ) - Oracle Help 
Center
docs.oracle.com
The Level class defines a set of standard logging levels that can be used to 
control logging output. The logging Level objects are ordered and are specified 
by ordered integers.

if you know Severity you can triage the SEVERE errors before working down to 
INFO errors


WDYT?

Martin
__




From: Erick Erickson 
Sent: Friday, June 15, 2018 1:05 PM
To: dev@lucene.apache.org; Mark Miller
Subject: Re: Status of solr tests

Mark (and everyone).

I'm trying to be somewhat conservative about what I BadApple, at this
point it's only things that have failed every week for the last 4.
Part of that conservatism is to avoid BadApple'ing tests that are
failing and _should_ fail.

I'm explicitly _not_ delving into any of the causes at all at this
point, it's overwhelming until we reduce the noise as everyone knows.

So please feel totally free to BadApple anything you know is flakey,
it won't intrude on my turf ;)

And since I realized I can also report tests that have _not_ failed in
a month that _are_ BadApple'd, we can be a little freer with
BadApple'ing tests since there's a mechanism for un-annotating them
without a lot of tedious effort.

FWIW.

On Fri, Jun 15, 2018 at 9:09 AM, Mark Miller  wrote:
> There is an okay chance I'm going to start making some improvements here as
> well. I've been working on a very stable set of tests on my starburst branch
> and will slowly bring in test fixes over time (I've already been making some
> on that branch for important tests). We should currently be defaulting to
> tests.badapples=false on all solr test runs - it's a joke to try and get a
> clean run otherwise, and even then somehow 4 or 5 tests that fail somewhat
> commonly have so far avoided Erick's @BadApple hack and slash. They are bad
> appled on my dev branch now, but that is currently where any time I have is
> spent rather than on the main dev branches.
>
> Also, too many flakey tests are introduced because devs are not beasting or
> beasting well before committing new heavy tests. Perhaps we could add some
> docs around that.
>
> We have built in beasting support, we need to emphasize that a couple passes
> on a new test is not sufficient to test it's quality.
>
> - Mark
>
> On Fri, Jun 15, 2018 at 9:46 AM Erick Erickson 
> wrote:
>>
>> (Sg) All very true. You're not alone in your frustration.
>>
>> I've been trying to at least BadApple tests that fail consistently, so
>> another option could be to disable BadApple'd tests. My hope has been
>> to get to the point of being able to reliably get clean runs, at least
>> when BadApple'd tests are disabled.
>>
>> From that point I want to draw a line in the sand and immediately
>> address tests that fail that are _not_ BadApple'd. At least then we'll
>> stop getting _worse_. And then we can work on the BadApple'd tests.
>> But as David says, that's not going to be any time soon. It's been a
>> couple of months that I've been trying to just get the tests
>> BadApple'd without even trying to fix any of them.
>>
>> It's particularly pernicious because with all the noise we don't see
>> failures we _should_ see.
>>
>> So I don't have any good short-term answer either. We've built up a
>> very large technical debt in the testing. The first step is to stop
>> adding more debt, which is what I've been working on so far. And
>> that's the easy part
>>
>> Siigghh
>>
>> Erick
>>
>>
>> On Fri, Jun 15, 2018 at 5:29 AM, David Smiley 
>> wrote:
>> > (Sigh) I sympathize with your points Simon.  I'm +1 to modify the
>> > Lucene-side JIRA QA bot (Yetus) to not execute Solr tests.  We can and
>> > are
>> > trying to improve the stability of the Solr tests but even
>> > optimistically
>> > the practical reality is that it won't be good enough anytime soon.
>> > When we
>> > get there, we can reverse this.
>> >
>> > On Fri, Jun 15, 2018 at 3:32 AM Simon Willnauer
>> > 
>> > wrote:
>> >>
>> >> folks,
>> >>
>> >> I got more active working on IndexWriter and Soft-Deletes etc. in the
>> >> last couple of weeks. It's a blast again and I really enjoy it. The
>> >> one thing that is IMO not acceptable is the status of solr tests. I
>> >> tried so many times to get them passing on several different OSs but
>> >> it seems this is pretty hopepless. It's get's even worse the
>> >> Lucene/Solr QA job literally marks every ticket I attach a patch to as
>> >> `-1` because of arbitrary solr tests, here is an example:
>> >>
>> >> || Reason || Tests ||
>> >> | Failed junit tests | 

Re: Welcome Jason Gerlowski as committer

[Martin Gainty]

Welcome Jason!


Martin Gainty
__



From: Erick Erickson <erickerick...@gmail.com>
Sent: Thursday, February 8, 2018 12:03 PM
To: dev@lucene.apache.org
Subject: Re: Welcome Jason Gerlowski as committer

Welcome Jason!

On Thu, Feb 8, 2018 at 9:02 AM, David Smiley <david.w.smi...@gmail.com> wrote:
> Hello everyone,
>
> It's my pleasure to announce that Jason Gerlowski is our latest committer
> for Lucene/Solr in recognition for his contributions to the project!  Please
> join me in welcoming him.  Jason, it's tradition for you to introduce
> yourself with a brief bio.
>
> Congratulations and Welcome!
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
[https://media.licdn.com/dms/image/C5603AQFxEK3zcQRRAg/profile-displayphoto-shrink_200_200/0?e=1528722000=beta=VPuhJWteW40Szj8vikPvcG-7yKpKFEYtf6RhzuwVM6I]<http://linkedin.com/in/davidwsmiley>

David Smiley - Lucene/Solr Search Developer / Consultant - D W Smiley LLC | 
LinkedIn<http://linkedin.com/in/davidwsmiley>
linkedin.com
View David Smiley’s profile on LinkedIn, the world's largest professional 
community. David has 3 jobs jobs listed on their profile. See the complete 
profile on LinkedIn and discover David’s connections and jobs at similar 
companies.



> http://www.solrenterprisesearchserver.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: TestSSLRandomization is failing everytime

[Martin Gainty]

the other way to determine your default provider is to dump java.security:

cat $JAVA_HOME/jre/lib/security/java.security


hoss suggests you determine the default provider and default protocol with this 
simple test:

 public static void main(String[] args) throws Exception {

System.out.println(javax.net.ssl.SSLContext.getDefault().getProvider());

System.out.println(javax.net.ssl.SSLContext.getDefault().getProtocol());
}


what do you see for either test?


Martin
__




From: Joel Bernstein 
Sent: Wednesday, April 4, 2018 3:35 PM
To: lucene dev
Subject: Re: TestSSLRandomization is failing everytime

The code below ran fine from the command line and from a basic test case:
System.out.println(javax.net.
javax.net - This domain may be for sale!
javax.net
{domain} has been informing visitors about topics such as {related1}. Join 
thousands of satisfied visitors who discovered {related2}. This domain may be 
for sale!


ssl.SSLContext.getDefault().getProvider());
System.out.println(javax.net.ssl.SSLContext.getDefault().getProtocol());

The source code that throws the exception in JavaKeyStore.engineLoad is:


if (password != null) {
byte computed[], actual[];
computed = md.digest();
actual = new byte[computed.length];
dis.readFully(actual);
for (int i = 0; i < computed.length; i++) {
if (computed[i] != actual[i]) {
Throwable t = new UnrecoverableKeyException
("Password verification failed");
throw (IOException)new IOException
("Keystore was tampered with, or "
+ "password was incorrect").initCause(t);
}
}
}

Notice that it's simply comparing the bytes from two digests.

The digests are prepared using a SHA digest, notice that it just specifies SHA, 
which must choose the default SHA digest for the system it's on. If
it choses a different SHA digest the password would not match. My best bet 
right now is that I've changed my default SHA digest to be something
other then what was used to create the passwords for the test framework:



/**
 * To guard against tampering with the keystore, we append a keyed
 * hash with a bit of whitener.
 */
private MessageDigest getPreKeyedHash(char[] password)
throws NoSuchAlgorithmException, UnsupportedEncodingException
{
int i, j;

MessageDigest md = MessageDigest.getInstance("SHA");
byte[] passwdBytes = new byte[password.length * 2];
for (i=0, j=0; i> 8);
passwdBytes[j++] = (byte)password[i];
}
md.update(passwdBytes);
for (i=0; i> wrote:
Thanks Hoss, I will give this a try.

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, Apr 4, 2018 at 1:42 PM, Chris Hostetter 
> wrote:

: I suspect I hosed something to do with my root certs on my local machine.
: Fairly recently I was playing around with these certs while doing some SSL
: work for Alfresco. This should be fun to fix...

if that's your suspicion, i would start by testing out a simple java app
that does nothing but...

public static void main(String[] args) throws Exception {

System.out.println(javax.net.ssl.SSLContext.getDefault().getProvider());

System.out.println(javax.net.ssl.SSLContext.getDefault().getProtocol());
}

...if thta fails on the commandline, then ou definitely hozed your
machine.

If that *does* work on the commandline, then try the same code in a
trivial Junit test that just subclasses LuceneTestCase -- NOT
SolrTestCaseJ4 -- to see if the problem is somewhere in our ant/lucene
build setup, independent of any Solr SSL randomization.

:
: Joel Bernstein
: http://joelsolr.blogspot.com/
:
: On Wed, Apr 4, 2018 at 12:29 PM, Joel Bernstein 
> wrote:
:
: > Ok, so it does sounds like a local problem then. Nothing much has changed
: > locally. I'm still using the same Mac and Java version:
: >
: > defaultuildsMBP:clone2 joelbernstein$ java -version
: >
: > java version "1.8.0_40"
: >
: > Java(TM) SE Runtime Environment (build 1.8.0_40-b27)
: >
: > Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
: >
: > 

Re: SecureRandomAlgorithmTesterApp ??

[Martin Gainty]

From: Mihály Tóth 
Sent: Monday, February 12, 2018 10:37 AM
To: dev@lucene.apache.org
Subject: Re: SecureRandomAlgorithmTesterApp ??

Hi,

I used it to test how random entropy gets exhausted with different secure 
random configurations on different platforms. I tend to agree that it is not 
needed anymore because the result of these experiments have been captured 
elsewhere.
MG>which codebase duplicates this tool?

Best Regards,

  Misi
MG>Before its lost can u copy to github ?

2018-02-12 0:41 GMT+01:00 Uwe Schindler 
>:
Hi,

in Solr's Core test class is a file "SecureRandomAlgorithmTesterApp.java" in 
the default package. It is also compiled, but not used anywhere. It does not 
appear in Javadocs (as it's test only), but the updated weekly OpenClover 
coverage report list it as a completely untested class file in the default 
package. I'd like to delete it unless there is a use-case for it. Maybe let's 
move it into a package, if it's of use. It seems to be a command line program 
to test some SecureRandomConfigs in the JVM.

It was added by: SOLR-10338: Configure SecureRandom non blocking for tests 
(Mark Miller). I think it was just some testing when SecureRandom support was 
added and got accidentally committed to source tree.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de



-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: SecureRandomAlgorithmTesterApp ??

[Martin Gainty]

From: Uwe Schindler <u...@thetaphi.de>
Sent: Monday, February 12, 2018 2:31 AM
To: dev@lucene.apache.org
Subject: RE: SecureRandomAlgorithmTesterApp ??


Hi Martin,



this class was a test-only class, so I don’t think it’s of use for production 
end users. Why should we add it to SolrCLI?

MG>has to do with Blocking nature of your Native Random Number Generator (from 
Sun or Linux)

NativePRNGBlocking will be problematic in any applications where you do not 
want your application to block while the system gathers more entropy. Getting 
any type of output from it could cause your application’s thread to hang.
It is fine for use in a desktop application for generating a local 
cryptographic key (for example), but will almost never be okay to use in a web 
application.

MG>since we dont want webapp to hang..how to config using a non-blocking RNG ?

MG>java.security could specify securerandom.source to an unblocked source

securerandom.source=file:/dev/urandom

MG>but wait devs dont have access to this file ..the Operations people do and 
they wont touch it..second option:

MG>from Java CLI specify generate RNG from unblocking source

java -Djava.security.egd=file:/dev/urandom ...

./solr/cloud-dev/cli-test-solrcloud-start.sh
(possibly update server/solr/collection1/conf for cli-test-solrcloud-start.sh)


update scripts to accommodate -Djava.security.egd=file:/dev/urandom

./solr/cloud-dev/solrcloud-start-existing.sh
./solr/cloud-dev/solrcloud-start.sh

MG>the next call to create RNG instance will not block

SecureRandom random=SecureRandom("NativePRNG",String provider);
//warning make sure provider is listed in $JRE_HOME/lib/security/java.security

MG>P/L uwe wants us to verify we *are* using a NonBlocking RandomNumberGenerator

SecureRandomAlgorithmTesterApp will assert but for the time being we could set 
it up to make sure all the executions are made non-blocking.

MG>SecureRandomAlgorithmTesterApp accepts the algorithm, the function and the 
amount of data are program arguments.


MG>the 2 SecureRandomAlgorithmTesterApp features i would refactor:

MG>function should be default callback function
MG>data should be default to a constant

MG>i have seen when someone implements a provider which does not support their 
SecureRandom Algorithm
https://docs.oracle.com/javase/9/security/oracleproviders.htm#JSSEC-GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D

JDK Providers Documentation - 
Oracle<https://docs.oracle.com/javase/9/security/oracleproviders.htm#JSSEC-GUID-3A80CC46-91E1-4E47-AC51-CB7B782CEA7D>
docs.oracle.com
This document contains the technical details of the providers that are included 
in the JDK. It is assumed that readers have a strong understanding of the Java 
...

MG>To Recap: SecureRandomAlgorithmTesterApp would be a testing tool to test:

MG>RandomNumberGenerator does indeed draw from unblocking source

MG>ensures SecureRandom algorithm is supported by providers listed in 
java.security

MG>WDYT?

Uwe



-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de<http://www.thetaphi.de/>

eMail: u...@thetaphi.de



From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: Monday, February 12, 2018 4:27 AM
To: dev@lucene.apache.org
Subject: Re: SecureRandomAlgorithmTesterApp ??









From: Uwe Schindler <u...@thetaphi.de<mailto:u...@thetaphi.de>>
Sent: Sunday, February 11, 2018 6:41 PM
To: dev@lucene.apache.org<mailto:dev@lucene.apache.org>
Subject: SecureRandomAlgorithmTesterApp ??



Hi,

in Solr's Core test class is a file "SecureRandomAlgorithmTesterApp.java" in 
the default package. It is also compiled, but not used anywhere. It does not 
appear in Javadocs (as it's test only), but the updated weekly OpenClover 
coverage report list it as a completely untested class file in the default 
package. I'd like to delete it unless there is a use-case for it. Maybe let's 
move it into a package, if it's of use. It seems to be a command line program 
to test some SecureRandomConfigs in the JVM.

It was added by: SOLR-10338: Configure SecureRandom non blocking for tests 
(Mark Miller). I think it was just some testing when SecureRandom support was 
added and got accidentally committed to source tree.

MG>would it make sense to copy SecureRandomAlgorithmTesterApp  as static inner 
class inside org.apache.solr.util.SOLRCLI ?

http://grepcode.com/file/repo1.maven.org/maven2/org.apache.solr/solr-core/5.2.0/org/apache/solr/util/SolrCLI.java#SolrCLI.ApiTool

GC: SolrCLI - org.apache.solr.util.SolrCLI (.java) - GrepCode Class 
Source<http://grepcode.com/file/repo1.maven.org/maven2/org.apache.solr/solr-core/5.2.0/org/apache/solr/util/SolrCLI.java#SolrCLI.ApiTool>

grepcode.com

org.apache.solr.util.SolrCLI - Command-line utility for working with Solr


MG>WDYT?


Uwe

Re: SecureRandomAlgorithmTesterApp ??

[Martin Gainty]

From: Uwe Schindler 
Sent: Sunday, February 11, 2018 6:41 PM
To: dev@lucene.apache.org
Subject: SecureRandomAlgorithmTesterApp ??

Hi,

in Solr's Core test class is a file "SecureRandomAlgorithmTesterApp.java" in 
the default package. It is also compiled, but not used anywhere. It does not 
appear in Javadocs (as it's test only), but the updated weekly OpenClover 
coverage report list it as a completely untested class file in the default 
package. I'd like to delete it unless there is a use-case for it. Maybe let's 
move it into a package, if it's of use. It seems to be a command line program 
to test some SecureRandomConfigs in the JVM.

It was added by: SOLR-10338: Configure SecureRandom non blocking for tests 
(Mark Miller). I think it was just some testing when SecureRandom support was 
added and got accidentally committed to source tree.

MG>would it make sense to copy SecureRandomAlgorithmTesterApp  as static inner 
class inside org.apache.solr.util.SOLRCLI ?
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.solr/solr-core/5.2.0/org/apache/solr/util/SolrCLI.java#SolrCLI.ApiTool
GC: SolrCLI - org.apache.solr.util.SolrCLI (.java) - GrepCode Class 
Source
grepcode.com
org.apache.solr.util.SolrCLI - Command-line utility for working with Solr

MG>WDYT?


Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Need to install Solr in Tomcat in Eclipse

[Martin Gainty]

From: Mayank Kumar 
Sent: Friday, February 9, 2018 6:21 AM
To: dev@lucene.apache.org
Subject: Need to install Solr in Tomcat in Eclipse

Hi,

I am Mayank and just wanted to contribute to Apache Solr.

I want to deploy the solr application in Apache tomcat in Eclipse so that I 
will be able to debug it.

Can anybody help me in doing the same.

MG>Parroting eclipse-tomcat-plugin documentation from
http://marketplace.eclipse.org/content/eclipse-tomcat-plugin
Eclipse Tomcat Plugin | Eclipse Plugins, Bundles and 
...
marketplace.eclipse.org
The Eclipse Tomcat Plugin provides simple integration of a tomcat servlet 
container for the development of java web applications. This project is the 
successor of the ...





1. Go to the source forge site (click on "?') 
(https://sourceforge.net/projects/tomcatplugin/)

[https://a.fsdn.com/allura/p/tomcatplugin/icon?1487932622]

Eclipse Tomcat Plugin download | 
SourceForge.net
sourceforge.net
Download Eclipse Tomcat Plugin for free. Simple handling of a tomcat server in 
Eclipse IDE. The Eclipse Tomcat Plugin provides simple integration of a ...



2. Download the version of the tomcat plugin

3. Unzip the file, there should be folders features and plugins

4. Put the files of the folders into their respective folders in the eclipse 
root directory

5. Restart eclispe.

MG>JDK 8 WARNING: you may have to manually edit context.xml and .tomcatplugin 
(be sure to copy to backup first!)

MG>JDK9: Untested

MG>if you experience Handshake errors apparently need JCE installed

1) Download and unzip "Java Cryptography Extension (JCE) Unlimited Strength 
Jurisdiction Policy Files 8" (first link google in my case)

2) replace both files in the directory $JAVA_HOME/jre/lib/security

3) restart eclipse.

Thank you,
Mayank
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Jason Gerlowski as committer

[Martin Gainty]

the next time you bag HalfDome.. bring your laptop with you


Welcome Jason!

Martin
__




From: Jason Gerlowski 
Sent: Thursday, February 8, 2018 3:05 PM
To: dev@lucene.apache.org
Subject: Re: Welcome Jason Gerlowski as committer

Hi all,

Thanks for the warm welcome, and the opportunity to join your ranks as a
committer.

A bit about myself.  I work for IBM in Pittsburgh, PA (USA), where I live with
my lovely wife Kait and our dog Brantley.  Outside of work and Solr I spend
much of my time outside.  My wife and I are working on a lifetime goal to see
all of our National Parks here in the US. I enjoy camping, hiking, cycling,
and bouldering when the weather permits.

Most of my focus in the Solr community has been on improving the experience
users have when picking up Solr for the first time, by adding features to
SolrJ, the bin/solr scripts, and the documentation.  Hopefully I've been
removing more paper-cuts than I've added along the way, and improving things
for our users.  I've loved the experience so far, and look forward to working
with you all for a long time to come.

Thanks to everyone for the reviews, time, and for putting up with me in
general. I especially want to thank Shai Erera and Anshum Gupta, who introduced
me to the project and have helped me navigate the community.  And my wife for
making the constant little sacrifices that afford me time to contribute.  It'd
be impossible to have gotten this far without everyone's help!

Thank you,

Jason

On Thu, Feb 8, 2018 at 2:31 PM, Shai Erera  wrote:
> Welcome!
>
>
> On Thu, Feb 8, 2018, 20:56 Joel Bernstein  wrote:
>>
>> Welcome Jason!
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Thu, Feb 8, 2018 at 12:41 PM, Ishan Chattopadhyaya
>>  wrote:
>>>
>>> Congratulations Jason! :-)
>>>
>>> On Thu, Feb 8, 2018 at 10:38 PM, Karl Wright  wrote:

 Hello Jason!


 On Thu, Feb 8, 2018 at 12:06 PM, Dawid Weiss 
 wrote:
>
> Welcome Jason!
>
> Dawid
>
> On Thu, Feb 8, 2018 at 6:04 PM, Adrien Grand  wrote:
> > Welcome Jason!
> >
> > Le jeu. 8 févr. 2018 à 18:03, David Smiley 
> > a
> > écrit :
> >>
> >> Hello everyone,
> >>
> >> It's my pleasure to announce that Jason Gerlowski is our latest
> >> committer
> >> for Lucene/Solr in recognition for his contributions to the project!
> >> Please
> >> join me in welcoming him.  Jason, it's tradition for you to
> >> introduce
> >> yourself with a brief bio.
> >>
> >> Congratulations and Welcome!
> >> --
> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
[https://media-exp2.licdn.com/mpr/mpr/shrinknp_200_200/AAEAAQclJDJkMDllNGFjLTNlZDgtNGNjZC1hYTBkLTFjODVjMTBlMWI2Mg.jpg]

David Smiley | Professional Profile | 
LinkedIn
linkedin.com
View David Smiley’s professional profile on LinkedIn. LinkedIn is the world's 
largest business network, helping professionals like David Smiley discover 
inside connections to recommended job candidates, industry experts, and 
business partners.



> >> http://www.solrenterprisesearchserver.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

>>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Ignacio Vera as Lucene/Solr committer

[Martin Gainty]

¡Bienvendos Ignacio!


Martín
__



From: Erick Erickson 
Sent: Thursday, January 11, 2018 12:39 PM
To: dev@lucene.apache.org
Subject: Re: Welcome Ignacio Vera as Lucene/Solr committer

Welcome Ignacio!

On Thu, Jan 11, 2018 at 9:09 AM, Karl Wright 
> wrote:
Welcome, Ignacio!
Karl

On Thu, Jan 11, 2018 at 11:46 AM, Steve Rowe 
> wrote:
Congrats and welcome Ignacio!

--
Steve
www.lucidworks.com

> On Jan 11, 2018, at 11:35 AM, Adrien Grand 
> > wrote:
>
> Hi all,
>
> Please join me in welcoming Ignacio Vera as the latest Lucene/Solr committer.
> Ignacio, it's tradition for you to introduce yourself with a brief bio.
>
> Congratulations and Welcome!


-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Welcome Karl Wright to the PMC

[Martin Gainty]

Willkommen Karl!


Martin
___


From: Adrien Grand 
Sent: Thursday, December 28, 2017 9:08 AM
To: Lucene Dev
Subject: Welcome Karl Wright to the PMC

I am pleased to announce that Karl Wright has accepted the PMC's invitation to 
join.

Welcome Karl!

Re: Welcome Dennis Gove to the PMC

[Martin Gainty]

Congratulations Dennis


Welcome to Lucene dev group!

Martin
__




From: Joel Bernstein 
Sent: Tuesday, December 26, 2017 8:12 AM
To: lucene dev
Subject: Welcome Dennis Gove to the PMC

I am pleased to announce that Dennis Gove has accepted the PMC's invitation to 
join.

Welcome Dennis!

Re: Welcome Jim Ferenczi to the PMC

[Martin Gainty]

Congratulazioni jim!


Martini
__



From: Michael McCandless 
Sent: Wednesday, December 20, 2017 6:31 AM
To: Lucene/Solr dev
Subject: Re: Welcome Jim Ferenczi to the PMC

Welcome Jim!

On Dec 20, 2017 5:18 AM, "Adrien Grand" 
> wrote:
I am pleased to announce that Jim Ferenczi has accepted the PMC's invitation to 
join.

Welcome Jim!

Re: Solr Ref Guide not building

[Martin Gainty]

as evidenced by the warning you're getting..your yaml scripts appear to 
reference deprecated ruby gems

personally i dont care to implement ruby gems since these binaries work on ONLY 
the OS/ARCH they were originally targeted for

a well designed software architecture implementing plugins will flexibly build 
to any number of OS/ARCH with no need to build for each specific target 
OS/ARCH  with makefile(s) (as is the case for ruby gems) .


The caveat for implementing plugins is "as long as the JDK remains the same" 
you should see no behaviour delta(s) as you implement your plugin from one 
OS/ARCH to another..


hth

Martin
__



From: Doug Turnbull <dturnb...@opensourceconnections.com>
Sent: Saturday, December 2, 2017 1:12 PM
To: dev@lucene.apache.org
Subject: Re: Solr Ref Guide not building

Thanks.

I don’t mind poking around the ref guide config, but I'm following the readme 
and building master. I'm hesitant to change config files as part of my PR, 
which probably will break the ref guide build for others :)

Best
-Doug


On Sat, Dec 2, 2017 at 7:37 AM Martin Gainty 
<mgai...@hotmail.com<mailto:mgai...@hotmail.com>> wrote:


MG>see below



From: Doug Turnbull 
<dturnb...@opensourceconnections.com<mailto:dturnb...@opensourceconnections.com>>
Sent: Friday, December 1, 2017 9:17 PM
To: dev@lucene.apache.org<mailto:dev@lucene.apache.org>
Subject: Solr Ref Guide not building

Hello!

I'm trying to update the Solr Ref guide with my change for SOLR-11662. I 
believe I've installed the required dependencies and double checked the README 
in the solr-ref-guide. Unfortunately, running ant build-site I immediately get 
this error, seemingly on the first adoc file encountered:


 [exec] jekyll 3.5.0 | Error:  No header received back.
 [exec]   Conversion error: Jekyll::AsciiDoc::Converter encountered an 
error while converting 'about-filters.adoc':
MG>possible ant build snafu
MG>configuration file: 
/Users/doug/ws/lucene-solr/solr/build/solr-ref-guide/content/_config.yml
MG>Deprecation: The 'gems' configuration option has been renamed to 'plugins'.
MG>Please update your config file accordingly.
MG>check output config.yml for 'gems' and sub in 'plugins'
MG>also check ant input solr-ref-guide/config.yml.template for 'gems' instead 
of 'plugins'

I feel like I must be doing something stupid (I'll assume user error on my 
part). But if there's anything obvious I'm doing wrong, please let me know

A more complete log can be found here 
https://gist.github.com/softwaredoug/36fe87f0d63403e7be22d5a2ff8af073
[https://avatars1.githubusercontent.com/u/629060?s=400=4]<https://gist.github.com/softwaredoug/36fe87f0d63403e7be22d5a2ff8af073>

doug-being-dumb.txt<https://gist.github.com/softwaredoug/36fe87f0d63403e7be22d5a2ff8af073>
gist.github.com<http://gist.github.com>



Thanks for any help

-Doug
--
Consultant, OpenSource Connections. Contact info at 
http://o19s.com/about-us/doug-turnbull/; Free/Busy (http://bit.ly/dougs_cal)
[http://opensourceconnections.com/images/logo/OSC-logomark-color.png]<http://o19s.com/about-us/doug-turnbull/>

Doug Turnbull<http://o19s.com/about-us/doug-turnbull/>
o19s.com<http://o19s.com>
Search relevance consultant. Author of Relevant Search. Doug crafts 
search/recommendation solutions that “get” users. To do this, Doug uses 
Solr/Elasticsearc...


--
Consultant, OpenSource Connections. Contact info at 
http://o19s.com/about-us/doug-turnbull/; Free/Busy (http://bit.ly/dougs_cal)

Re: Solr Ref Guide not building

[Martin Gainty]

MG>see below



From: Doug Turnbull 
Sent: Friday, December 1, 2017 9:17 PM
To: dev@lucene.apache.org
Subject: Solr Ref Guide not building

Hello!

I'm trying to update the Solr Ref guide with my change for SOLR-11662. I 
believe I've installed the required dependencies and double checked the README 
in the solr-ref-guide. Unfortunately, running ant build-site I immediately get 
this error, seemingly on the first adoc file encountered:


 [exec] jekyll 3.5.0 | Error:  No header received back.
 [exec]   Conversion error: Jekyll::AsciiDoc::Converter encountered an 
error while converting 'about-filters.adoc':
MG>possible ant build snafu
MG>configuration file: 
/Users/doug/ws/lucene-solr/solr/build/solr-ref-guide/content/_config.yml
MG>Deprecation: The 'gems' configuration option has been renamed to 'plugins'.
MG>Please update your config file accordingly.
MG>check output config.yml for 'gems' and sub in 'plugins'
MG>also check ant input solr-ref-guide/config.yml.template for 'gems' instead 
of 'plugins'

I feel like I must be doing something stupid (I'll assume user error on my 
part). But if there's anything obvious I'm doing wrong, please let me know

A more complete log can be found here 
https://gist.github.com/softwaredoug/36fe87f0d63403e7be22d5a2ff8af073
[https://avatars1.githubusercontent.com/u/629060?s=400=4]

doug-being-dumb.txt
gist.github.com



Thanks for any help

-Doug
--
Consultant, OpenSource Connections. Contact info at 
http://o19s.com/about-us/doug-turnbull/; Free/Busy (http://bit.ly/dougs_cal)
[http://opensourceconnections.com/images/logo/OSC-logomark-color.png]

Doug Turnbull
o19s.com
Search relevance consultant. Author of Relevant Search. Doug crafts 
search/recommendation solutions that “get” users. To do this, Doug uses 
Solr/Elasticsearc...

Re: Welcome Noble Paul to the PMC

[Martin Gainty]

congratulations Paul


Martin


From: Scott Blum 
Sent: Sunday, November 19, 2017 3:26 PM
To: dev@lucene.apache.org
Subject: Re: Welcome Noble Paul to the PMC

Congrats Noble!

On Sun, Nov 19, 2017 at 3:02 PM, Adrien Grand 
> wrote:
I am pleased to announce that Noble Paul has accepted the PMC's invitation to 
join.

Welcome Noble!

Re: JIRA and keyboard shortcuts

[Martin Gainty]

Bedankt Rob


Martijn
__


From: Rob Audenaerde <rob.audenae...@gmail.com>
Sent: Saturday, October 28, 2017 7:08 AM
To: dev@lucene.apache.org
Subject: Re: JIRA and keyboard shortcuts

I think you can just press the '?' to get a list

Verstuurd vanaf mijn iPad

Op 28 okt. 2017 om 03:25 heeft Martin Gainty 
<mgai...@hotmail.com<mailto:mgai...@hotmail.com>> het volgende geschreven:


do you have a link for JIRA keyboard shortcuts we can reference?


Thanks David!

Martin
__




From: David Smiley <david.w.smi...@gmail.com<mailto:david.w.smi...@gmail.com>>
Sent: Friday, October 27, 2017 8:48 AM
To: dev@lucene.apache.org<mailto:dev@lucene.apache.org>
Subject: JIRA and keyboard shortcuts

Just an FYI folks: JIRA has keyboard shortcuts that do things like assign the 
issue to you with merely the touch of one key.  I've at least twice 
accidentally done exactly that, to my embarrassment.  Thankfully it can be 
disabled on a per-user basis in the "Profile" page for yourself, and then under 
the "Preferences" section.
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com
[https://media.licdn.com/mpr/mpr/shrinknp_200_200/AAEAAQclJDJkMDllNGFjLTNlZDgtNGNjZC1hYTBkLTFjODVjMTBlMWI2Mg.jpg]<http://linkedin.com/in/davidwsmiley>

David Smiley | Professional Profile | 
LinkedIn<http://linkedin.com/in/davidwsmiley>
linkedin.com<http://linkedin.com>
View David Smiley’s professional profile on LinkedIn. LinkedIn is the world's 
largest business network, helping professionals like David Smiley discover 
inside connections to recommended job candidates, industry experts, and 
business partners.

Re: JIRA and keyboard shortcuts

[Martin Gainty]

do you have a link for JIRA keyboard shortcuts we can reference?


Thanks David!

Martin
__




From: David Smiley 
Sent: Friday, October 27, 2017 8:48 AM
To: dev@lucene.apache.org
Subject: JIRA and keyboard shortcuts

Just an FYI folks: JIRA has keyboard shortcuts that do things like assign the 
issue to you with merely the touch of one key.  I've at least twice 
accidentally done exactly that, to my embarrassment.  Thankfully it can be 
disabled on a per-user basis in the "Profile" page for yourself, and then under 
the "Preferences" section.
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com
[https://media.licdn.com/mpr/mpr/shrinknp_200_200/AAEAAQclJDJkMDllNGFjLTNlZDgtNGNjZC1hYTBkLTFjODVjMTBlMWI2Mg.jpg]

David Smiley | Professional Profile | 
LinkedIn
linkedin.com
View David Smiley’s professional profile on LinkedIn. LinkedIn is the world's 
largest business network, helping professionals like David Smiley discover 
inside connections to recommended job candidates, industry experts, and 
business partners.

Re: Congratulations to the new Lucene/Solr PMC Chair, Adrien Grand

[Martin Gainty]

Félicitations Adrien!


Martin

__


From: ansh...@apple.com  on behalf of Anshum Gupta 

Sent: Thursday, October 19, 2017 11:52 AM
To: dev@lucene.apache.org
Subject: Re: Congratulations to the new Lucene/Solr PMC Chair, Adrien Grand

Congratulations Adrien!

-Anshum



On Oct 19, 2017, at 12:19 AM, Tommaso Teofili 
> wrote:

Once a year the Lucene PMC rotates the PMC chair and Apache Vice President 
position.
This year we have nominated and elected Adrien Grand as the chair and today the 
board just approved it, so now it's official.

Congratulations Adrien!
Regards,
Tommaso

Re: Ready for JDK 9 ?

[Martin Gainty]

From: Rory O'Donnell 
Sent: Tuesday, August 8, 2017 6:03 AM
To: Dawid Weiss; Uwe Schindler
Cc: rory.odonn...@oracle.com; Dalibor Topic; Balchandra Vaidya; Muneer 
Kolarkunnu; dev@lucene.apache.org
Subject: Ready for JDK 9 ?


Hi Uwe & Dawid,

Thank you very much for all your testing of JDK 9 during its
development! Such contributions have significantly helped shape and
improve JDK 9.

Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
would like to ask if your project can be considered to be 'ready for JDK
9', or if there are any remaining show stopper issues which you've
encountered when testing with the JDK 9 release candidate.

MG>do you know if Oracle dropping IIOMetadata*.* (JPEG Metadata Parse classes)?
MG>I am noticing "will be deprecated in future release" messages
MG>i am using drew noakes (Adobe) XMP parser
MG>but the integration with Oracles base IIOMetadata classes isnt 100% 
successful

MG>JPEG spec I am referencing is at 
https://docs.oracle.com/javase/7/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html
JPEG Metadata Format Specification and Usage 
Notes
docs.oracle.com
NOTE: It is important to call dispose() on the JPEG reader and writer objects 
when they are no longer needed, as they consume significant native resources 
which are ...


MG>can you recommend working alternatives such as Jai or commons-imaging for 
testing getAsTree, mergeTree and setFromTree?
MG>Thanks Rory!

JDK 9  b181 is available at http://jdk.java.net/9/
JDK 9 Early-Access Builds
jdk.java.net
Notes. Full JDK 9 downloads are larger than full JDK 8 downloads because they 
include JMOD files so that you can experiment with creating custom run-time 
images.




If you have a public web page, mailing list post, or even a tweet
announcing you project's readiness for JDK 9, I'd love to add the URL to
the upcoming JDK 9 readiness page on the Quality Outreach wiki.


Looking forward to hearing from you,
Rory

[1] http://openjdk.java.net/projects/jdk9/
JDK 9 project page - OpenJDK
openjdk.java.net
JDK 9. The goal of this Project is to produce an open-source reference 
implementation of the Java SE 9 Platform defined by JSR 379 in the Java 
Community Process.




--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Opportunities for cohesion improvement and refactoring

[Martin Gainty]

From: João Paulo Lemes Machado 
Sent: Wednesday, July 19, 2017 7:15 AM
To: dev@lucene.apache.org
Subject: Opportunities for cohesion improvement and refactoring

Hello everyone.

My name is João Paulo, I am a graduate student the Federal University of 
Uberlandia, Brazil.

I was analyzing the modularization of some classes of Lucene, and  I identified 
some opportunities for cohesion improvement in the following classes:

IndexSearcher
ArrayUtil
FieldType
Operations
CheckIndex
LeafReader

Could you please take a look and tell me if it's viable?

Maybe some of these classes could benefit from some kind of refactoring that we 
can discuss.
MG>what would be the benefit in refactoring these classes?
MG>which version lucene would you be targeting?
MG>Obrigado

Re: Welcome Mike Drob as Lucene/Solr committer

[Martin Gainty]

Welcome Mike!


Martin
__




From: Joel Bernstein 
Sent: Monday, May 8, 2017 12:35 PM
To: lucene dev
Subject: Re: Welcome Mike Drob as Lucene/Solr committer

Welcome Mike!

Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, May 8, 2017 at 12:18 PM, Steve Rowe 
> wrote:
Welcome Mike!

--
Steve
www.lucidworks.com

> On May 8, 2017, at 11:42 AM, Mark Miller 
> > wrote:
>
> I'm pleased to announce that Mike Drob has accepted the PMC's
> invitation to become a committer.
>
> Mike, it's tradition that you introduce yourself with a brief bio /
> origin story, explaining how you arrived here.
>
> Your existing Apache handle has already added to the “lucene" LDAP group, so 
> you now have commit privileges.
>
> Please celebrate this rite of passage, and confirm that the right
> karma has in fact enabled, by embarking on the challenge of adding
> yourself to the committers section of the Who We Are page on the
> website: http://lucene.apache.org/whoweare.html (use the ASF CMS
> bookmarklet
> at the bottom of the page here: https://cms.apache.org/#bookmark -
> more info here http://www.apache.org/dev/cms.html).
>
> Congratulations and welcome!
> --
> - Mark
> about.me/markrmiller


-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-7812) modified test for testing payload

[Martin Gainty (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Gainty updated LUCENE-7812:
--
Attachment: TestPayloadCheckQuery.java

> modified test for testing payload
> -
>
> Key: LUCENE-7812
> URL: https://issues.apache.org/jira/browse/LUCENE-7812
> Project: Lucene - Core
>  Issue Type: Test
>  Components: core/queryparser
>Affects Versions: 6.5.1
> Environment: jdk 1.8
> mvn 3.3
>Reporter: Martin Gainty
>Priority: Minor
> Attachments: TestPayloadCheckQuery.java
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
>  no specific test for SpanPayloadCheckQuery method specifically
> matches = payloadToMatch.get(upto).bytesEquals(payload);
> the only implementation i could locate was in collectLeaf of 
> SpanPayloadCheckQuery
> modified SpanPayloadCheckQueryTest now tests collectLeaf of 
> SpanPayloadCheckQuery
> patch for test attached
> suggestions/advice are most welcome



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-7812) modified test for testing payload

[Martin Gainty (JIRA)]

Martin Gainty created LUCENE-7812:
-

 Summary: modified test for testing payload
 Key: LUCENE-7812
 URL: https://issues.apache.org/jira/browse/LUCENE-7812
 Project: Lucene - Core
  Issue Type: Test
  Components: core/queryparser
Affects Versions: 6.5.1
 Environment: jdk 1.8
mvn 3.3
Reporter: Martin Gainty
Priority: Minor


 no specific test for SpanPayloadCheckQuery method specifically

matches = payloadToMatch.get(upto).bytesEquals(payload);

the only implementation i could locate was in collectLeaf of 
SpanPayloadCheckQuery

modified SpanPayloadCheckQueryTest now tests collectLeaf of 
SpanPayloadCheckQuery

patch for test attached

suggestions/advice are most welcome



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Release 6.6

[Martin Gainty]

i was wondering if there was a specific test for SpanPayloadCheckQuery method


matches = payloadToMatch.get(upto).bytesEquals(payload);


the only implementation i could locate was in collectLeaf of 
SpanPayloadCheckQuery


I will submit JIRA with Patch


as a CS *dinosaur* I am more familiar with LISP for dissecting sentence 
fragments (what we called phenomes) than current SEO implementations


Can you suggest a book to read to better understand Lucenes pattern dissection 
and match algorithms?


Many Thanks for helpful guidance

Martin
__




From: Erik Hatcher <erik.hatc...@gmail.com>
Sent: Sunday, April 30, 2017 2:06 PM
To: dev@lucene.apache.org
Subject: Re: Release 6.6

Martin -

I have to admit to still being unsure what the gist is here - is there a bug?   
Apologies for not catching what you’re saying/showing here.  Again, as far as I 
can tell SpanPayloadCheckQuery is working as expected now.

I’m going to focus purely on SOLR-1485 this week to get it committed for 6.6.  
If there is an issue to address with your work would you please open a JIRA and 
include your patch there?

Thanks,
Erik


On Apr 30, 2017, at 7:47 AM, Martin Gainty 
<mgai...@hotmail.com<mailto:mgai...@hotmail.com>> wrote:

Mornin' Erik

there is a collectLeaf  override in 
org.apache.lucene.queries.payloads.TestPayloadSpans ..but its never called:

static class VerifyingCollector implements SpanCollector {
List payloads = new ArrayList<>();
@Override
public void collectLeaf(PostingsEnum postings, int position, Term term) 
throws IOException {
 
 }
}

the modification in org.apache.lucene.queries.payloads.TestPayloadCheckQuery 
tests collectLeaf for query

//initialise term

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 231 before 
term1=new org.apache.lucene.index.Term('field','withPayload')");
org.apache.lucene.index.Term term1=new org.apache.lucene.index.Term("field", 
"withPayload");
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 233 term1="+term1);

//assume position is 5
int position=5;
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 235 
position="+position);

BytesRef pay = new BytesRef("pos: " + position);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 237 pay="+pay);

//build spanQuery with term parameter
org.apache.lucene.search.spans.SpanQuery spanQuery1 = new 
SpanTermQuery(term1);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 239 
spanQuery1="+spanQuery1);

//add BytesRef to payloadToMatch list
java.util.List payloadToMatch=new 
java.util.ArrayList();
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 241 
payloadToMatch="+payloadToMatch);
payloadToMatch.add(pay);


//build SpanPayloadCheckQuery

query=new org.apache.lucene.queries.payloads.SpanPayloadCheckQuery(
(org.apache.lucene.search.spans.SpanQuery)query,
(java.util.List)payloadToMatch);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 249 query="+query);

//build lucene Directory (TODO: we should use an existing directory with REAL 
test-data)
org.apache.lucene.store.Directory ram = 
newDirectory(com.carrotsearch.randomizedtesting.RandomizedContext.current().getRandom());

//build SegmentReader from Directory
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 251 ram="+ram);
SegmentReader reader = 
getOnlySegmentReader(org.apache.lucene.index.DirectoryReader.open(ram));
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 253 
reader="+reader);

//populate SlowCompositeReaderWrapper with SegmentReader
org.apache.lucene.index.LeafReader sr = 
org.apache.lucene.index.SlowCompositeReaderWrapper.wrap(reader);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 255 sr="+sr);

//add term to SegmentReader postings
org.apache.lucene.index.PostingsEnum postings = sr.postings(term1, 
PostingsEnum.PAYLOADS);

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);

//display the parameters for collectLeaf method for query:
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where position="+position);

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);
try
{ //public void collectLeaf(org.apache.lucene.index.Po

Re: Release 6.6

[Martin Gainty]

 
everything is working as expected with SpanPayloadCheckQuery for me now.   Do 
your tests point out an issue?   Or confirming that it is working properly at a 
lower level?

Erik


On Apr 29, 2017, at 9:08 AM, Martin Gainty 
<mgai...@hotmail.com<mailto:mgai...@hotmail.com>> wrote:

Martin Gainty has shared a OneDrive file with you. To view it, click the link 
below.


<https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
[https://r1.res.office365.com/owa/prem/images/dc-generic_20.png]<https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>

TestPayloadCheckQuery.java<https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>



attached

I coded this last nite so it is "quick and dirty"

in any case let me know if  testSpanPayloadCheck() method modification properly 
addresses your situation

Thanks!
Martin
__




From: Erik Hatcher <erik.hatc...@gmail.com<mailto:erik.hatc...@gmail.com>>
Sent: Saturday, April 29, 2017 8:58 AM
To: dev@lucene.apache.org<mailto:dev@lucene.apache.org>
Subject: Re: Release 6.6

Martin - there is a test class specifically for this query.   See the recent 
commits I've made to test it further fixing .equals/.hashCode and rewrite.

Can you send your full test code?

   Erik

On Apr 29, 2017, at 07:32, Martin Gainty 
<mgai...@hotmail.com<mailto:mgai...@hotmail.com>> wrote:

when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was about to 
reply just run that TestCase
(until i discovered there wasnt any!)

i'll start the bidding at 1 dinar for TestCase 
org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:
  @org.junit.Test
  public void testSpanPayloadCheck() throws Exception


//now lets test the collectLeaf for query
//of course calling Base Class SpanPayloadCheckQuery to construct query

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where position="+position);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);

try
{ //test public void collectLeaf(org.apache.lucene.index.PostingsEnum 
postings, int position,  //org.apache.lucene.index.Term term) 
throws java.io.IOException {
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1);
}
catch(java.io.IOException ioe) { 
log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws IOException 
="+ioe.getMessage()); }


unless of course anyone has a better idea to test collectLeaf ?
Martin
__




From: Erik Hatcher <erik.hatc...@gmail.com<mailto:erik.hatc...@gmail.com>>
Sent: Tuesday, April 25, 2017 7:57 PM
To: dev@lucene.apache.org<mailto:dev@lucene.apache.org>
Subject: Re: Release 6.6

Probably no bribe needed, but an updated patch would be a good start (or will 
the 2.5 year old patch still apply and be acceptable as-is?)

Erik

On Apr 25, 2017, at 7:52 PM, Walter Underwood 
<wun...@wunderwood.org<mailto:wun...@wunderwood.org>> wrote:

Who do I have to bribe to get SOLR-629 included?

https://issues.apache.org/jira/browse/SOLR-629

wunder
Walter Underwood
wun...@wunderwood.org<mailto:wun...@wunderwood.org>
http://observer.wunderwood.org/  (my blog)


On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya 
<ichattopadhy...@gmail.com<mailto:ichattopadhy...@gmail.com>> wrote:

Hi,
We have lots of changes, optimizations, bug fixes for 6.6. I'd like to propose 
a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0 release).

I can volunteer to release this, and I can cut the release branch around 4th 
May, in order to let some time for devs to finish current issues.

What do you think?

Regards,
Ishan

Re: Release 6.6

[Martin Gainty]

Martin Gainty has shared a OneDrive file with you. To view it, click the link 
below.


<https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>
[https://r1.res.office365.com/owa/prem/images/dc-generic_20.png]<https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>

TestPayloadCheckQuery.java<https://1drv.ms/u/s!AkpuiYcNg4cSgWRHc6DadiCIYaFN>




attached


I coded this last nite so it is "quick and dirty"

in any case let me know if  testSpanPayloadCheck() method modification properly 
addresses your situation


Thanks!

Martin
__




From: Erik Hatcher <erik.hatc...@gmail.com>
Sent: Saturday, April 29, 2017 8:58 AM
To: dev@lucene.apache.org
Subject: Re: Release 6.6

Martin - there is a test class specifically for this query.   See the recent 
commits I've made to test it further fixing .equals/.hashCode and rewrite.

Can you send your full test code?

   Erik

On Apr 29, 2017, at 07:32, Martin Gainty 
<mgai...@hotmail.com<mailto:mgai...@hotmail.com>> wrote:


when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was about to 
reply just run that TestCase
(until i discovered there wasnt any!)


i'll start the bidding at 1 dinar for TestCase 
org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:

  @org.junit.Test
  public void testSpanPayloadCheck() throws Exception


//now lets test the collectLeaf for query
//of course calling Base Class SpanPayloadCheckQuery to construct query

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where position="+position);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);

try
{ //test public void collectLeaf(org.apache.lucene.index.PostingsEnum 
postings, int position,  //org.apache.lucene.index.Term term) 
throws java.io.IOException {
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1);
}
catch(java.io.IOException ioe) { 
log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws IOException 
="+ioe.getMessage()); }


unless of course anyone has a better idea to test collectLeaf ?

Martin
__




From: Erik Hatcher <erik.hatc...@gmail.com<mailto:erik.hatc...@gmail.com>>
Sent: Tuesday, April 25, 2017 7:57 PM
To: dev@lucene.apache.org<mailto:dev@lucene.apache.org>
Subject: Re: Release 6.6

Probably no bribe needed, but an updated patch would be a good start (or will 
the 2.5 year old patch still apply and be acceptable as-is?)

Erik

On Apr 25, 2017, at 7:52 PM, Walter Underwood 
<wun...@wunderwood.org<mailto:wun...@wunderwood.org>> wrote:

Who do I have to bribe to get SOLR-629 included?

https://issues.apache.org/jira/browse/SOLR-629

wunder
Walter Underwood
wun...@wunderwood.org<mailto:wun...@wunderwood.org>
http://observer.wunderwood.org/  (my blog)


On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya 
<ichattopadhy...@gmail.com<mailto:ichattopadhy...@gmail.com>> wrote:

Hi,
We have lots of changes, optimizations, bug fixes for 6.6. I'd like to propose 
a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0 release).

I can volunteer to release this, and I can cut the release branch around 4th 
May, in order to let some time for devs to finish current issues.

What do you think?

Regards,
Ishan

Re: Release 6.6

[Martin Gainty]

when Erik mentioned he couldnt get SpanPayloadCheckQuery to work I was about to 
reply just run that TestCase
(until i discovered there wasnt any!)


i'll start the bidding at 1 dinar for TestCase 
org.apache.lucene.queries.payloads.TestPayloadCheckQuery mod:

  @org.junit.Test
  public void testSpanPayloadCheck() throws Exception


//now lets test the collectLeaf for query
//of course calling Base Class SpanPayloadCheckQuery to construct query

log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 257 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where postings="+postings);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 258 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where position="+position);
log.debug("TestPayloadCheckQuery::testSpanPayloadCheck LINE 259 before 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) where term1="+term1);

try
{ //test public void collectLeaf(org.apache.lucene.index.PostingsEnum 
postings, int position,  //org.apache.lucene.index.Term term) 
throws java.io.IOException {
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1);
}
catch(java.io.IOException ioe) { 
log.error("TestPayloadCheckQuery::testSpanPayloadCheck LINE 264 
query.getPayloadChecker().collectLeaf((org.apache.lucene.index.PostingsEnum)postings,
 (int)position,(org.apache.lucene.index.Term)term1) LINE 106 throws IOException 
="+ioe.getMessage()); }


unless of course anyone has a better idea to test collectLeaf ?

Martin
__




From: Erik Hatcher 
Sent: Tuesday, April 25, 2017 7:57 PM
To: dev@lucene.apache.org
Subject: Re: Release 6.6

Probably no bribe needed, but an updated patch would be a good start (or will 
the 2.5 year old patch still apply and be acceptable as-is?)

Erik

On Apr 25, 2017, at 7:52 PM, Walter Underwood 
> wrote:

Who do I have to bribe to get SOLR-629 included?

https://issues.apache.org/jira/browse/SOLR-629

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)


On Apr 25, 2017, at 10:46 AM, Ishan Chattopadhyaya 
> wrote:

Hi,
We have lots of changes, optimizations, bug fixes for 6.6. I'd like to propose 
a 6.6 release (perhaps the last 6x non-bug-fix release before 7.0 release).

I can volunteer to release this, and I can cut the release branch around 4th 
May, in order to let some time for devs to finish current issues.

What do you think?

Regards,
Ishan

Re: Developer's Guide

[Martin Gainty]

obrigado marco!


Martin
__



From: David Smiley 
Sent: Friday, March 3, 2017 9:20 PM
To: dev@lucene.apache.org
Subject: Re: Developer's Guide

I send my condolences Marco.

On Fri, Mar 3, 2017 at 5:36 PM Marco Reis 
> wrote:
I'm writing a book about Lucene and text processing in Portuguese (ok, maybe 
I'm masochist) and I can say the evolution is really fast. I started in version 
5 and I had to update to version 6. Now I have 60% ready, but we are in version 
6.4 and going on...




Marco Reis
Software Architect
http://marcoreis.net
https://github.com/masreis
+55 61 981194620

2017-03-03 15:32 GMT-03:00 Christine Poerschke (BLOOMBERG/ LONDON) 
>:
Somewhat related, any thoughts on combining the two 'How to Contribute to ...' 
wiki pages into a unified 'How to Contribute' under 
lucene.apache.org itself?

https://wiki.apache.org/lucene-java/HowToContribute
https://wiki.apache.org/solr/HowToContribute

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: 03/03/17 17:31:10

(not directly relevant to the topic, but I do have an empty
https://github.com/arafalov/solr-contributor-guide )

The problem with writing the book for Lucene/Solr is that the project
moves too fast for conventional print time. I kept having to rewrite
first 3 chapters completely because of the rapid changes.

If anybody is masochistic, I would recommend taking a smaller slice of
the project and writing about that in an intense spike and
self-publishing. I could offer a couple of Solr titles that I have on
the back-burner .

Regards,
   Alex.
P.s. There are no developer guides. Worse, there are no "pain point
guides either". Perhaps if somebody started the "pain-points" one, we
could then build the "developer guide" on top of it.
P.p.s. There is a "working with git for Lucene/Solr repo" guide
somewhere actually. But that's different. Also, consider using a
shallow git clone when getting the repo. Latest Git still allows to
commit from that and you may save yourself some significant
bandwidth/disk space.


http://www.solr-start.com/ - Resources for Solr users, new and experienced


On 3 March 2017 at 11:26, Doug Turnbull
>
 wrote:
> As an aside, I'm pretty sure if anyone wanted to write a new edition of
> Lucene in Action, and you're masochistic enough to write a book for a top
> tier tech book publisher, I'd be happy to introduce you to someone at
> Manning :)
>
> And Lucene In Action is a very good read, will help you get the big ideas,
> even if the examples are outdated
>
> -Doug
>
> On Fri, Mar 3, 2017 at 11:23 AM David Smiley 
> >
> wrote:
>>
>> Hi,
>> There is no developer's guide.  There are Javadocs, and there's an
>> outdated book (although the concepts are still good but it's the details
>> that have changed).
>> ~ David
>>
>> On Fri, Mar 3, 2017 at 11:16 AM Nilesh Kamani 
>> >
>> wrote:
>>>
>>> Could anybody please help me with this ?
>>>
>>> On Wed, Mar 1, 2017 at 9:22 AM, Nilesh Kamani 
>>> >
>>> wrote:

 Hello All,

 Are there any Developer's Guide to understand various packages and
 classes and their role ?
 I am looking to modify boolean AND search to meet some specific
 criteria.

 Thanks,
 Nilesh Kamani


>>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com

-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org



--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

Re: Welcome Toke Eskildsen as a Lucene/Solr committer

[Martin Gainty]

Held og lykke Toke!

Martin
__




From: Adrien Grand 
Sent: Tuesday, February 14, 2017 8:02 AM
To: dev@lucene.apache.org
Subject: Re: Welcome Toke Eskildsen as a Lucene/Solr committer

Welcome Toke!

Le mar. 14 févr. 2017 à 13:09, Jan Høydahl 
> a écrit :
I'm pleased to announce that Toke Eskildsen has accepted the Lucene
PMC's invitation to become a committer.

Toke, it's tradition that you introduce yourself with a brief bio.

Your account "toke" has been added to the “lucene" LDAP group, so you
now have commit privileges. Please test this by adding yourself to the
committers section of the Who We Are page on the website:
 (instructions here
).

The ASF dev page also has lots of useful links: .

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

-
To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Welcome Jim Ferenczi as a Lucene/Solr committer

[Martin Gainty]

Benvenuto Signore Ferenczi!


Martini
__

From: Shalin Shekhar Mangar 
Sent: Sunday, January 1, 2017 7:31 AM
To: dev@lucene.apache.org
Subject: Re: Welcome Jim Ferenczi as a Lucene/Solr committer

Congratulations and welcome Jim!

On Sun, Jan 1, 2017 at 3:35 PM Michael McCandless 
> wrote:
I'm pleased to announce that Jim Ferenczi has accepted the Lucene

PMC's invitation to become a committer.



Jim, it's tradition that you introduce yourself with a brief bio.



Your handle "jimczi" has been added to the "lucene" LDAP group, so you

now have commit privileges. Please test this by adding yourself to the

committers section of the Who We Are page on the website:

 (instructions here

).



The ASF dev page also has lots of useful links: .



Congratulations and welcome and Happy New Year,



Mike McCandless



http://blog.mikemccandless.com



-

To unsubscribe, e-mail: 
dev-unsubscr...@lucene.apache.org

For additional commands, e-mail: 
dev-h...@lucene.apache.org

Re: Welcome Mikhail Khludnev to the PMC

[Martin Gainty]

welcome Mikhail!


Martin
__



From: Erick Erickson 
Sent: Friday, December 30, 2016 11:31 AM
To: dev@lucene.apache.org
Subject: Re: Welcome Mikhail Khludnev to the PMC

Congrats Mikhail! Well deserved...

On Fri, Dec 30, 2016 at 8:27 AM, Shalin Shekhar Mangar
 wrote:
> Welcome Mikhail!
>
> On Fri, Dec 30, 2016 at 8:45 PM, Adrien Grand  wrote:
>> I am pleased to announce that Mikhail Khludnev has accepted the PMC's
>> invitation to join.
>>
>> Welcome Mikhail!
>>
>> Adrien
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> 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: Kudos to Jan

[Martin Gainty]

many apache projects contain 2 groups of people

-managers who get the credit for the project
-contributors who do the work for the project

I would like to see Jan the contributor promoted  to the group who gets credit 
for the project
Agreed?
Martin 
__ 



From: compuwizard...@gmail.com
Date: Wed, 28 Sep 2016 11:58:24 -0500
Subject: Re: Kudos to Jan
To: dev@lucene.apache.org

Definitely a great effort. Not only closing/cleaning up JIRAs but putting in a 
lot of effort to making logging more sane.Kevin Risden


On Wed, Sep 28, 2016 at 11:50 AM, Alexandre Rafalovitch  
wrote:
+1



I tried doing that too, so I know the effort it takes :-)



Regards,

   Alex.



Newsletter and resources for Solr beginners and intermediates:

http://www.solr-start.com/





On 28 September 2016 at 23:10, David Smiley  wrote:

> Yes; thanks Jan!

>

>

> On Wed, Sep 28, 2016 at 11:38 AM Erick Erickson 

> wrote:

>>

>> Jan:

>>

>> Wanted to send a public thanks for your efforts to clean up old JIRAs.

>> We even have more JIRAs closed than opened in the last 30 days!

>>

>> It's a thankless task, much appreciated.

>>

>> Erick

>>

>> -

>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org

>> For additional commands, e-mail: dev-h...@lucene.apache.org

>>

> --

> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:

> http://www.solrenterprisesearchserver.com



-

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org

For additional commands, e-mail: dev-h...@lucene.apache.org




  

RE: Java function throws exception on JSP web application

[Martin Gainty]

NoMethodFoundError is wrong servlet jar you cannot mix servlet-api.jar that 
does not meet the current Java Servlet Spec supported for your webapp
https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api
cannot override final class means exactly that ..any class that attempts to 
override a final class will throw that exception
select another class with commensurate functionality that isnt final to 
override or just use concrete implementation of final class itself
https://coderanch.com/t/410683/java/java/final-class
Martin-
> Date: Mon, 5 Sep 2016 00:41:54 -0700
> From: reg9sz...@freemail.hu
> To: dev@lucene.apache.org
> Subject: Re: Java function throws exception on JSP web application
> 
> Now, I became angry with silly errors. I created a new web application,
> copied the jars ini it, and now it works fine. 
> 
> But I have no idea, wat is the difference between the two applications.
> 
> 
> 
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/Java-function-throws-exception-on-JSP-web-application-tp4294431p4294632.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
  

RE: Congratulations to the new Lucene/Solr PMC Chair, Tommaso Teofili

[Martin Gainty]

Buona Fortuna Tommaso!
Martini
__ 


From: luc...@mikemccandless.com
Date: Wed, 15 Jun 2016 18:36:54 -0400
Subject: Congratulations to the new Lucene/Solr PMC Chair, Tommaso Teofili
To: dev@lucene.apache.org

Once a year the Lucene PMC rotates the PMC chair and Apache Vice President 
position.
This year we have nominated and elected Tommaso Teofili as the chair, and today 
the board just approved it, so now it's official.
Congratulations Tommaso!
Mike McCandless

http://blog.mikemccandless.com
  

RE: Assignment about Lucene and Android

[Martin Gainty]

i do not see NIOConnector in main body of android source?
https://source.android.com/source/index.html
but I do see NIOConnector extension availability in googlesource

https://android.googlesource.com/platform/external/jetty/+/marshmallow-dev/src/java/org/eclipse/jetty/servlet/DefaultServlet.java
Manfred can you confirm NIOConnector capability in Android?

/danke/Martin 
__ 



From: adrian.dominik.szymc...@gmail.com
Date: Tue, 7 Jun 2016 15:45:04 +0200
Subject: Re: Assignment about Lucene and Android
To: dev@lucene.apache.org

Hi Michael,

Thank you for such quick response. I have found this at 
https://github.com/lukhnos/mobilelucene at section "Porting Lucene to Android"

I understand lack of NIO.2 and some libraries but part "Because it's cumbersome 
to load Java resources in Android, and combining metadata in JAR files when 
DEXing is also a complicated task, I've also made changes to the SPI loading 
mechanism in Lucene so that it uses a hard-coded list of "loaded" classes." is 
rather hard to understand and some extention would be much appreciated.

Regards,
Adrian
2016-06-07 15:37 GMT+02:00 Michael McCandless :
Hi Adrian,
Alas I am not an expert on Android, and I don't think I wrote that fragment!  
Where did you find it?
Can you send an email to the Lucene dev list (dev@lucene.apache.org) asking 
this question?Mike

http://blog.mikemccandless.com

On Tue, Jun 7, 2016 at 7:18 AM, Adrian Szymczak 
 wrote:
Hi,I am ​working on assignment for class at university and ​use marvelous​ 
project​ I see you are one of main contributors - from what I've determined the 
most advanced mobile lucene port there is 
​https://github.com/lukhnos/mobilelucene In one part I have to explain problems 
with porting Lucene to Android and foud fragment you've written​ in description 
of project​:"Because it's cumbersome to load Java resources in Android, and 
combining metadata in JAR files when DEXing is also a complicated task, I've 
also made changes to the SPI loading mechanism in Lucene so that it uses a 
hard-coded list of "loaded" classes.
There are a few more changes needed. I'll try to document them in detail when I 
find the time."Do you think it would be possible for you to elaborate on the 
subject a little bit more? I was writing to some other contributors but would 
be thankful for your personal input.​Kindest ​Regards,Adrian Szymczak



  

RE: Welcome Scott Blum as a Lucene/Solr committer!

[Martin Gainty]

Glad to have you on board Scott!
Martin  




Date: Tue, 19 Apr 2016 08:46:20 -0400
Subject: Re: Welcome Scott Blum as a Lucene/Solr committer!
From: daddy...@gmail.com
To: dev@lucene.apache.org

Welcome, Scott!Karl
On Tue, Apr 19, 2016 at 8:38 AM, Otis Gospodnetic  
wrote:
Another welcome...from NYC subway ;)
Otis
On Apr 19, 2016, at 05:21, Shalin Shekhar Mangar  wrote:

I'm pleased to announce that Scott Blum has accepted the Lucene PMC's 
invitation to become a committer.Scott, it's tradition that you introduce 
yourself with a brief bio.Your handle "dragonsinth" has already added to the 
“lucene" LDAP group, so you now have commit privileges. Please test this by 
adding yourself to the committers section of the Who We Are page on the 
website:  (use the ASF CMS bookmarklet 
at the bottom of the page here:  - more info 
here ).The ASF dev page also has lots of 
useful links: .Congratulations and welcome!
-- 
Regards,
Shalin Shekhar Mangar.



  

RE: Apache Solr and Tika used to index Panama Papers

[Martin Gainty]

last time I traveled into Panama City there were a TON of high-rollers with 
silk suits wearing Gucci Shoes on board the plane
(I of course thought it was for the annual Latin American Star-Trek convention)

Thanks Uwe (and Dave)
Martin 
__ 

  


Date: Wed, 6 Apr 2016 09:00:00 -0400
Subject: Re: Apache Solr and Tika used to index Panama Papers
From: joels...@gmail.com
To: dev@lucene.apache.org

Wonder if they were on the users list!Joel 
Bernsteinhttp://joelsolr.blogspot.com/


On Wed, Apr 6, 2016 at 8:57 AM, David Smiley  wrote:
 awesome
On Wed, Apr 6, 2016 at 4:45 AM Uwe Schindler  wrote:
Hi all,



I just wanted to repost the following by Chris Mattman on the TIKA list:



If you have been following the news you’ve seen the Panama papers and how the 
world’s rich and elite have been storing all their money offshore to hide it. 
Two of the ASF’s key technologies were used in uncovering that story and 
showing the world what was going on: Apache Tika and Apache Solr.



Solr was used for making the Terabytes of Panama Papers available to 
journalists. The preprocessing of the documents for indexing was done with Tika 
(maybe through the contrib/extraction module).



Here is the article by Forbes about that:

http://www.forbes.com/sites/thomasbrewster/2016/04/05/panama-papers-amazon-encryption-epic-leak



Uwe



-

Uwe Schindler

uschind...@apache.org

ASF Member, Apache Lucene PMC / Committer

Bremen, Germany

http://lucene.apache.org/







-

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org

For additional commands, e-mail: dev-h...@lucene.apache.org



-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, SpeakerLinkedIn: 
http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com

  

RE: Welcome Karl Wright as a Lucene/Solr committer!

[Martin Gainty]

would like to hear more on how to search GIS Objects using Lat/Long inputs
my immediate interest is identifying Rock Glacier Formations in the 
Andeshttps://en.wikipedia.org/wiki/Rock_glacier

Bienvenidos Karl
Martin 
__ 

   


> From: rcm...@gmail.com
> Date: Mon, 4 Apr 2016 11:53:57 -0400
> Subject: Re: Welcome Karl Wright as a Lucene/Solr committer!
> To: dev@lucene.apache.org
> 
> Welcome Karl!
> 
> On Mon, Apr 4, 2016 at 10:40 AM, Karl Wright  wrote:
> > Hi all,
> >
> > Professionally, I've been active in software development since the 1970's.
> > My interests include many things related to software development, as well as
> > areas as varied as geology, carpentry, and gardening.  I'm the PMC chair for
> > the ManifoldCF project, as well as a committer on other Apache projects such
> > as Http Components.
> >
> > My current employer is HERE, Inc, who is a spin-off from Nokia, who sells
> > map data, services, and search capabilities.
> >
> > I'm also the contributor and principal author of the Geo3D package, which is
> > now part of Lucene under the spatial3d module.  I intend to continue to
> > contribute to this package for the foreseeable future.
> >
> > Thanks!!
> > Karl
> >
> >
> > On Mon, Apr 4, 2016 at 10:28 AM, Michael McCandless
> >  wrote:
> >>
> >> I'm pleased to announce that Karl Wright has accepted the Lucene PMC's
> >> invitation to become a committer.
> >>
> >> Karl, it's tradition that you introduce yourself with a brief bio.
> >>
> >> Karma has been granted to your pre-existing account, so that you can
> >> add yourself to the committers section of the Who We Are page on the
> >> website: http://lucene.apache.org/whoweare.html
> >>
> >> Congratulations and welcome!
> >>
> >> Mike McCandless
> >>
> >> http://blog.mikemccandless.com
> >
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
  

RE: Test Issues

[Martin Gainty]

 
MG>scroll down to org.apache.solr.BaseDistributedSearchTestCase.java
MG>public static String compare(SolrDocumentList a, SolrDocumentList b, int 
flags, Map handle)

From: david.w.smi...@gmail.com
Date: Mon, 28 Mar 2016 19:22:28 +
Subject: Re: Test Issues
To: dev@lucene.apache.org

https://issues.apache.org/jira/browse/SOLR-6612

On Mon, Mar 28, 2016 at 3:19 PM Mike Drob  wrote:
Thanks, David. Is there a JIRA associated with this known issue?

Now that I knew what I was looking for, I had to also skip timestamp and 
_version_, but after that everything works as expected.

On Mon, Mar 28, 2016 at 12:10 PM, David Smiley  wrote:
Most likely you need to add this to your test:handle.put("maxScore", SKIPVAL);

There is a known issue in which wether maxScore is returned or not in 
distributed search vs non-distributed is inconsistent, in the event you didn't 
ask for the score explicitly (e.g. by setting 'fl=score')
On Mon, Mar 28, 2016 at 3:07 PM Mike Drob  wrote:
I feel like I have to be missing something simple, and yet I find myself asking 
on the mailing list. I've narrowed down my failing test to something that I 
don't think it related to my code changes at all and I'm struggling to 
understand what I'm failing to set up correctly in this environment.

This test consistently fails for me:

public class MyTest extends BaseDistributedSearchTestCase {
  @Override
  protected String getSolrXml() {
return "solr.xml";
  }

  public MyTest() {
fixShardCount(1);
  }
  
  @Test
  public void test() throws Exception {
index(id, 1);
commit();
query("q", "*:*");
  }
}

With the following trace:

junit.framework.AssertionFailedError: .response.maxScore:1.0!=null
at __randomizedtesting.SeedInfo.seed([9EDA50B342BBA70E:5699086545248268]:0)
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:924)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:943)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:618)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:598)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:577)
at org.apache.solr.mytest.MyTrace.test(MyTest.java:61)
at ...
MG>compare method is where maxScore is tested ( or disabled with 
handle.put("maxScore", 4) )
public static String compare(SolrDocumentList a, SolrDocumentList b, int flags, 
Map handle) {boolean ordered = (flags & UNORDERED) == 0;   
 String cmp;int f = flags(handle, "maxScore");if ((f & SKIPVAL) == 0) { 
 cmp = compare(a.getMaxScore(), b.getMaxScore(), 0, handle);if (cmp 
!= null) return ".maxScore" + cmp;} else {  if (b.getMaxScore() != 
null) {  
//why not put if(b.getMaxScore()!=null)  before if  ((f & SKIPVAL) == 0) {  and 
avoid NPE
if (a.getMaxScore() == null) {  return ".maxScore missing"; 
   }  }}...return null;  }MG>why not put if(b.getMaxScore()!=null)  
before if  ((f & SKIPVAL) == 0) {  and avoid NPE
I've tried copying from existing test cases, but haven't had any luck so far. 
Any pointers on this?

Mike
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, SpeakerLinkedIn: 
http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com


-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, SpeakerLinkedIn: 
http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com   

RE: Welcome Kevin Risden as Lucene/Solr committer

[Martin Gainty]

¡Bienvenidos Kevin!
Martín 
__  
 



Date: Wed, 16 Mar 2016 14:36:32 -0700
Subject: Re: Welcome Kevin Risden as Lucene/Solr committer
From: tomasflo...@gmail.com
To: dev@lucene.apache.org

Welcome Kevin!

On Wed, Mar 16, 2016 at 1:23 PM, Kevin Risden  wrote:
Thanks for the warm welcome. Its an honor to be invited to work on

this project and with so many great people.



Bio:

I graduated from Rose-Hulman Institute of Technology in 2012. My

undergrad revolved around software development, software testing, and

robotics. In early 2013, I joined Avalon Consulting, LLC, moved down

to Austin, TX, and first started using Solr. The focus at the time was

to use Solr as an analytics engine to power charts/graphs. From 2013

on, I worked a lot on Hadoop and Solr integrations with a continued

focus on analytics. Providing training and education are two areas

that I am really passionate about. In addition to my regular work, I

have been improving the SolrJ JDBC driver to enable more analytics use

cases.

Kevin Risden





On Wed, Mar 16, 2016 at 12:55 PM, Anshum Gupta  wrote:

> Congratulations and Welcome Kevin!

>

> On Wed, Mar 16, 2016 at 10:03 AM, David Smiley 

> wrote:

>>

>> Welcome Kevin!

>>

>> (corrected misspelling of your last name in the subject)

>>

>> On Wed, Mar 16, 2016 at 1:02 PM Joel Bernstein  wrote:

>>>

>>> I'm pleased to announce that Kevin Risden has accepted the PMC's

>>> invitation to become a committer.

>>>

>>> Kevin, it's tradition that you introduce yourself with a brief bio.

>>>

>>> I believe your account has been setup and karma has been granted so that

>>> you can add yourself to the committers section of the Who We Are page on the

>>> website:

>>> .

>>>

>>> Congratulations and welcome!

>>>

>>>

>>> Joel Bernstein

>>>

>> --

>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:

>> http://www.solrenterprisesearchserver.com

>

>

>

>

> --

> Anshum Gupta



-

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org

For additional commands, e-mail: dev-h...@lucene.apache.org




  

[jira] [Commented] (SOLR-8789) CollectionAPISolrJTests is not run when running ant test

[Martin Gainty (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15180774#comment-15180774
 ] 

Martin Gainty commented on SOLR-8789:
-

anshum/eric 

solr-5.3.1>find . -name *Test*.java
?

can you be specific on which filenames e.g. *Test*.java are *supposed to be* 
located in solr
?

> CollectionAPISolrJTests is not run when running ant test
> 
>
> Key: SOLR-8789
> URL: https://issues.apache.org/jira/browse/SOLR-8789
> Project: Solr
>  Issue Type: Bug
>Reporter: Anshum Gupta
>
> The pattern that is used to run the tests on Jenkins (ant test) is (from 
> lucene/common-build.xml) :
> {code}
> 
> 
> {code}
> CollectionAPISolrJTests ends in an extra 's' and so is not executed. We need 
> to either fix the pattern or the test name to make sure that this test is run.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: ant idea and IntelliJ 15

[Martin Gainty]

From: risd...@avalonconsult.com
Date: Wed, 24 Feb 2016 07:26:18 -0600
Subject: Re: ant idea and IntelliJ 15
To: dev@lucene.apache.org


On Wed, Feb 24, 2016 at 3:47 AM, Jan Høydahl  wrote:
Not sure if the problem started after I upgraded to IntelliJ 15 or after we 
switched to git or what. Others having the same issues?
I haven't had any issues using IntellJ 14, 15 or 16 EAP with lucene-solr before 
or after switching to Git. I've cloned and cleaned out the IntelliJ settings 
multiple times and haven't had any issues opening the project in IntelliJ after 
doing "ant idea".
Kevin Risden
Hadoop Tech Lead | Avalon Consulting, LLCM: 732 213 8417LinkedIn | Google+ | 
Twitter

MG>Kevin..would you know of a GIT macrodef which can sub for build.xml 
svn-checker macrodef?
 
 
   
  
   
  
  
  
MG>svn-checker invoked thru check-svn-working-copy target in build.xml
  
  
MG>Thanks Kevin!
-This
 message (including any attachments) contains confidential information intended 
for a specific individual and purpose, and is protected by law. If you are not 
the intended recipient, you should delete this message. Any disclosure, 
copying, or distribution of this message, or the taking of any action based on 
it, is strictly prohibited.
  

RE: ant idea and IntelliJ 15

[Martin Gainty]

Jan
I spent a day attempting to determine the lifecycle for ant build.xml targets 
then I retasked the build to implement maven pom.xml(s)

I have all pom.xml which pre-compile,compile,run testcases and build jars for 
Project Lucene ..Here is listing of Lucene pom.xml's
./lucene/pom.xml   ./lucene/analysis/pom.xml   ./lucene/analysis/common/pom.xml./lucene/analysis/icu/pom.xml./lucene/analysis/kuromoji/pom.xml./lucene/analysis/morfologik/pom.xml./lucene/analysis/phonetic/pom.xml./lucene/analysis/smartcn/pom.xml./lucene/analysis/stempel/pom.xml./lucene/analysis/uima/pom.xml./lucene/build/poms/pom.xml
   ./lucene/build/poms/lucene/pom.xml ./lucene/build/poms/lucene/backward-codecs/pom.xml./lucene/build/poms/lucene/benchmark/pom.xml./lucene/build/poms/lucene/classification/pom.xml./lucene/build/poms/lucene/codecs/pom.xml./lucene/build/poms/lucene/core/pom.xml./lucene/build/poms/lucene/demo/pom.xml./lucene/build/poms/lucene/expressions/pom.xml./lucene/build/poms/lucene/facet/pom.xml./lucene/build/poms/lucene/grouping/pom.xml./lucene/build/poms/lucene/highlighter/pom.xml./lucene/build/poms/lucene/join/pom.xml./lucene/build/poms/lucene/memory/pom.xml./lucene/build/poms/lucene/misc/pom.xml./lucene/build/poms/lucene/queries/pom.xml./lucene/build/poms/lucene/queryparser/pom.xml./lucene/build/poms/lucene/replicator/pom.xml./lucene/build/poms/lucene/sandbox/pom.xml./lucene/build/poms/lucene/spatial/pom.xml./lucene/build/poms/lucene/spatial3d/pom.xml./lucene/build/poms/lucene/suggest/pom.xml./lucene/build/poms/lucene/test-framework/pom.xml
./lucene/build/poms/solr/pom.xml./lucene/build/poms/solr/contrib/pom.xml  ./lucene/build/poms/solr/contrib/analysis-extras/pom.xml./lucene/build/poms/solr/contrib/analytics/pom.xml./lucene/build/poms/solr/contrib/clustering/pom.xml./lucene/build/poms/solr/contrib/dataimporthandler/pom.xml./lucene/build/poms/solr/contrib/dataimporthandler-extras/pom.xml./lucene/build/poms/solr/contrib/extraction/pom.xml./lucene/build/poms/solr/contrib/langid/pom.xml./lucene/build/poms/solr/contrib/map-reduce/pom.xml./lucene/build/poms/solr/contrib/morphlines-cell/pom.xml./lucene/build/poms/solr/contrib/morphlines-core/pom.xml./lucene/build/poms/solr/contrib/uima/pom.xml./lucene/build/poms/solr/contrib/velocity/pom.xml
./lucene/build/poms/solr/core/pom.xml./lucene/build/poms/solr/solrj/pom.xml./lucene/build/poms/solr/test-framework/pom.xml
./lucene/core/pom.xml ./lucene/core/experimental/pom.xml./lucene/test-framework/pom.xml  ./lucene/test-framework/experimental/pom.xml
Attaching /lucene/pom.xml for your review
I can upload the pom.xmls on my github account for you if you desire

Takk og HilsenMartin 
__ 
   


> From: jan@cominvent.com
> Subject: ant idea and IntelliJ 15
> Date: Wed, 24 Feb 2016 10:47:46 +0100
> To: dev@lucene.apache.org
> 
> Hi
> 
> Recently, ant idea does not set up my IntelliJ correctly. Source paths to 
> basic things like solr-core are missing, a broken reference int Ant.xml to 
> lucene/test-framework/lib/ant-1.8.2.jar etc.
> 
> Not sure if the problem started after I upgraded to IntelliJ 15 or after we 
> switched to git or what. Others having the same issues?
> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
  

pom.xml
Description: XML document

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: State of Michigan

[Martin Gainty]

To anyone who is not familiar with financial crisis facing the taxpayers of 
State of Michigan
State of Michigan is attempting to determine how to fix the schools in Detroit 
to restore heat and to fix the areas where snow has collapsed roofs
in schools and caused severe water damage and mildew. The pricetag for fixing 
the Detroit School System will be a minimum of 3.4B 
UShttps://www.mackinac.org/21919
State of Michigan is attempting to determine how to replace the Lead 
Contanimation Water System for the city of Flint MiThe pricetag for fixing the 
City of Flint water system will be a minimum of 1.5B US
This does not budget in providing lifetime care all of the children who are now 
suffering side-effects from drinking lead poisined 
waterhttp://www.wilx.com/home/headlines/Big-difference-on-Flint-fix-price-tag-366248571.html

To anyone that has attempted to collect past due monies.. interest is charged 
to a client when they fall behind in paying their bill..typically terms of 1/10 
net 90 apply which is if you pay me in 10 days I deduct 1% from your bill..if 
you wait 90 days you ADD accrued interest to principal

State of Michigan is in technical bankruptcy because they have insufficient 
funds to meet Detroit School obligation and the Flint Water obligationThe 
governor has called out the National Guard who is now delivering bottled water 
to those in Flint affected by lead poisined water
http://www.detroitnews.com/story/news/politics/2016/01/17/snyder-appeal-obama-flint-disaster-declaration/78944416/
Knowing these facts can you honestly say a Consultants LLC deserves interest on 
any past due amount from the State of Michigan..that is:The consultant needs 
that money more than the child who is sitting in a freezing cold classroom 
because their is no money to turn on heat?The consultant needs that money more 
than the child who is suffering from drinking lead-poisoned water in Flint?
Careful Dude (whatever the term dude means)..the citizens of Michigan are 
listening to your response
Martin 
__ 

   


From: mgai...@hotmail.com
To: dev@lucene.apache.org; bmal...@umich.edu
Subject: RE: LLC expense figures and interest income
Date: Mon, 8 Feb 2016 20:16:39 -0500




$3939  is chump change for professional consultants (whatever thats supposed to 
be) for local 'consultants'waste and fraud here in the commonwealth is measured 
in "millions "does anyone know where the LLC gets $3939  when City of Flint and 
State of Mi are supposedly bankrupt?Martin 
__ 
Son: Dad whats a LLC?
Father: In a consulting LLC when a consultant gets sued they are only 
responsible for an LLC Max Liability 
Son: I dont understand?
Father: Consulting Company LLC makes out like a bandit..the other guy eats 
scrod   
 > Date: Mon, 8 Feb 2016 11:06:02 -0800
> Subject: Re: LLC expense figures and interest income
> From: erickerick...@gmail.com
> To: dev@lucene.apache.org
> 
> Sorry, autocomplete failure. Wish the tax guy's name wasn't Devin.
> 
> Ignore please.
> 
> No way to delete this is there?
> 
> Erick
> 
> On Mon, Feb 8, 2016 at 10:58 AM, Erick Erickson  
> wrote:
> > And one other question from Bernadette.
> >
> > Thanks!
> > Erick
> >
> >
> > -- Forwarded message --
> > From: Bernadette Malinoski 
> > Date: Mon, Feb 8, 2016 at 10:35 AM
> > Subject: LLC expense figures and interest income
> > To: Erick Erickson 
> >
> >
> > So, on form C-EZ Devin has $3939 in expenses
> >
> > QB report has $3517 (see attached)  I think the difference might be
> > the proportion of Devin's professional fees which he was going to
> > allot to the LLC.
> >
> > Also, our UMCU interest for the Workplace Partners account is shown in
> > the attached as Other Income for the LLC.  I believe Devin has just
> > combined that with our other interest bearing accounts on the 1040.
> > That might be exactly where it belongs, but if it needs to go with the
> > business income, it would change the company numbers by just a bit on
> > all the related schedules/forms.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

  

RE: LLC expense figures and interest income

[Martin Gainty]

$3939  is chump change for professional consultants (whatever thats supposed to 
be) for local 'consultants'waste and fraud here in the commonwealth is measured 
in "millions "does anyone know where the LLC gets $3939  when City of Flint and 
State of Mi are supposedly bankrupt?Martin 
__ 
Son: Dad whats a LLC?
Father: In a consulting LLC when a consultant gets sued they are only 
responsible for an LLC Max Liability 
Son: I dont understand?
Father: Consulting Company LLC makes out like a bandit..the other guy eats 
scrod   
 > Date: Mon, 8 Feb 2016 11:06:02 -0800
> Subject: Re: LLC expense figures and interest income
> From: erickerick...@gmail.com
> To: dev@lucene.apache.org
> 
> Sorry, autocomplete failure. Wish the tax guy's name wasn't Devin.
> 
> Ignore please.
> 
> No way to delete this is there?
> 
> Erick
> 
> On Mon, Feb 8, 2016 at 10:58 AM, Erick Erickson  
> wrote:
> > And one other question from Bernadette.
> >
> > Thanks!
> > Erick
> >
> >
> > -- Forwarded message --
> > From: Bernadette Malinoski 
> > Date: Mon, Feb 8, 2016 at 10:35 AM
> > Subject: LLC expense figures and interest income
> > To: Erick Erickson 
> >
> >
> > So, on form C-EZ Devin has $3939 in expenses
> >
> > QB report has $3517 (see attached)  I think the difference might be
> > the proportion of Devin's professional fees which he was going to
> > allot to the LLC.
> >
> > Also, our UMCU interest for the Workplace Partners account is shown in
> > the attached as Other Income for the LLC.  I believe Devin has just
> > combined that with our other interest bearing accounts on the 1040.
> > That might be exactly where it belongs, but if it needs to go with the
> > business income, it would change the company numbers by just a bit on
> > all the related schedules/forms.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
  

RE: Breaking Java back-compat in Solr

[Martin Gainty]

From: ser...@gmail.com
Date: Sun, 10 Jan 2016 13:58:52 +
Subject: Re: Breaking Java back-compat in Solr
To: dev@lucene.apache.org

I think that our Maven integration only publishes Lucene/Solr artifacts to 
Maven central, but I don't think the POMs actually produce the artifacts? I 
could be wrong though ...MG>at least *not yet*

If that's the case, then we'd need to only add these to Solr's build.xml, like 
it's done in Lucene.
MG>common-build.xml jarify macrodef seems to do the heavy lifting to aggregate 
the jar  
 
   
   
 

  

MG>thanks shai...Martin
Shai

On Sun, Jan 10, 2016 at 3:35 PM Martin Gainty <mgai...@hotmail.com> wrote:



can you also add this to lucene pom.xml ?

Martin 
__ 

  


From: ser...@gmail.com
Date: Sun, 10 Jan 2016 07:57:26 +
Subject: Re: Breaking Java back-compat in Solr
To: dev@lucene.apache.org

As for SOLR-8475, I will commit it to trunk only. But I think that we should 
come up w/ concrete annotations in our code, and annotate classes as we go, to 
back our back-compat policy. I propose that we add these:

@solr.internal - this is internal API and will change without notice. No 
back-compat guarantees.
@solr.experimental - this is a candidate for a new public API, but will likely 
change until it stabilizes. No (strong) back-compat guarantees.
@solr.expert - while you can use this API, we cannot guarantee strong 
back-compat support. Will be on a per-case basis.
@solr.public - this is our public API, standard back-compat policy. Of course, 
if something needs break, we'll discuss the case, but otherwise users who use 
this API can expect to upgrade minor releases without re-compiling their code. 
Immediate candidate is SolrJ.

I also propose that until we tag all classes, we treat "no annotation" as 
@solr.internal (except for SolrJ code). That will force us to explicitly tag 
classes that we think should at least be @solr.public, since that's the only 
annotation that should draw the attention of developers.

If people agree, we can add these annotations to the build.xml, to add proper 
text to javadocs.

Shai

On Sat, Jan 9, 2016 at 2:15 AM Jack Krupansky <jack.krupan...@gmail.com> wrote:
With the talk of 6.0 coming out real soon and not waiting for new work, will 
this 6.0/5.x issue become moot and morph into an issue for 7.0/6.x?
Settling the criteria for Solr plugin API back-compat still seems urgent, but 
if the SOLR-8475 work can quickly get committed to trunk for 6.0 maybe that 
takes some of the pressure off. Still, I'd prefer that the back-compat criteria 
be settled ASAP.
-- Jack Krupansky

On Wed, Jan 6, 2016 at 10:43 AM, Yonik Seeley <ysee...@gmail.com> wrote:
On Wed, Jan 6, 2016 at 1:03 AM, Anshum Gupta <ans...@anshumgupta.net> wrote:

> As I understand, seems like there's reasonable consensus that we will:

>

> 1. provide strong back-compat for for SolrJ and REST APIs

> 2. Strive to maintain but not guarantee *strong* back-compat for Java APIs.



I think this actually represents what our current policy already is.

The sticking point is perhaps "Strive to maintain" is changing

definition to become much more lenient, to the point of being

meaningless.



Let's look at the issue that spawned this thread:

https://issues.apache.org/jira/browse/SOLR-8475  (Some refactoring to

SolrIndexSearcher)



The issue is if QueryCommand and QueryResult should be moved out of

SolrIndexSearcher in 5.x (essentially a rename), or of that rename

should only be in 6.0.  If one's desire for a class rename (of classes

that are likely to be used by plugins) overrides #2, I'd argue that

means we essentially have no #2 at all.  Or perhaps I'm not grasping

why it's really that important to rename those classes.



Regarding annotations:

Multiple people have suggested annotating classes that should remain

back compat.  If we were to do this, wouldn't we want those

annotations to cover the classes in question

(SolrIndexSearcher,QueryCommand,QueryResult)?  If not, what would they

cover and still be useful?



-Yonik



-

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org

For additional commands, e-mail: dev-h...@lucene.apache.org




  

RE: Breaking Java back-compat in Solr

[Martin Gainty]

can you also add this to lucene pom.xml ?
Martin 
__ 

  


From: ser...@gmail.com
Date: Sun, 10 Jan 2016 07:57:26 +
Subject: Re: Breaking Java back-compat in Solr
To: dev@lucene.apache.org

As for SOLR-8475, I will commit it to trunk only. But I think that we should 
come up w/ concrete annotations in our code, and annotate classes as we go, to 
back our back-compat policy. I propose that we add these:

@solr.internal - this is internal API and will change without notice. No 
back-compat guarantees.
@solr.experimental - this is a candidate for a new public API, but will likely 
change until it stabilizes. No (strong) back-compat guarantees.
@solr.expert - while you can use this API, we cannot guarantee strong 
back-compat support. Will be on a per-case basis.
@solr.public - this is our public API, standard back-compat policy. Of course, 
if something needs break, we'll discuss the case, but otherwise users who use 
this API can expect to upgrade minor releases without re-compiling their code. 
Immediate candidate is SolrJ.

I also propose that until we tag all classes, we treat "no annotation" as 
@solr.internal (except for SolrJ code). That will force us to explicitly tag 
classes that we think should at least be @solr.public, since that's the only 
annotation that should draw the attention of developers.

If people agree, we can add these annotations to the build.xml, to add proper 
text to javadocs.

Shai

On Sat, Jan 9, 2016 at 2:15 AM Jack Krupansky  wrote:
With the talk of 6.0 coming out real soon and not waiting for new work, will 
this 6.0/5.x issue become moot and morph into an issue for 7.0/6.x?
Settling the criteria for Solr plugin API back-compat still seems urgent, but 
if the SOLR-8475 work can quickly get committed to trunk for 6.0 maybe that 
takes some of the pressure off. Still, I'd prefer that the back-compat criteria 
be settled ASAP.
-- Jack Krupansky

On Wed, Jan 6, 2016 at 10:43 AM, Yonik Seeley  wrote:
On Wed, Jan 6, 2016 at 1:03 AM, Anshum Gupta  wrote:

> As I understand, seems like there's reasonable consensus that we will:

>

> 1. provide strong back-compat for for SolrJ and REST APIs

> 2. Strive to maintain but not guarantee *strong* back-compat for Java APIs.



I think this actually represents what our current policy already is.

The sticking point is perhaps "Strive to maintain" is changing

definition to become much more lenient, to the point of being

meaningless.



Let's look at the issue that spawned this thread:

https://issues.apache.org/jira/browse/SOLR-8475  (Some refactoring to

SolrIndexSearcher)



The issue is if QueryCommand and QueryResult should be moved out of

SolrIndexSearcher in 5.x (essentially a rename), or of that rename

should only be in 6.0.  If one's desire for a class rename (of classes

that are likely to be used by plugins) overrides #2, I'd argue that

means we essentially have no #2 at all.  Or perhaps I'm not grasping

why it's really that important to rename those classes.



Regarding annotations:

Multiple people have suggested annotating classes that should remain

back compat.  If we were to do this, wouldn't we want those

annotations to cover the classes in question

(SolrIndexSearcher,QueryCommand,QueryResult)?  If not, what would they

cover and still be useful?



-Yonik



-

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org

For additional commands, e-mail: dev-h...@lucene.apache.org