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

[Jie Kang]

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

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

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

-- 

Jie Kang

OpenJDK Team - Software Engineering Intern