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] |
Administrator
|
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. 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] |
> 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] |
Administrator
|
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] |
Free forum by Nabble | Edit this page |