Re: Plugin compatibility when adding a class

On Fri, Jun 16, 2017 at 7:53 PM, Christian McHugh wrote: > I changed my > "clientInterface" field from a String to a custom object. You cannot change the type of an existing field. You can introduce a new field with a different type, and have `readResolve` do the data

Re: Plugin compatibility when adding a class

I think I have this almost going. The issue seems to be that I changed my "clientInterface" field from a String to a custom object. Even though my readResolve() returns the 'this' object with the new BasicClient type, for any old projects that have the old String field in their

Re: Plugin compatibility when adding a class

2017-06-16 12:19 GMT+02:00 Christian McHugh : > On Friday, June 16, 2017 at 11:12:27 AM UTC+1, Robert Sandell wrote: >> >> The XStream deserialization from config.xml to the object graph don't use >> the DataboundConstructor et.al. It is only interested in mapping xml

Re: Plugin compatibility when adding a class

On Friday, June 16, 2017 at 11:12:27 AM UTC+1, Robert Sandell wrote: > > The XStream deserialization from config.xml to the object graph don't use > the DataboundConstructor et.al. It is only interested in mapping xml data > to fields (in most cases). > > DataboundConstructor is only used for

Re: Plugin compatibility when adding a class

The XStream deserialization from config.xml to the object graph don't use the DataboundConstructor et.al. It is only interested in mapping xml data to fields (in most cases). DataboundConstructor is only used for formbinding from the UI and pipeline step definitions etc. /B 2017-06-16 12:03

Re: Plugin compatibility when adding a class

Great example, thanks! Let's say that a release had already been made which changed the databoundconstructor. In that case, the constructor's api is already modified. In this theoretical example, is there a mechanism by which the job config.xml could be updated to match the new constructor

Re: Plugin compatibility when adding a class

Sometimes it is just simpler to move to a new implementation class entirely. You keep Just Enough™ of the old class around that it can be read from disk... and then you add a `readResolve` method that instantiates and returns the new class Here is a very old example of doing this for a complex