GitHub JIRA PR linking broken...

[David Smiley]

FYI https://issues.apache.org/jira/browse/INFRA-20253

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

Re: [DISCUSS] 8.5.2 Release?

[Noble Paul]

I just finished all the steps given in
https://cwiki.apache.org/confluence/display/LUCENE/ReleaseTodo

Please let me know if anything is missing.
I still don't see the solr release details in https://lucene.apache.org/

How do i do it?


On Thu, May 14, 2020 at 10:47 AM Noble Paul  wrote:
>
> I'll fix them today
>
> On Thu, May 14, 2020, 9:19 AM Mike Drob  wrote:
>>
>> Thanks. I’ve found one small change for the release script so far, I plan to 
>> batch all my notes together and commit them at the end of the process.
>>
>> Right now I think I’m waiting on a few final steps from 7.7.3 to complete 
>> and then we’ll be ready to roll with 8.5.2
>>
>> On Wed, May 13, 2020 at 4:59 PM Jan Høydahl  wrote:
>>>
>>> Mike, I merged latest changes to releaseWizard to branch_8_5 as well. So 
>>> you’ll be first to test the new instructions for updating the web site. So 
>>> please be prepared for discovering quirks in that part of the releaseWizard.
>>>
>>> Jan
>>>
>>> > 7. mai 2020 kl. 19:13 skrev Mike Drob :
>>> >
>>> > Devs,
>>> >
>>> > I know that we had 8.5.1 only a few weeks ago, but with the fix for 
>>> > LUCENE-9350 I think we should consider another bug-fix. I know that 
>>> > without it I will be explicitly recommending several users to stay off of 
>>> > 8.5.x on their upgrade plans. There are some pretty scary looking charts 
>>> > on SOLR-14428 that describe the impact of the bug in more detail.
>>> >
>>> > I'd be happy to volunteer as RM for this, would probably be looking at 
>>> > trying to get it a vote started sometime next week.
>>> >
>>> > Thanks,
>>> > Mike
>>> >
>>> >
>>> > https://issues.apache.org/jira/browse/SOLR-14428
>>> > https://issues.apache.org/jira/browse/LUCENE-9350
>>> >
>>> > -
>>> > 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
>>>


-- 
-
Noble Paul

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

Re: [DISCUSS] 8.5.2 Release?

[Noble Paul]

I'll fix them today

On Thu, May 14, 2020, 9:19 AM Mike Drob  wrote:

> Thanks. I’ve found one small change for the release script so far, I plan
> to batch all my notes together and commit them at the end of the process.
>
> Right now I think I’m waiting on a few final steps from 7.7.3 to complete
> and then we’ll be ready to roll with 8.5.2
>
> On Wed, May 13, 2020 at 4:59 PM Jan Høydahl  wrote:
>
>> Mike, I merged latest changes to releaseWizard to branch_8_5 as well. So
>> you’ll be first to test the new instructions for updating the web site. So
>> please be prepared for discovering quirks in that part of the releaseWizard.
>>
>> Jan
>>
>> > 7. mai 2020 kl. 19:13 skrev Mike Drob :
>> >
>> > Devs,
>> >
>> > I know that we had 8.5.1 only a few weeks ago, but with the fix for
>> LUCENE-9350 I think we should consider another bug-fix. I know that without
>> it I will be explicitly recommending several users to stay off of 8.5.x on
>> their upgrade plans. There are some pretty scary looking charts on
>> SOLR-14428 that describe the impact of the bug in more detail.
>> >
>> > I'd be happy to volunteer as RM for this, would probably be looking at
>> trying to get it a vote started sometime next week.
>> >
>> > Thanks,
>> > Mike
>> >
>> >
>> > https://issues.apache.org/jira/browse/SOLR-14428
>> > https://issues.apache.org/jira/browse/LUCENE-9350
>> >
>> > -
>> > 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: AttributeError: 'bool' object has no attribute 'setdefault'

[Chee Yong Teh]

Hi Andi,

I don't know much about pip install myself. 

I have look at the code and instead of building an egg file, I added an option 
(--wheel) so it will build a wheel file instead

elif arg == '--wheel':
wheel = True
dist = True
use_distutils = False

then pass that flag (wheel) into def compile then inside compile

if dist:
if wininst:
script_args.append('bdist_wininst')
elif with_setuptools:
script_args.append('bdist_wheel' if wheel else 'bdist_egg')
else:
script_args.append('bdist')

command line help
Distribution actions:
--use-distutils - use distutils even when setuptools is available
--wheel - generate wheel using setuptools
--bdist - generate a binary distutils-based distribution

No idea how to send in patch but I think it's straightforward changes to add 
that option to JCC so user has option to build egg or wheel file and pip 
install will work on wheel file.

Thanks,

Chee Yong


Chee Yong Teh 
27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138 
OTC Infrastructure Service of the Year & ​Global Compression Service of the Year
-Original Message-
From: Andi Vajda  
Sent: 13 May 2020 21:21
To: pylucene-dev@lucene.apache.org
Subject: RE: AttributeError: 'bool' object has no attribute 'setdefault'



On Wed, 13 May 2020, Andi Vajda wrote:

>
> On Wed, 13 May 2020, Chee Yong Teh wrote:
>
>> Thanks for your help and I got everything build and working now.
>
> Great ! (thanks for letting me know)
>
>> I have another question about pip install. I know JCC has option of 
>> bdist which will produce an egg file. However, pip install is not 
>> able to install an egg file. I know I can use easy install but I just 
>> wondering what is the steps to make a sdist or something that pip 
>> install can use from JCC command as I seen in the help of the command 
>> it mentions pip install (--egg-info and --extra-setup-arg)
>
> I know very little about pip myself, I did not implement or test these 
> features in JCC, they were contributed as patches by users in the past.

Searching the list archives, this thread seems relevant:
   
http://pylucene-users-developers-list.2474766.n2.nabble.com/Changes-to-enable-easy-install-of-packages-using-JCC-td7243054.html#a7244239

Andi..

> Patches to better support 'pip install' are welcome !
>
> Andi..
>
>> 
>> Thanks,
>> 
>> Chee Yong
>> 
>> 
>> Chee Yong Teh
>> 27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138 OTC 
>> Infrastructure Service of the Year & ​Global Compression Service of 
>> the Year -Original Message-
>> From: Andi Vajda 
>> Sent: 07 May 2020 17:01
>> To: pylucene-dev@lucene.apache.org
>> Subject: RE: AttributeError: 'bool' object has no attribute 'setdefault'
>> 
>> 
>> On Thu, 7 May 2020, Chee Yong Teh wrote:
>> 
>>> Hi Andi,
>>> 
>>> I think I got it working but there is an issue with the class name 
>>> with '.'.
>>> 
>>> In the jar there are some class name like below
>>> 
>>> public static final class SensitivityProfileIdList.Builder public 
>>> static final class SRMBreakdown.Builder
>> 
>> Yes, these are so-called inner classes.
>> 
>>> So JCC will wrap this can change the '.' to '$'
>> 
>> Which Java exposes to JCC with a '$' in place of the '.' in the name.
>> 
>>> SensitivityProfileIdList$Builder
>>> SRMBreakdown$Builder
>>> 
>>> I cannot really use this classes in python and python flag it up as 
>>> syntax error. Would it be better to use '_' instead of '$' to 
>>> replace the '.' in the class name?
>> 
>> That's definitely an option. Doing this automatically may then cause 
>> a clash with a class that uses _ already. There is a --rename flag 
>> that lets you control the name to pick:
>>
>>   --rename
>> 'full.package.path.here.SensitivityProfileIdList$Builder=SensitivityProfileIdList_Builder'
>> 
>> (you need '' around a string with literal $ in a shell command line)
>> 
>> Andi..
>> 
>>> 
>>> Thanks,
>>> 
>>> Chee Yong
>>> 
>>> 
>>> Chee Yong Teh
>>> 27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138 OTC 
>>> Infrastructure Service of the Year & ​Global Compression Service of 
>>> the Year -Original Message-
>>> From: Andi Vajda 
>>> Sent: 06 May 2020 00:34
>>> To: Chee Yong Teh 
>>> Cc: pylucene-dev@lucene.apache.org
>>> Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'
>>> 
>>> 
 On May 5, 2020, at 16:17, Chee Yong Teh 
 wrote:
 
 
 Hi Andi,
 
 Ok I have changed the command to
 
 python -m jcc --version 7.1.4 --use_full_names --include 
 /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/smart-swapclear-public-release_daru.12.
 jar --include
 /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/colt-1.2.0.jar 
 --include 
 /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/commons-math3-3.6.1.ja
 r --include /home/cheeyong 
 .teh/SMART-API-7.1.4/smart/lib/jna-5.2.0.jar
 --include

