Re: Bundled/shaded JARs

On 03/02/2020 08:45, Adam Burke wrote:
> In other codebases I have seen this done reactively as a “poor man’s 
> dependency conflict resolution”. ie introduce renaming only where 
> there are conflicts in transitive dependencies, allowing the use of 
> two different versions of classes with the same full name.
>
> I don’t know the specific history in Jython, though.

Here from the beginning: 
https://hg.python.org/jython/rev/107fe4a4c96b#l28.7, hence pinging Jim. 
Unfortunately, it didn't occur to me it might be the wrong thing to 
leave it so until after I cut a beta 3 (unpublished so far).

Now wondering if a beta 4 might be necessary as it seems the sort of 
change that would need it, in case unshading produces the sort of 
conflict you're talking about.  :(

Jeff

>
> Cheers
> Adam
>
>> 在 2020年2月3日，下午6:36，Jeff Allen <[email protected]> 写道：
>>
>> 
>>
>> When we install Jython we have bundled the contents of the JARs we 
>> depend on into ~/jython.jar . Some we name-translate:
>>
>>     org/python/apache/commons/compress
>>     org/python/bouncycastle
>>
>> And some we just copy:
>>
>>     com/ziclix/python/sql
>>     jnr/ffi
>>
>> What drives one choice or the other?
>>
>> Testing after installation, I get a test failure from test_ssl 
>> (Unable to create OpenSSL PBDKF: PBKDF-OpenSSL SecretKeyFactory not 
>> available), where I suspect the shading is the cause. Quite likely, 
>> something is loaded by its unshaded class name, since if I place 
>> unshaded BC JARs on the path the test passes.
>>
>> We seem to have gone to some lengths in _sslcerts.py, for example, to 
>> use the shaded classes, but must we shade it?
>>
>> Jeff
>>
>> -- 
>> Jeff Allen
>> _______________________________________________
>> Jython-dev mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jython-dev

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev