Allows for multiple deserialization class renames files

[nakomis]

No description provided.

[aledsage]

Worth adding test case(s).
(ping me offline if you want to talk about how best to write good unit-test coverage for this).

Also note the related discussion the mailing list. An alternative suggestion is that we pick up all files with the given name on the classpath (rather than all those in a given directory). I personally prefer the approach of all files in the directory. That would allow us to more easily incrementally add things (e.g. have separate files for upgrading between versions).

---

I wonder about a nicer package name than org.apache.brooklyn.core.mgmt.persist.deserializingClassRenames. I imagine many people will just put this in their ./conf/ directory, so we don't want them to have to create a really deep nested directory.

---

Another thing we could add (in the future?) is if there are conflicting changes - e.g. A is renamed to B in the first file, and B is renamed to C in the second file. Currently, the result would depend on the other the files were processed: i.e. it could be "B" or "C". It would be good to be more predictable.

I'm fine with that being deferred for now.

[ahgittin]

@nakomis ping

[tbouron]

Hey @nakomis, overloading the class deserialisation has been addressed in #492 but for karaf edition only. Do you also need it for the classic edition? In this case, could you rebase on the latest master + add tests?

[nakomis]

Not needed for classic, so #492 should suffice, closing