Gradle build question

[Erick Erickson]

I’m occasionally having to bump the "org.gradle.jvmargs=-Xmx2g” setting in 
gradle.properties. I usually bump it to 4g, but have no evidence that 3g 
wouldn’t work.

WDYT about making 3g the default (I volunteer)? FWIW, I’m constantly cleaning 
everything out as I switch back and forth between ant and gradle, so I’m 
probably hitting it more often than people who can just set it once and 
forgeddaboudit because it gets regenerated often. It’s no big deal for me to 
set it when I need to but if I hit it I expect others might too.

Erick

P.S. In order to see some files I’m working on getting warnings out of, I’m 
adding “-Xmaxwarns", “1” to my local defaults-java.gradle file. I’ve 
already inadvertently checked that in once, if anyone sees this in future you 
know who to blame. Ping me and I’ll fix.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] 8.5.2 Release?

[Mike Drob]

Thanks. I’ve found one small change for the release script so far, I plan
to batch all my notes together and commit them at the end of the process.

Right now I think I’m waiting on a few final steps from 7.7.3 to complete
and then we’ll be ready to roll with 8.5.2

On Wed, May 13, 2020 at 4:59 PM Jan Høydahl  wrote:

> Mike, I merged latest changes to releaseWizard to branch_8_5 as well. So
> you’ll be first to test the new instructions for updating the web site. So
> please be prepared for discovering quirks in that part of the releaseWizard.
>
> Jan
>
> > 7. mai 2020 kl. 19:13 skrev Mike Drob :
> >
> > Devs,
> >
> > I know that we had 8.5.1 only a few weeks ago, but with the fix for
> LUCENE-9350 I think we should consider another bug-fix. I know that without
> it I will be explicitly recommending several users to stay off of 8.5.x on
> their upgrade plans. There are some pretty scary looking charts on
> SOLR-14428 that describe the impact of the bug in more detail.
> >
> > I'd be happy to volunteer as RM for this, would probably be looking at
> trying to get it a vote started sometime next week.
> >
> > Thanks,
> > Mike
> >
> >
> > https://issues.apache.org/jira/browse/SOLR-14428
> > https://issues.apache.org/jira/browse/LUCENE-9350
> >
> > -
> > 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: [DISCUSS] 8.5.2 Release?

[Jan Høydahl]

Mike, I merged latest changes to releaseWizard to branch_8_5 as well. So you’ll 
be first to test the new instructions for updating the web site. So please be 
prepared for discovering quirks in that part of the releaseWizard.

Jan

> 7. mai 2020 kl. 19:13 skrev Mike Drob :
> 
> Devs,
> 
> I know that we had 8.5.1 only a few weeks ago, but with the fix for 
> LUCENE-9350 I think we should consider another bug-fix. I know that without 
> it I will be explicitly recommending several users to stay off of 8.5.x on 
> their upgrade plans. There are some pretty scary looking charts on SOLR-14428 
> that describe the impact of the bug in more detail.
> 
> I'd be happy to volunteer as RM for this, would probably be looking at trying 
> to get it a vote started sometime next week.
> 
> Thanks,
> Mike
> 
> 
> https://issues.apache.org/jira/browse/SOLR-14428
> https://issues.apache.org/jira/browse/LUCENE-9350
> 
> -
> 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: pre-commit failing

[Joel Bernstein]

Thanks Erick,

I'll give that a try.


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


On Wed, May 13, 2020 at 3:22 PM Erick Erickson 
wrote:

> Joel:
>
> 'git clean -dxf’ is your friend ;). Beware if you’re adding new files,
> ‘cause that removes everything that’s not already in git. It won’t touch
> anything you’ve added locally even if it’s not part of the remote repo.
>
> Sometimes I’ve also gotten weird stuff that’s cured with “gradlew —stop”
> if you’ve used Gradle…
>
> Erick
>
> > On May 13, 2020, at 2:33 PM, Joel Bernstein  wrote:
> >
> > A fresh clone doesn't produce this error so it looks like it is specific
> to my local repo.
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> >
> > On Wed, May 13, 2020 at 2:17 PM Joel Bernstein 
> wrote:
> > Is anybody seeing the following error on pre-commit:
> > JAR resource does not exist: core/lib/commons-beanutils-1.9.3.jar
> >
> > Thanks,
> > Joel
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

RE: AttributeError: 'bool' object has no attribute 'setdefault'

[Andi Vajda]

On Wed, 13 May 2020, Andi Vajda wrote:



On Wed, 13 May 2020, Chee Yong Teh wrote:


Thanks for your help and I got everything build and working now.


Great ! (thanks for letting me know)

I have another question about pip install. I know JCC has option of bdist 
which will produce an egg file. However, pip install is not able to install 
an egg file. I know I can use easy install but I just wondering what is the 
steps to make a sdist or something that pip install can use from JCC 
command as I seen in the help of the command it mentions pip install 
(--egg-info and --extra-setup-arg)


I know very little about pip myself, I did not implement or test these 
features in JCC, they were contributed as patches by users in the past.


Searching the list archives, this thread seems relevant:
  
http://pylucene-users-developers-list.2474766.n2.nabble.com/Changes-to-enable-easy-install-of-packages-using-JCC-td7243054.html#a7244239

Andi..


Patches to better support 'pip install' are welcome !

Andi..



Thanks,

Chee Yong


Chee Yong Teh
27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138
OTC Infrastructure Service of the Year & ​Global Compression Service of the 
Year

-Original Message-
From: Andi Vajda 
Sent: 07 May 2020 17:01
To: pylucene-dev@lucene.apache.org
Subject: RE: AttributeError: 'bool' object has no attribute 'setdefault'


On Thu, 7 May 2020, Chee Yong Teh wrote:


Hi Andi,

I think I got it working but there is an issue with the class name with 
'.'.


In the jar there are some class name like below

public static final class SensitivityProfileIdList.Builder public
static final class SRMBreakdown.Builder


Yes, these are so-called inner classes.


So JCC will wrap this can change the '.' to '$'


Which Java exposes to JCC with a '$' in place of the '.' in the name.


SensitivityProfileIdList$Builder
SRMBreakdown$Builder

I cannot really use this classes in python and python flag it up as
syntax error. Would it be better to use '_' instead of '$' to replace
the '.' in the class name?


That's definitely an option. Doing this automatically may then cause a 
clash with a class that uses _ already. There is a --rename flag that lets 
you control the name to pick:


  --rename 
'full.package.path.here.SensitivityProfileIdList$Builder=SensitivityProfileIdList_Builder'


(you need '' around a string with literal $ in a shell command line)

Andi..



Thanks,

Chee Yong


Chee Yong Teh
27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138 OTC Infrastructure
Service of the Year & ​Global Compression Service of the Year
-Original Message-
From: Andi Vajda 
Sent: 06 May 2020 00:34
To: Chee Yong Teh 
Cc: pylucene-dev@lucene.apache.org
Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'


On May 5, 2020, at 16:17, Chee Yong Teh  
wrote:



Hi Andi,

Ok I have changed the command to

python -m jcc --version 7.1.4 --use_full_names --include 
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/smart-swapclear-public-release_daru.12.

jar --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/colt-1.2.0.jar --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/commons-math3-3.6.1.jar
--include /home/cheeyong .teh/SMART-API-7.1.4/smart/lib/jna-5.2.0.jar
--include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/log4j-1.2.16.jar
--include /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/proto
buf-java-3.5.1.jar --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-api-1.6.1.jar
--include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-log4j12-1.6.1.jar
--py thon lch_smart --build --install
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory

I'm using --include instead of --jar and pass in
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory as a
class I want to wrap. It seem fine and everything build fine but when
I do a print(dir(lch_smart)). It doesn't seem to wrap that
SMARTClientDataProviderFactory class


print(dir(lch_smart))

