Best strategy for changed XML serialization of Publisher classes

[Ulli Hafner-2]

Hi,

while extending the findbugs plugin I realized, that the old serialized
results in the build folder (build.xml) might be not compatible anymore
with a new plugin version. (The deserializing code actually throws an
exception...)

What is the best strategy here? Discarding old builds is the easiest way
for a plugin developer - providing conversion code the best way for
plugin users. I'm not sure whether it's worth the effort to keep the
findbugs plugin 1.x compatible to build format 1.y (y < x). I would
rather provide new features instead of keeping old versions compatible.

Is there a way to ignore not compatible XML parts in the build.xml
folder. E.g., using a version number, so that a plugin could decide
whether it could serialize or not?

Ulli
--
Avaloq - essential for banking.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kohsuke Kawaguchi]

Hafner Ullrich wrote:

> while extending the findbugs plugin I realized, that the old serialized
> results in the build folder (build.xml) might be not compatible anymore
> with a new plugin version. (The deserializing code actually throws an
> exception...)
>
> What is the best strategy here? Discarding old builds is the easiest way
> for a plugin developer - providing conversion code the best way for
> plugin users. I'm not sure whether it's worth the effort to keep the
> findbugs plugin 1.x compatible to build format 1.y (y < x). I would
> rather provide new features instead of keeping old versions compatible.

I believe if action fails to deserialize, that portion will just get
ignored and the build record itself will be loaded successfully --- IOW,
the only loss is that you can't read old findbugs report. It's your
judgement call to decide if it's OK or not.

There are several techniques to evolve data structure in a compatible
way. One is to declare the old field as transient and then if you
noticed that the old format is loaded, you can convert to the new format
and call save(). SubversionSCM does that.

Another approach is try to use the stable data format as the persistent
data format, instead of using the dump of the in-memory data structure.
So in your case that would amount to just keeping findbugs.xml as its
original form.

> Is there a way to ignore not compatible XML parts in the build.xml
> folder. E.g., using a version number, so that a plugin could decide
> whether it could serialize or not?

I believe exceptions are not fatal. They are printed to indicate a
problem, but I don't think that halts the loading process. Are you just
trying to avoid those exception traces?

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

[Ulli Hafner-2]

> Hafner Ullrich wrote:
> > while extending the findbugs plugin I realized, that the old
> > serialized results in the build folder (build.xml) might be not
> > compatible anymore with a new plugin version. (The
> deserializing code
> > actually throws an
> > exception...)
> >
> > What is the best strategy here? Discarding old builds is
> the easiest
> > way for a plugin developer - providing conversion code the best way
> > for plugin users. I'm not sure whether it's worth the
> effort to keep
> > the findbugs plugin 1.x compatible to build format 1.y (y < x). I
> > would rather provide new features instead of keeping old
> versions compatible.
>
> I believe if action fails to deserialize, that portion will
> just get ignored and the build record itself will be loaded
> successfully --- IOW, the only loss is that you can't read
> old findbugs report. It's your judgement call to decide if
> it's OK or not.
>
> There are several techniques to evolve data structure in a
> compatible way. One is to declare the old field as transient
> and then if you noticed that the old format is loaded, you
> can convert to the new format and call save(). SubversionSCM
> does that.

I see!

>
> Another approach is try to use the stable data format as the
> persistent data format, instead of using the dump of the
> in-memory data structure.
> So in your case that would amount to just keeping
> findbugs.xml as its original form.
>

Luckily, I already use that approach:-) I just persist additional
data like the total number of warnings, etc. in the build publisher
Action.

> > Is there a way to ignore not compatible XML parts in the build.xml
> > folder. E.g., using a version number, so that a plugin could decide
> > whether it could serialize or not?
>
> I believe exceptions are not fatal. They are printed to
> indicate a problem, but I don't think that halts the loading
> process. Are you just trying to avoid those exception traces?

Actually, yes. I thought hudson users don't like exceptions on their
console.
But indeed the findbugs functionality still is available for new builds.


Thanks, Ulli

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kohsuke Kawaguchi]

Hafner Ullrich wrote:
> Actually, yes. I thought hudson users don't like exceptions on their
> console.
> But indeed the findbugs functionality still is available for new builds.

Sometimes these errors indicate a real issue, so it's not entirely clear
if just suppressing them is a good idea. But dumping a large number of
stack traces to console won't help people either.

I guess it would be nice if Hudson can capture load errors and report
them in the web UI. I was thinking about this in the context of broken
changelog.xml, empty build directory, etc., which are somehow created.
Fixing these problems require user actions, so I thought maybe we need
an UI for that.


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]