[rfc][icedtea-web] fixing CacheReproducerTest and improving VersionedJarTest

[Jiri Vanek]

On 03/19/2015 09:32 PM, Jie Kang wrote:
>
>
> ----- Original Message -----
>> On 03/04/2015 06:13 PM, Jiri Vanek wrote:
>>>>>
>>>>> Well please fix this as soon as possible.
>>>>>
>>>>
>>>> sure. Probably today.
>>>>
>>>>> Please make sure to get both use-cases below:
>>>>>
>>>>> 1) user changes cachedir to custom location using itweb-settings : this
>>>>> is broken with your patch (bug in PathsAndFiles?)
>>>>
>>>> Sure!
>>>
>>> Hmm. Looking to it now, it stopepd to gave sense to me.
>>>
>>> The cahe si already selectable via XDG variables. Why to make it more
>>> complicated by completly custom value?
>>>
>>> Same is valid for logging.
>>>
>>> Is the chengable target of those two really desirable?
>>
>>
>> ping??
>>
>> I really am for dropping support of dual-setup-able cache and config. However
>> it is definitely not something minor.
>
> Hello.
>
> I'm not sure what to say to continue this discussion :\ I think that the ability for users to set a custom location for their cache is useful and good to have.

for what? You can set it ia xdg variables. Its standartized behaviour.

 > Prior to this patch we had this feature, but now it's not working so I think a fix would be nice. 
What's wrong with allowing users to choose custom locations? We had this feature before already, I 
am just asking for a fix that makes it work again.
> Otherwise, if you want to to remove this feature, a patch that removes it all would be nice. Just leaving it broken is the main issue for me.

Sure. I will fix it or remove it. this+localizations is main blocker for release. Also Lukas's fix 
for attributes is awaited.
>
>>
>> The resurrection of setupable paths may be tricky, but should be doable. Stil
>> it do not gave sense for me....
>
> CacheUtil tests will test the caching system and will deal with the cache on the filesystem. I think it makes sense to use a temporary cache location to do this.
> ResourceTracker/ResourceDownloader/PluginBridge/other tests that touch resources in the cache will deal with the cache on the filesystem. I think it also makes sense to use a temporary cache location to do this.
>
> The main reason for setupable paths is for these tests.


yes. But those test can now use fake instance of the singleton, or not?
>
> Thoughts? I am open to alternatives;
>
>
> Regards,
>
>>>
>>> J.
>>>>
>>>>>
>>>>> 2) for unit tests : we need to be able to set cache to a temporary
>>>>> location : CacheUtil unit tests need to test caching functions
>>>>> (clearCache, etc.), but not in user's cache.
>>>>
>>>> I thought you were working on this? I guess I made this a bit more
>>>> complicated now...
>>>>
>>>> I'm not sure if this feature is desirable, however Most easy solution will
>>>> be to create false CacheLruWrapper, or not? (Now I guess You know why it
>>>> s probably better to not copy its value into static field...)
>>>> J.
>>>
>>
>>
>