['CLASSPATH', 'ConstVariableDescriptor', 'FinalizerClass',
'FinalizerProxy', 'InvalidArgsError', 'JArray', 'JArray_bool',
'JArray_byte', 'JArray_char', 'JArray_double', 'JArray_float',
'JArray_int', 'JArray_long', 'JArray_object', 'JArray_short',
'JArray_string', 'JCCEnv', 'JCC_VERSION', 'JObject', 'JavaError',
'PrintWriter', 'StringWriter', 'VERSION', '__builtins__',
'__cached__', '__doc__', '__file__', '__loader__', '__module_dir__',
'__name__', '__package__', '__path__', '__spec__', '_lch_smart',
'findClass', 'getVMEnv', 'initVM', 'makeClass', 'makeInterface',
'os']




You're using --use_full_names, thus to access the wrapper for
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory
you need to say:
>>> from com.lchclearnet.swapclear.smart import
SMARTClientDataProviderFactory

Andi..



If I use --jar option I will still get the "AttributeError: 'bool' object 
has no attribute 'setdefault'" error.


Thanks,

Chee Yong

Chee Yong Teh​
27 Bush Lane, London, EC4R 0AN   |   +44 203 929 3138

OTC Infrastructure 

RE: AttributeError: 'bool' object has no attribute 'setdefault'

[Andi Vajda]

On Wed, 13 May 2020, Chee Yong Teh wrote:


Thanks for your help and I got everything build and working now.


Great ! (thanks for letting me know)

I have another question about pip install. I know JCC has option of bdist 
which will produce an egg file. However, pip install is not able to 
install an egg file. I know I can use easy install but I just wondering 
what is the steps to make a sdist or something that pip install can use 
from JCC command as I seen in the help of the command it mentions pip 
install (--egg-info and --extra-setup-arg)


I know very little about pip myself, I did not implement or test these 
features in JCC, they were contributed as patches by users in the past.

Patches to better support 'pip install' are welcome !

Andi..



Thanks,

Chee Yong


Chee Yong Teh
27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138
OTC Infrastructure Service of the Year & ​Global Compression Service of the Year
-Original Message-
From: Andi Vajda 
Sent: 07 May 2020 17:01
To: pylucene-dev@lucene.apache.org
Subject: RE: AttributeError: 'bool' object has no attribute 'setdefault'


On Thu, 7 May 2020, Chee Yong Teh wrote:


Hi Andi,

I think I got it working but there is an issue with the class name with '.'.

In the jar there are some class name like below

public static final class SensitivityProfileIdList.Builder public
static final class SRMBreakdown.Builder


Yes, these are so-called inner classes.


So JCC will wrap this can change the '.' to '$'


Which Java exposes to JCC with a '$' in place of the '.' in the name.


SensitivityProfileIdList$Builder
SRMBreakdown$Builder

I cannot really use this classes in python and python flag it up as
syntax error. Would it be better to use '_' instead of '$' to replace
the '.' in the class name?


That's definitely an option. Doing this automatically may then cause a clash 
with a class that uses _ already. There is a --rename flag that lets you 
control the name to pick:

  --rename 
'full.package.path.here.SensitivityProfileIdList$Builder=SensitivityProfileIdList_Builder'

(you need '' around a string with literal $ in a shell command line)

Andi..



Thanks,

Chee Yong


Chee Yong Teh
27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138 OTC Infrastructure
Service of the Year & ​Global Compression Service of the Year
-Original Message-
From: Andi Vajda 
Sent: 06 May 2020 00:34
To: Chee Yong Teh 
Cc: pylucene-dev@lucene.apache.org
Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'



On May 5, 2020, at 16:17, Chee Yong Teh  wrote:


Hi Andi,

Ok I have changed the command to

python -m jcc --version 7.1.4 --use_full_names --include 
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/smart-swapclear-public-release_daru.12.
jar --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/colt-1.2.0.jar --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/commons-math3-3.6.1.jar
--include /home/cheeyong .teh/SMART-API-7.1.4/smart/lib/jna-5.2.0.jar
--include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/log4j-1.2.16.jar
--include /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/proto
buf-java-3.5.1.jar --include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-api-1.6.1.jar
--include
/home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-log4j12-1.6.1.jar
--py thon lch_smart --build --install
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory

I'm using --include instead of --jar and pass in
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory as a
class I want to wrap. It seem fine and everything build fine but when
I do a print(dir(lch_smart)). It doesn't seem to wrap that
SMARTClientDataProviderFactory class


print(dir(lch_smart))

['CLASSPATH', 'ConstVariableDescriptor', 'FinalizerClass',
'FinalizerProxy', 'InvalidArgsError', 'JArray', 'JArray_bool',
'JArray_byte', 'JArray_char', 'JArray_double', 'JArray_float',
'JArray_int', 'JArray_long', 'JArray_object', 'JArray_short',
'JArray_string', 'JCCEnv', 'JCC_VERSION', 'JObject', 'JavaError',
'PrintWriter', 'StringWriter', 'VERSION', '__builtins__',
'__cached__', '__doc__', '__file__', '__loader__', '__module_dir__',
'__name__', '__package__', '__path__', '__spec__', '_lch_smart',
'findClass', 'getVMEnv', 'initVM', 'makeClass', 'makeInterface',
'os']




You're using --use_full_names, thus to access the wrapper for
com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory
you need to say:
>>> from com.lchclearnet.swapclear.smart import
SMARTClientDataProviderFactory

Andi..



If I use --jar option I will still get the "AttributeError: 'bool' object has no 
attribute 'setdefault'" error.

Thanks,

Chee Yong

Chee Yong Teh​
27 Bush Lane, London, EC4R 0AN   |   +44 203 929 3138

OTC Infrastructure Service of the Year & ​Global Compression Service
of the Year -Original Message-
From: Andi Vajda 
Sent: 05 May 2020 23:30
To: Chee Yong Teh 
Cc: pylucene-dev@lucene.apache.org
Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'


On 

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Lucky Sharma]

++1

Regards,
Lucky Sharma

On Wed, 13 May 2020 at 8:01 PM, Mark Harwood  wrote:

> +1
>
> On 2020/05/12 07:36:57, Dawid Weiss  wrote:
> > Dear Lucene and Solr developers!
> >
> > According to an earlier [DISCUSS] thread on the dev list [2], I am
> > calling for a vote on the proposal to make Solr a top-level Apache
> > project (TLP) and separate Lucene and Solr development into two
> > independent entities.
> >
> > To quickly recap the reasons and consequences of such a move: it seems
> > like the reasons for the initial merge of Lucene and Solr, around 10
> > years ago, have been achieved. Both projects are in good shape and
> > exhibit signs of independence already (mailing lists, committers,
> > patch flow). There are many technical considerations that would make
> > development much easier if we move Solr out into its own TLP.
> >
> > We discussed this issue [2] and both PMC members and committers had a
> > chance to review all the pros and cons and express their views. The
> > discussion showed that there are clearly different opinions on the
> > matter - some people are in favor, some are neutral, others are
> > against or not seeing the point of additional labor. Realistically, I
> > don't think reaching 100% level consensus is going to be possible --
> > we are a diverse bunch with different opinions and personalities. I
> > firmly believe this is the right direction hence the decision to put
> > it under the voting process. Should something take a wrong turn in the
> > future (as some folks worry it may), all blame is on me.
> >
> > Therefore, the proposal is to separate Solr from under Lucene TLP, and
> > make it a TLP on its own. The initial structure of the new PMC,
> > committer base, git repositories and other managerial aspects can be
> > worked out during the process if the decision passes.
> >
> > Please indicate one of the following (see [1] for guidelines):
> >
> > [ ] +1 - yes, I vote for the proposal
> > [ ] -1 - no, I vote against the proposal
> >
> > Please note that anyone in the Lucene+Solr community is invited to
> > express their opinion, though only Lucene+Solr committers cast binding
> > votes (indicate non-binding votes in your reply, please).
> >
> > The vote will be active for a week to give everyone a chance to read
> > and cast a vote.
> >
> > Dawid
> >
> > [1] https://www.apache.org/foundation/voting.html
> > [2]
> https://lists.apache.org/thread.html/rfae2440264f6f874e91545b2030c98e7b7e3854ddf090f7747d338df%40%3Cdev.lucene.apache.org%3E
> >
> > -
> > 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
>
> --
Warm Regards,

