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?
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?
I will look forward to rc1.
thanks
Philip
On Mon, Mar 26, 2012 at 6:37 PM, Adam Murdoch
<adam.murd...@gradleware.com> 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
