On 27/03/2012, at 11:40 PM, Philip Crotwell wrote:
> Would it be more acceptable to do something like:
>
> } catch (java.io.InvalidClassException e) {
> remove(key);
> throw e;
>
> so that the exception still continues up the stack, but at least the
> second time you run it the offending item is removed? Is there any
> good reason to keep something in the cache once you know it is not
> compatible?
It depends what the cache file is being used for. For task history, it probably
does not make any sense to keep the entry. In this case, the catch block would
have to live up in CacheBackedTaskHistoryRepository. However, it would have to
deal with all the other cases that the cached entry can be broken: the class
has been renamed, is no longer serialisable, used to implement readResolve()
but no longer does, implements Externalizable and has changed its serialisation
scheme, etc.
I think it would be much more reliable to simply invalidate the task history
when the implementation class path of the task changes, to preempt these
problems (and more).
>
> Or is there any work around you can think of that is less of a
> sledgehammer than "-C rebuild" where one bad item means redownloading
> the entire dependency cache?
You can use the new --rerun-tasks command-line option, or the old --no-opt
command-line option.
>
> I will look forward to rc1.
>
> thanks
> Philip
>
> On Mon, Mar 26, 2012 at 6:37 PM, Adam Murdoch
> <[email protected]> wrote:
>>
>> On 27/03/2012, at 12:38 AM, Philip Crotwell wrote:
>>
>> Hi
>>
>> I have a patch for GRADLE-2084 where serialization exceptions cause
>> gradle to crash rather than simply failing the out of date check.
>>
>>
>> I don't think this is the correct solution for this issue. That code is used
>> for a number of different things, not just for task up-to-date checks. There
>> are many ways an IncompatibleClassChange can happen here, and for almost all
>> of them, we don't want to ignore the exception.
>>
>> Instead, I think we want to do
>> this: http://issues.gradle.org/browse/GRADLE-1910. This will catch the
>> incompatible changes to persistent classes, plus a whole bunch of other
>> problems. A fix is scheduled for 1.0-rc-1.
>>
>>
>> --
>> Adam Murdoch
>> Gradle Co-founder
>> http://www.gradle.org
>> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
>> http://www.gradleware.com
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