Lucky Sharma
Contact No :+91 9821559918

Re: pre-commit failing

[Erick Erickson]

Joel:

'git clean -dxf’ is your friend ;). Beware if you’re adding new files, ‘cause 
that removes everything that’s not already in git. It won’t touch anything 
you’ve added locally even if it’s not part of the remote repo.

Sometimes I’ve also gotten weird stuff that’s cured with “gradlew —stop” if 
you’ve used Gradle…

Erick

> On May 13, 2020, at 2:33 PM, Joel Bernstein  wrote:
> 
> A fresh clone doesn't produce this error so it looks like it is specific to 
> my local repo.
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/
> 
> 
> On Wed, May 13, 2020 at 2:17 PM Joel Bernstein  wrote:
> Is anybody seeing the following error on pre-commit:
> JAR resource does not exist: core/lib/commons-beanutils-1.9.3.jar
> 
> Thanks,
> Joel
> 


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

Re: pre-commit failing

[Joel Bernstein]

A fresh clone doesn't produce this error so it looks like it is specific to
my local repo.

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


On Wed, May 13, 2020 at 2:17 PM Joel Bernstein  wrote:

> Is anybody seeing the following error on pre-commit:
>
> JAR resource does not exist: core/lib/commons-beanutils-1.9.3.jar
>
>
> Thanks,
>
> Joel
>
>

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Jason Gerlowski]

> Would this not be eased to some extent if the initial committer base of both 
> the projects was the same?

"Who has commit karma to a project" is a separate question from "Who
will make commits in practice".  Having Lucene committers retain their
status as Solr committers only helps if they're willing and interested
in keeping Solr up to date.  From discussion on this thread so far,
I'm not sure how much of that interest exists.  After all, avoiding
this solr-update-burden was one of the arguments cited in favor of a
split.

> Contrary to Jason I don't think keeping Solr and Lucene code together helps 
> anybody in tackling those issues now or in the future.
That's not the point I was making.  I wasn't saying that the split (or
lack thereof) affects our ability to address test-flakiness (etc.).  I
was citing test-flakiness as an example of how bad us Solr folks have
been historically at prioritizing this sort of work that's crucial for
project health but not tied to a specific feature.  I brought this
historical example up as a parallel or a prediction to how we might do
with a similar task: managing to stay up to date on Lucene.  My whole
point was: "We historically don't do well at getting this sort of work
done; therefore I expect we're going to have some level of lag behind
Lucene"

On Wed, May 13, 2020 at 2:11 PM Dawid Weiss  wrote:
>
> > This might sound a bit harsh, but maybe Lucene devs helping with Solr has 
> > let Solr off the hook a bit too much? I actually like the fact that the 
> > split causes Solr to figure out it's own situation and focus on its 
> > problems.
>
> Well said.
>
> > Take our ongoing test flakiness woes and SolrCloud instability issues as 
> > examples: both are serious threats to the project, both have been around 
> > for years, and both are here to stay for the foreseeable future.
>
> Contrary to Jason I don't think keeping Solr and Lucene code together
> helps anybody in tackling those issues now or in the future. The first
> thing Mark (Miller) did when he started cleaning up the codebase for
> gradle was to *disable* nearly all randomizations and fix certain
> parameters to bring back stability and speed up Solr tests. I bet it would be
> a tad easier if he only had Solr (or Lucene) side to take care of (rather than
> both Lucene AND Solr).
>
> What is good for Lucene may not be as good for Solr. Maybe removing
> randomizations that
> currently happen in LuceneTestCase will calm down tests? Who knows. 
> Sincerely, I
> think a split project may bring a clean slate for more drastic
> refactorings and cleanups. A combined
> codebase keeps the status quo we've been in for years.
>
> 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

pre-commit failing

[Joel Bernstein]

Is anybody seeing the following error on pre-commit:

JAR resource does not exist: core/lib/commons-beanutils-1.9.3.jar


Thanks,

Joel

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Dawid Weiss]

> This might sound a bit harsh, but maybe Lucene devs helping with Solr has let 
> Solr off the hook a bit too much? I actually like the fact that the split 
> causes Solr to figure out it's own situation and focus on its problems.

Well said.

> Take our ongoing test flakiness woes and SolrCloud instability issues as 
> examples: both are serious threats to the project, both have been around for 
> years, and both are here to stay for the foreseeable future.

Contrary to Jason I don't think keeping Solr and Lucene code together
helps anybody in tackling those issues now or in the future. The first
thing Mark (Miller) did when he started cleaning up the codebase for
gradle was to *disable* nearly all randomizations and fix certain
parameters to bring back stability and speed up Solr tests. I bet it would be
a tad easier if he only had Solr (or Lucene) side to take care of (rather than
both Lucene AND Solr).

What is good for Lucene may not be as good for Solr. Maybe removing
randomizations that
currently happen in LuceneTestCase will calm down tests? Who knows. Sincerely, I
think a split project may bring a clean slate for more drastic
refactorings and cleanups. A combined
codebase keeps the status quo we've been in for years.

Dawid

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

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Dawid Weiss]

> Would this not be eased to some extent if the initial committer base
> of both the projects was the same?

This is what I originally suggested; somebody (can't remember who) said
it should be voluntary. I'm really open to either option.

D.

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

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Atri Sharma]

Would this not be eased to some extent if the initial committer base
of both the projects was the same?

On Wed, May 13, 2020 at 10:44 PM Jason Gerlowski  wrote:
>
> There's nothing wrong with a harsh "sink or swim" approach if the
> risks are bearable.  If the worst case risk here is that we have a few
> rough releases as we smooth out the process, I'm all on board with
> "sink or swim".  But by the same token - "sink or swim" gets less
> appealing as the risks increase.   No sane person would toss their PFD
> after a shipwreck because they always meant to learn to backstroke.
> So maybe we just disagree on what the worst case harm to Solr looks
> like.  I see the harm being pretty serious: if Solr stagnates its
> Lucene version relative to other offerings users could go elsewhere
> and the project would lose out on adoption and community.  A Very Bad
> Thing.  But if you don't see this as even a remote possibility, well
> then "sink or swim" makes sense.
>
> > I'd be OK with a stable, robust Solr that got 1-2 major versions behind 
> > Lucene, but was rock-solid with a lower barrier to entry...
>
> If that's an option, I might be too.  But I'm not sure how a
> Lucene-Solr split (or an older Lucene version) does anything to make
> Solr more solid, lower its barrier to entry, etc.  Anecdotally, Solr
> bugs rooted in Lucene seem the minority by far.  And Solr committers
> can put effort into stability/barrier-to-entry as easily now as they
> can in a post-split world.  Is there some connection between the split
> and the those -ilities that I'm missing?
>
> > I choose to be more optimistic wrt «Solr committers» ability to integrate 
> > new and changed Lucene APIs in Solr
> I agree that Solr committers _can_ do this work, and that there are
> some awesome committers who straddle the fence and know Lucene very
> well.  I wasn't trying to impugn anyone's efforts, interest or
> expertise.  My point was just that at the end of the day a split
> leaves fewer people around Solr with knowledge of the Lucene APIs and
> their perf implications.  And a split is going to burden those
> remaining people heavily until the roster of Lucene-literate Solr
> committers re-populates.
>
> On Wed, May 13, 2020 at 10:29 AM Jan Høydahl  wrote:
> >
> > I choose to be more optimistic wrt «Solr committers» ability to integrate 
> > new and changed Lucene APIs in Solr. You do not need to be a Lucene 
> > committer in order to learn how to USE the Lucene APIs, and I believe there 
> > are several «Solr committers» who already posess those skills and are 
> > pretty deep in Lucene already. Hopefully they are interested in doing 
> > lucene upgrades for Solr, even if that some times includes implementing 
> > support for a new fieldType (points vs trie), getting rid of 
> > index-time-boost features etc. I may even attempt some of those tasks 
> > myself for the areas of Lucene API I am comfortable with.
> >
> > Jan
> >
> > 13. mai 2020 kl. 16:24 skrev Doug Turnbull 
> > :
> >
> > Jason, I hear your arguments and think of them FOR a split
> >
> > This might sound a bit harsh, but maybe Lucene devs helping with Solr has 
> > let Solr off the hook a bit too much? I actually like the fact that the 
> > split causes Solr to figure out it's own situation and focus on its 
> > problems.
> >
> > Regardless of the split or not, Solr is going to sink or swim based on the 
> > efforts of Solr committers, not Lucene committers. I don't think Lucene 
> > committers are going to be the ones to really address the systemic issues 
> > with Solr. If anything, I imagine they are "let me fix this so the code 
> > compiles" level of maintenance.
> >
> > "Falling behind Lucene" is counterbalanced to me with "Should Solr be on 
> > cutting-edge Lucene?"
> >
> > I'd be OK with a stable, robust Solr that got 1-2 major versions behind 
> > Lucene, but was rock-solid with a lower barrier to entry...
> >
> > On Wed, May 13, 2020 at 10:07 AM Jason Gerlowski  
> > wrote:
> >>
> >> Wanted to add my two cents to the mix, though I'm a little late as the
> >> vote has already progressed pretty far.
> >>
> >> I'm against a split.  From the points raised, I agree that Lucene has
> >> much to gain.  But Solr has a lot to lose.
> >>
> >> Lucene devs would be freed from keeping Solr usage up to date.  That's
> >> a great improvement for Lucene itself.  But that burden doesn't
> >> disappear - it's just being moved to a different (smaller) group of
> >> committers - who by definition don't know Lucene as well, and are less
> >> suited to the task.  (Lucene devs still might help post-split, but
> >> given that avoiding this burden is one of the arguments made above for
> >> a split, it seems unwise to assume how much this generosity will
> >> continue.)
> >>
> >> One likely result is that Solr will fall behind Lucene. Possibly
> >> permanently behind.  Lucene folks are doing great work to improve
> >> perf, add features etc. so falling behind is a Very Bad Thing.  To
> >> 

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Jason Gerlowski]

There's nothing wrong with a harsh "sink or swim" approach if the
risks are bearable.  If the worst case risk here is that we have a few
rough releases as we smooth out the process, I'm all on board with
"sink or swim".  But by the same token - "sink or swim" gets less
appealing as the risks increase.   No sane person would toss their PFD
after a shipwreck because they always meant to learn to backstroke.
So maybe we just disagree on what the worst case harm to Solr looks
like.  I see the harm being pretty serious: if Solr stagnates its
Lucene version relative to other offerings users could go elsewhere
and the project would lose out on adoption and community.  A Very Bad
Thing.  But if you don't see this as even a remote possibility, well
then "sink or swim" makes sense.

> I'd be OK with a stable, robust Solr that got 1-2 major versions behind 
> Lucene, but was rock-solid with a lower barrier to entry...

If that's an option, I might be too.  But I'm not sure how a
Lucene-Solr split (or an older Lucene version) does anything to make
Solr more solid, lower its barrier to entry, etc.  Anecdotally, Solr
bugs rooted in Lucene seem the minority by far.  And Solr committers
can put effort into stability/barrier-to-entry as easily now as they
can in a post-split world.  Is there some connection between the split
and the those -ilities that I'm missing?

> I choose to be more optimistic wrt «Solr committers» ability to integrate new 
> and changed Lucene APIs in Solr
I agree that Solr committers _can_ do this work, and that there are
some awesome committers who straddle the fence and know Lucene very
well.  I wasn't trying to impugn anyone's efforts, interest or
expertise.  My point was just that at the end of the day a split
leaves fewer people around Solr with knowledge of the Lucene APIs and
their perf implications.  And a split is going to burden those
remaining people heavily until the roster of Lucene-literate Solr
committers re-populates.

On Wed, May 13, 2020 at 10:29 AM Jan Høydahl  wrote:
>
> I choose to be more optimistic wrt «Solr committers» ability to integrate new 
> and changed Lucene APIs in Solr. You do not need to be a Lucene committer in 
> order to learn how to USE the Lucene APIs, and I believe there are several 
> «Solr committers» who already posess those skills and are pretty deep in 
> Lucene already. Hopefully they are interested in doing lucene upgrades for 
> Solr, even if that some times includes implementing support for a new 
> fieldType (points vs trie), getting rid of index-time-boost features etc. I 
> may even attempt some of those tasks myself for the areas of Lucene API I am 
> comfortable with.
>
> Jan
>
> 13. mai 2020 kl. 16:24 skrev Doug Turnbull 
> :
>
> Jason, I hear your arguments and think of them FOR a split
>
> This might sound a bit harsh, but maybe Lucene devs helping with Solr has let 
> Solr off the hook a bit too much? I actually like the fact that the split 
> causes Solr to figure out it's own situation and focus on its problems.
>
> Regardless of the split or not, Solr is going to sink or swim based on the 
> efforts of Solr committers, not Lucene committers. I don't think Lucene 
> committers are going to be the ones to really address the systemic issues 
> with Solr. If anything, I imagine they are "let me fix this so the code 
> compiles" level of maintenance.
>
> "Falling behind Lucene" is counterbalanced to me with "Should Solr be on 
> cutting-edge Lucene?"
>
> I'd be OK with a stable, robust Solr that got 1-2 major versions behind 
> Lucene, but was rock-solid with a lower barrier to entry...
>
> On Wed, May 13, 2020 at 10:07 AM Jason Gerlowski  
> wrote:
>>
>> Wanted to add my two cents to the mix, though I'm a little late as the
>> vote has already progressed pretty far.
>>
>> I'm against a split.  From the points raised, I agree that Lucene has
>> much to gain.  But Solr has a lot to lose.
>>
>> Lucene devs would be freed from keeping Solr usage up to date.  That's
>> a great improvement for Lucene itself.  But that burden doesn't
>> disappear - it's just being moved to a different (smaller) group of
>> committers - who by definition don't know Lucene as well, and are less
>> suited to the task.  (Lucene devs still might help post-split, but
>> given that avoiding this burden is one of the arguments made above for
>> a split, it seems unwise to assume how much this generosity will
>> continue.)
>>
>> One likely result is that Solr will fall behind Lucene. Possibly
>> permanently behind.  Lucene folks are doing great work to improve
>> perf, add features etc. so falling behind is a Very Bad Thing.  To
>> Solr, Lucene is not the same as Jetty or Jackson which Solr can fall
>> behind on without significant detriment.  Lucene and the core search
>> functionality it offers is what brings people to Solr (or Elastic).
>> Putting ourselves in a position to fall behind on Lucene does a huge
>> disservice to our users, and loses Solr one of its greatest
>> 

RE: AttributeError: 'bool' object has no attribute 'setdefault'

[Chee Yong Teh]

Hi Andi,

Thanks for your help and I got everything build and working now.

I have another question about pip install. I know JCC has option of bdist which 
will produce an egg file. However, pip install is not able to install an egg 
file. I know I can use easy install but I just wondering what is the steps to 
make a sdist or something that pip install can use from JCC command as I seen 
in the help of the command it mentions pip install (--egg-info and 
--extra-setup-arg)

Thanks,

Chee Yong


Chee Yong Teh 
27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138 
OTC Infrastructure Service of the Year & ​Global Compression Service of the Year
-Original Message-
From: Andi Vajda  
Sent: 07 May 2020 17:01
To: pylucene-dev@lucene.apache.org
Subject: RE: AttributeError: 'bool' object has no attribute 'setdefault'


On Thu, 7 May 2020, Chee Yong Teh wrote:

> Hi Andi,
>
> I think I got it working but there is an issue with the class name with '.'.
>
> In the jar there are some class name like below
>
> public static final class SensitivityProfileIdList.Builder public 
> static final class SRMBreakdown.Builder

Yes, these are so-called inner classes.

> So JCC will wrap this can change the '.' to '$'

Which Java exposes to JCC with a '$' in place of the '.' in the name.

> SensitivityProfileIdList$Builder
> SRMBreakdown$Builder
>
> I cannot really use this classes in python and python flag it up as 
> syntax error. Would it be better to use '_' instead of '$' to replace 
> the '.' in the class name?

That's definitely an option. Doing this automatically may then cause a clash 
with a class that uses _ already. There is a --rename flag that lets you 
control the name to pick:

   --rename 
'full.package.path.here.SensitivityProfileIdList$Builder=SensitivityProfileIdList_Builder'

(you need '' around a string with literal $ in a shell command line)

Andi..

>
> Thanks,
>
> Chee Yong
>
>
> Chee Yong Teh
> 27 Bush Lane, London, EC4R 0AN  |  +44 203 929 3138 OTC Infrastructure 
> Service of the Year & ​Global Compression Service of the Year 
> -Original Message-
> From: Andi Vajda 
> Sent: 06 May 2020 00:34
> To: Chee Yong Teh 
> Cc: pylucene-dev@lucene.apache.org
> Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'
>
>
>> On May 5, 2020, at 16:17, Chee Yong Teh  wrote:
>>
>> 
>> Hi Andi,
>>
>> Ok I have changed the command to
>>
>> python -m jcc --version 7.1.4 --use_full_names --include 
>> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/smart-swapclear-public-release_daru.12.
>> jar --include
>> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/colt-1.2.0.jar --include 
>> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/commons-math3-3.6.1.jar
>> --include /home/cheeyong .teh/SMART-API-7.1.4/smart/lib/jna-5.2.0.jar
>> --include
>> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/log4j-1.2.16.jar
>> --include /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/proto
>> buf-java-3.5.1.jar --include
>> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-api-1.6.1.jar
>> --include
>> /home/cheeyong.teh/SMART-API-7.1.4/smart/lib/slf4j-log4j12-1.6.1.jar
>> --py thon lch_smart --build --install 
>> com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory
>>
>> I'm using --include instead of --jar and pass in 
>> com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory as a 
>> class I want to wrap. It seem fine and everything build fine but when 
>> I do a print(dir(lch_smart)). It doesn't seem to wrap that 
>> SMARTClientDataProviderFactory class
>>
> print(dir(lch_smart))
>> ['CLASSPATH', 'ConstVariableDescriptor', 'FinalizerClass', 
>> 'FinalizerProxy', 'InvalidArgsError', 'JArray', 'JArray_bool', 
>> 'JArray_byte', 'JArray_char', 'JArray_double', 'JArray_float', 
>> 'JArray_int', 'JArray_long', 'JArray_object', 'JArray_short', 
>> 'JArray_string', 'JCCEnv', 'JCC_VERSION', 'JObject', 'JavaError', 
>> 'PrintWriter', 'StringWriter', 'VERSION', '__builtins__', 
>> '__cached__', '__doc__', '__file__', '__loader__', '__module_dir__', 
>> '__name__', '__package__', '__path__', '__spec__', '_lch_smart', 
>> 'findClass', 'getVMEnv', 'initVM', 'makeClass', 'makeInterface', 
>> 'os']
>
>
> You're using --use_full_names, thus to access the wrapper for 
> com.lchclearnet.swapclear.smart.SMARTClientDataProviderFactory
> you need to say:
>  >>> from com.lchclearnet.swapclear.smart import 
> SMARTClientDataProviderFactory
>
> Andi..
>
>>
>> If I use --jar option I will still get the "AttributeError: 'bool' object 
>> has no attribute 'setdefault'" error.
>>
>> Thanks,
>>
>> Chee Yong
>>
>> Chee Yong Teh​
>> 27 Bush Lane, London, EC4R 0AN|   +44 203 929 3138
>> 
>> OTC Infrastructure Service of the Year & ​Global Compression Service 
>> of the Year -Original Message-
>> From: Andi Vajda 
>> Sent: 05 May 2020 23:30
>> To: Chee Yong Teh 
>> Cc: pylucene-dev@lucene.apache.org
>> Subject: Re: AttributeError: 'bool' object has no attribute 'setdefault'
>>
>>
>> On Tue, 5 May 2020, 

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Mark Harwood]

+1

On 2020/05/12 07:36:57, Dawid Weiss  wrote: 
> Dear Lucene and Solr developers!
> 
> According to an earlier [DISCUSS] thread on the dev list [2], I am
> calling for a vote on the proposal to make Solr a top-level Apache
> project (TLP) and separate Lucene and Solr development into two
> independent entities.
> 
> To quickly recap the reasons and consequences of such a move: it seems
> like the reasons for the initial merge of Lucene and Solr, around 10
> years ago, have been achieved. Both projects are in good shape and
> exhibit signs of independence already (mailing lists, committers,
> patch flow). There are many technical considerations that would make
> development much easier if we move Solr out into its own TLP.
> 
> We discussed this issue [2] and both PMC members and committers had a
> chance to review all the pros and cons and express their views. The
> discussion showed that there are clearly different opinions on the
> matter - some people are in favor, some are neutral, others are
> against or not seeing the point of additional labor. Realistically, I
> don't think reaching 100% level consensus is going to be possible --
> we are a diverse bunch with different opinions and personalities. I
> firmly believe this is the right direction hence the decision to put
> it under the voting process. Should something take a wrong turn in the
> future (as some folks worry it may), all blame is on me.
> 
> Therefore, the proposal is to separate Solr from under Lucene TLP, and
> make it a TLP on its own. The initial structure of the new PMC,
> committer base, git repositories and other managerial aspects can be
> worked out during the process if the decision passes.
> 
> Please indicate one of the following (see [1] for guidelines):
> 
> [ ] +1 - yes, I vote for the proposal
> [ ] -1 - no, I vote against the proposal
> 
> Please note that anyone in the Lucene+Solr community is invited to
> express their opinion, though only Lucene+Solr committers cast binding
> votes (indicate non-binding votes in your reply, please).
> 
> The vote will be active for a week to give everyone a chance to read
> and cast a vote.
> 
> Dawid
> 
> [1] https://www.apache.org/foundation/voting.html
> [2] 
> https://lists.apache.org/thread.html/rfae2440264f6f874e91545b2030c98e7b7e3854ddf090f7747d338df%40%3Cdev.lucene.apache.org%3E
> 
> -
> 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: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Jan Høydahl]

I choose to be more optimistic wrt «Solr committers» ability to integrate new 
and changed Lucene APIs in Solr. You do not need to be a Lucene committer in 
order to learn how to USE the Lucene APIs, and I believe there are several 
«Solr committers» who already posess those skills and are pretty deep in Lucene 
already. Hopefully they are interested in doing lucene upgrades for Solr, even 
if that some times includes implementing support for a new fieldType (points vs 
trie), getting rid of index-time-boost features etc. I may even attempt some of 
those tasks myself for the areas of Lucene API I am comfortable with.

Jan

> 13. mai 2020 kl. 16:24 skrev Doug Turnbull 
> :
> 
> Jason, I hear your arguments and think of them FOR a split
> 
> This might sound a bit harsh, but maybe Lucene devs helping with Solr has let 
> Solr off the hook a bit too much? I actually like the fact that the split 
> causes Solr to figure out it's own situation and focus on its problems. 
> 
> Regardless of the split or not, Solr is going to sink or swim based on the 
> efforts of Solr committers, not Lucene committers. I don't think Lucene 
> committers are going to be the ones to really address the systemic issues 
> with Solr. If anything, I imagine they are "let me fix this so the code 
> compiles" level of maintenance. 
> 
> "Falling behind Lucene" is counterbalanced to me with "Should Solr be on 
> cutting-edge Lucene?" 
> 
> I'd be OK with a stable, robust Solr that got 1-2 major versions behind 
> Lucene, but was rock-solid with a lower barrier to entry... 
> 
> On Wed, May 13, 2020 at 10:07 AM Jason Gerlowski  > wrote:
> Wanted to add my two cents to the mix, though I'm a little late as the
> vote has already progressed pretty far.
> 
> I'm against a split.  From the points raised, I agree that Lucene has
> much to gain.  But Solr has a lot to lose.
> 
> Lucene devs would be freed from keeping Solr usage up to date.  That's
> a great improvement for Lucene itself.  But that burden doesn't
> disappear - it's just being moved to a different (smaller) group of
> committers - who by definition don't know Lucene as well, and are less
> suited to the task.  (Lucene devs still might help post-split, but
> given that avoiding this burden is one of the arguments made above for
> a split, it seems unwise to assume how much this generosity will
> continue.)
> 
> One likely result is that Solr will fall behind Lucene. Possibly
> permanently behind.  Lucene folks are doing great work to improve
> perf, add features etc. so falling behind is a Very Bad Thing.  To
> Solr, Lucene is not the same as Jetty or Jackson which Solr can fall
> behind on without significant detriment.  Lucene and the core search
> functionality it offers is what brings people to Solr (or Elastic).
> Putting ourselves in a position to fall behind on Lucene does a huge
> disservice to our users, and loses Solr one of its greatest
> advantages.
> 
> I hope that in the case of a split, the Solr community would rise to
> the occasion and prevent this.  But my personal judgement is that it's
> unlikely.  I hate to be negative, and I hope to be proven wrong, but
> that's how things look to me.  We (Solr folks) have a bad track record
> of addressing things with less-tangible, less-sellable benefits.  Take
> our ongoing test flakiness woes and SolrCloud instability issues as
> examples: both are serious threats to the project, both have been
> around for years, and both are here to stay for the foreseeable
> future.
> 
> If conditions were different in a way that made "falling behind" less
> likely, I'd be all for a split.  But given (1) our recent track record
> of addressing these sort of issues, (2) our test flakiness which will
> make identifying "Lucene snapshot upgrade" bugs exceedingly difficult,
> and (3) the current economic conditions which may make it harder for
> committers to negotiate time from their employers to work on Lucene
> updates...now seems like a bad time to attempt a split.  It will harm
> Solr more than it helps Lucene.
> 
> On Tue, May 12, 2020 at 3:37 PM Namgyu Kim  > wrote:
> >
> > It's hard to make a decision because it seems to have pros and cons.
> > Basically, I agree to separate but there are some questions.
> > So I don't not vote right now.
> >
> > 1) Release version
> > Currently, versions of Lucene and Solr are aligned, how will they be 
> > managed in the future?
> > Other people took Elasticsearch as an example... But it was an independent 
> > project from the beginning.
> > So there is no problem with the Lucene version. (Elasticsearch 7.7 and 
> > Lucene 8.5.1)
> > I'm sure if we make solr as an independent project, it will make cracks 
> > about the version structure. (like Lucene 8.6.2 and Solr 8.9.1)
> > But it's also strange to suddenly start a new version of the Solr. (Solr 
> > 1.0)
> > Of course it's a matter of adaption, but it's likely to cause some 
> > 

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Doug Turnbull]

Jason, I hear your arguments and think of them FOR a split

This might sound a bit harsh, but maybe Lucene devs helping with Solr has
let Solr off the hook a bit too much? I actually like the fact that the
split causes Solr to figure out it's own situation and focus on
its problems.

Regardless of the split or not, Solr is going to sink or swim based on the
efforts of Solr committers, not Lucene committers. I don't think Lucene
committers are going to be the ones to really address the systemic issues
with Solr. If anything, I imagine they are "let me fix this so the code
compiles" level of maintenance.

"Falling behind Lucene" is counterbalanced to me with "Should Solr be on
cutting-edge Lucene?"

I'd be OK with a stable, robust Solr that got 1-2 major versions behind
Lucene, but was rock-solid with a lower barrier to entry...

On Wed, May 13, 2020 at 10:07 AM Jason Gerlowski 
wrote:

> Wanted to add my two cents to the mix, though I'm a little late as the
> vote has already progressed pretty far.
>
> I'm against a split.  From the points raised, I agree that Lucene has
> much to gain.  But Solr has a lot to lose.
>
> Lucene devs would be freed from keeping Solr usage up to date.  That's
> a great improvement for Lucene itself.  But that burden doesn't
> disappear - it's just being moved to a different (smaller) group of
> committers - who by definition don't know Lucene as well, and are less
> suited to the task.  (Lucene devs still might help post-split, but
> given that avoiding this burden is one of the arguments made above for
> a split, it seems unwise to assume how much this generosity will
> continue.)
>
> One likely result is that Solr will fall behind Lucene. Possibly
> permanently behind.  Lucene folks are doing great work to improve
> perf, add features etc. so falling behind is a Very Bad Thing.  To
> Solr, Lucene is not the same as Jetty or Jackson which Solr can fall
> behind on without significant detriment.  Lucene and the core search
> functionality it offers is what brings people to Solr (or Elastic).
> Putting ourselves in a position to fall behind on Lucene does a huge
> disservice to our users, and loses Solr one of its greatest
> advantages.
>
> I hope that in the case of a split, the Solr community would rise to
> the occasion and prevent this.  But my personal judgement is that it's
> unlikely.  I hate to be negative, and I hope to be proven wrong, but
> that's how things look to me.  We (Solr folks) have a bad track record
> of addressing things with less-tangible, less-sellable benefits.  Take
> our ongoing test flakiness woes and SolrCloud instability issues as
> examples: both are serious threats to the project, both have been
> around for years, and both are here to stay for the foreseeable
> future.
>
> If conditions were different in a way that made "falling behind" less
> likely, I'd be all for a split.  But given (1) our recent track record
> of addressing these sort of issues, (2) our test flakiness which will
> make identifying "Lucene snapshot upgrade" bugs exceedingly difficult,
> and (3) the current economic conditions which may make it harder for
> committers to negotiate time from their employers to work on Lucene
> updates...now seems like a bad time to attempt a split.  It will harm
> Solr more than it helps Lucene.
>
> On Tue, May 12, 2020 at 3:37 PM Namgyu Kim  wrote:
> >
> > It's hard to make a decision because it seems to have pros and cons.
> > Basically, I agree to separate but there are some questions.
> > So I don't not vote right now.
> >
> > 1) Release version
> > Currently, versions of Lucene and Solr are aligned, how will they be
> managed in the future?
> > Other people took Elasticsearch as an example... But it was an
> independent project from the beginning.
> > So there is no problem with the Lucene version. (Elasticsearch 7.7 and
> Lucene 8.5.1)
> > I'm sure if we make solr as an independent project, it will make cracks
> about the version structure. (like Lucene 8.6.2 and Solr 8.9.1)
> > But it's also strange to suddenly start a new version of the Solr. (Solr
> 1.0)
> > Of course it's a matter of adaption, but it's likely to cause some
> confusion for existing users.
> >
> > 2) Complementary relationship
> > When Lucene and Solr are built together, Solr can always maintain the
> latest Lucene.
> > In my personal opinion, it's a great advantage of Solr.
> > Because Solr doesn't have to suffer from Lucene API changes and has
> latest library.
> > But it will be difficult if Solr becomes independent.
> > If Solr tracks the master branch of Lucene on separate
> repository(project), can it always check and reflect Lucene's API changes?
> >
> > On Tue, May 12, 2020 at 10:12 PM Doug Turnbull <
> dturnb...@opensourceconnections.com> wrote:
> >>
> >> I'll give a perspective that comes more from the user's / "market"
> point of view as at OSC we onboard lots of new organizations into Solr.
> >>
> >> - Most new users incorrectly think of Solr as an 

Re: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Jason Gerlowski]

Wanted to add my two cents to the mix, though I'm a little late as the
vote has already progressed pretty far.

I'm against a split.  From the points raised, I agree that Lucene has
much to gain.  But Solr has a lot to lose.

Lucene devs would be freed from keeping Solr usage up to date.  That's
a great improvement for Lucene itself.  But that burden doesn't
disappear - it's just being moved to a different (smaller) group of
committers - who by definition don't know Lucene as well, and are less
suited to the task.  (Lucene devs still might help post-split, but
given that avoiding this burden is one of the arguments made above for
a split, it seems unwise to assume how much this generosity will
continue.)

One likely result is that Solr will fall behind Lucene. Possibly
permanently behind.  Lucene folks are doing great work to improve
perf, add features etc. so falling behind is a Very Bad Thing.  To
Solr, Lucene is not the same as Jetty or Jackson which Solr can fall
behind on without significant detriment.  Lucene and the core search
functionality it offers is what brings people to Solr (or Elastic).
Putting ourselves in a position to fall behind on Lucene does a huge
disservice to our users, and loses Solr one of its greatest
advantages.

I hope that in the case of a split, the Solr community would rise to
the occasion and prevent this.  But my personal judgement is that it's
unlikely.  I hate to be negative, and I hope to be proven wrong, but
that's how things look to me.  We (Solr folks) have a bad track record
of addressing things with less-tangible, less-sellable benefits.  Take
our ongoing test flakiness woes and SolrCloud instability issues as
examples: both are serious threats to the project, both have been
around for years, and both are here to stay for the foreseeable
future.

If conditions were different in a way that made "falling behind" less
likely, I'd be all for a split.  But given (1) our recent track record
of addressing these sort of issues, (2) our test flakiness which will
make identifying "Lucene snapshot upgrade" bugs exceedingly difficult,
and (3) the current economic conditions which may make it harder for
committers to negotiate time from their employers to work on Lucene
updates...now seems like a bad time to attempt a split.  It will harm
Solr more than it helps Lucene.

On Tue, May 12, 2020 at 3:37 PM Namgyu Kim  wrote:
>
> It's hard to make a decision because it seems to have pros and cons.
> Basically, I agree to separate but there are some questions.
> So I don't not vote right now.
>
> 1) Release version
> Currently, versions of Lucene and Solr are aligned, how will they be managed 
> in the future?
> Other people took Elasticsearch as an example... But it was an independent 
> project from the beginning.
> So there is no problem with the Lucene version. (Elasticsearch 7.7 and Lucene 
> 8.5.1)
> I'm sure if we make solr as an independent project, it will make cracks about 
> the version structure. (like Lucene 8.6.2 and Solr 8.9.1)
> But it's also strange to suddenly start a new version of the Solr. (Solr 1.0)
> Of course it's a matter of adaption, but it's likely to cause some confusion 
> for existing users.
>
> 2) Complementary relationship
> When Lucene and Solr are built together, Solr can always maintain the latest 
> Lucene.
> In my personal opinion, it's a great advantage of Solr.
> Because Solr doesn't have to suffer from Lucene API changes and has latest 
> library.
> But it will be difficult if Solr becomes independent.
> If Solr tracks the master branch of Lucene on separate repository(project), 
> can it always check and reflect Lucene's API changes?
>
> On Tue, May 12, 2020 at 10:12 PM Doug Turnbull 
>  wrote:
>>
>> I'll give a perspective that comes more from the user's / "market" point of 
>> view as at OSC we onboard lots of new organizations into Solr.
>>
>> - Most new users incorrectly think of Solr as an independent Apache project, 
>> and many will have little knowledge or awareness of Lucene itself until 
>> given the full history of Lucene, Solr, Elasticsearch... or they have to 
>> dive into the code/write a plugin
>>
>> - Most orgs / managers think in terms of "Solr" (as in "Solr" vs 
>> "Elasticsearch" vs "Vespa, etc). So the starting point for new devs / folks 
>> is from the Solr angle
>>
>> - Lucene, when discussed, is understood more colloquially as a Solr 
>> dependency
>>
>> - If someone brings down the code to do some kind of work or investigation, 
>> there's typically surprise that Lucene and Solr are bundled together.
>>
>> - There's further surprise as the projects are indeed so different: Lucene 
>> and Solr tests, for example look little alike. They seem to have different 
>> coding syles / practices. One has more server-like and distributed system 
>> concerns; the other is clearly a low-level library for doing search work...
>>
>> I personally have a hard time explaining to new users the rationale for 
>> keeping these together, 

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Gus Heck]

(having not read all replies, just the message I added binding... later
replies indicate that i should have said

-1 (committer)

On Wed, May 13, 2020 at 7:53 AM Gus Heck  wrote:

> -1 (binding)
>
> On Wed, May 13, 2020 at 6:53 AM Joel Bernstein  wrote:
>
>> -1 (binding)
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>>
>> On Wed, May 13, 2020 at 4:39 AM Tomoko Uchida <
>> tomoko.uchida.1...@gmail.com> wrote:
>>
>>> Personally, I am not particularly interested in "promoting" Solr to TLP
>>> though, agree with the idea Lucene and Solr should have separate code base,
>>> CI infra, contribution procedure, release cycles, etc.
>>> If this proposal is the best way to do so, +1 (non binding).
>>>
>>> Tomoko
>>>
>>>
>>> 2020年5月13日(水) 16:21 Dawid Weiss :
>>>
 > I wanted to clarify that only PMC members cast binding votes and not
 committers.

 I thought it's up to the decision of the one who sends the vote thread
 but I stand corrected, thank you Anshum.

 Dawid

 -
 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)
>


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

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Gus Heck]

-1 (binding)

On Wed, May 13, 2020 at 6:53 AM Joel Bernstein  wrote:

> -1 (binding)
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Wed, May 13, 2020 at 4:39 AM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>> Personally, I am not particularly interested in "promoting" Solr to TLP
>> though, agree with the idea Lucene and Solr should have separate code base,
>> CI infra, contribution procedure, release cycles, etc.
>> If this proposal is the best way to do so, +1 (non binding).
>>
>> Tomoko
>>
>>
>> 2020年5月13日(水) 16:21 Dawid Weiss :
>>
>>> > I wanted to clarify that only PMC members cast binding votes and not
>>> committers.
>>>
>>> I thought it's up to the decision of the one who sends the vote thread
>>> but I stand corrected, thank you Anshum.
>>>
>>> Dawid
>>>
>>> -
>>> 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: [VOTE] Solr to become a top-level Apache project (TLP)

[Joel Bernstein]

-1 (binding)


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


On Wed, May 13, 2020 at 4:39 AM Tomoko Uchida 
wrote:

> Personally, I am not particularly interested in "promoting" Solr to TLP
> though, agree with the idea Lucene and Solr should have separate code base,
> CI infra, contribution procedure, release cycles, etc.
> If this proposal is the best way to do so, +1 (non binding).
>
> Tomoko
>
>
> 2020年5月13日(水) 16:21 Dawid Weiss :
>
>> > I wanted to clarify that only PMC members cast binding votes and not
>> committers.
>>
>> I thought it's up to the decision of the one who sends the vote thread
>> but I stand corrected, thank you Anshum.
>>
>> Dawid
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Tomoko Uchida]

Personally, I am not particularly interested in "promoting" Solr to TLP
though, agree with the idea Lucene and Solr should have separate code base,
CI infra, contribution procedure, release cycles, etc.
If this proposal is the best way to do so, +1 (non binding).

Tomoko


2020年5月13日(水) 16:21 Dawid Weiss :

> > I wanted to clarify that only PMC members cast binding votes and not
> committers.
>
> I thought it's up to the decision of the one who sends the vote thread
> but I stand corrected, thank you Anshum.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Dawid Weiss]

> I wanted to clarify that only PMC members cast binding votes and not 
> committers.

I thought it's up to the decision of the one who sends the vote thread
but I stand corrected, thank you Anshum.

Dawid

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

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Adrien Grand]

+1

On Tue, May 12, 2020 at 9:37 AM Dawid Weiss  wrote:

> Dear Lucene and Solr developers!
>
> According to an earlier [DISCUSS] thread on the dev list [2], I am
> calling for a vote on the proposal to make Solr a top-level Apache
> project (TLP) and separate Lucene and Solr development into two
> independent entities.
>
> To quickly recap the reasons and consequences of such a move: it seems
> like the reasons for the initial merge of Lucene and Solr, around 10
> years ago, have been achieved. Both projects are in good shape and
> exhibit signs of independence already (mailing lists, committers,
> patch flow). There are many technical considerations that would make
> development much easier if we move Solr out into its own TLP.
>
> We discussed this issue [2] and both PMC members and committers had a
> chance to review all the pros and cons and express their views. The
> discussion showed that there are clearly different opinions on the
> matter - some people are in favor, some are neutral, others are
> against or not seeing the point of additional labor. Realistically, I
> don't think reaching 100% level consensus is going to be possible --
> we are a diverse bunch with different opinions and personalities. I
> firmly believe this is the right direction hence the decision to put
> it under the voting process. Should something take a wrong turn in the
> future (as some folks worry it may), all blame is on me.
>
> Therefore, the proposal is to separate Solr from under Lucene TLP, and
> make it a TLP on its own. The initial structure of the new PMC,
> committer base, git repositories and other managerial aspects can be
> worked out during the process if the decision passes.
>
> Please indicate one of the following (see [1] for guidelines):
>
> [ ] +1 - yes, I vote for the proposal
> [ ] -1 - no, I vote against the proposal
>
> Please note that anyone in the Lucene+Solr community is invited to
> express their opinion, though only Lucene+Solr committers cast binding
> votes (indicate non-binding votes in your reply, please).
>
> The vote will be active for a week to give everyone a chance to read
> and cast a vote.
>
> Dawid
>
> [1] https://www.apache.org/foundation/voting.html
> [2]
> https://lists.apache.org/thread.html/rfae2440264f6f874e91545b2030c98e7b7e3854ddf090f7747d338df%40%3Cdev.lucene.apache.org%3E
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Adrien