GeezerVison

Documentation is still missing, would like to know if this is something you want inside spotless, before I do the tedious documentation work. 😄

@nedtwigg I played around with #524. Classloading is a bit awkward... Do you have any better idea?

I'll have another go at the class loading stuff after the other two PRs are in. Can't handle all the parallelity in my brain. 🤣

I could get rid of the serializing deserializing, but I couldn't get rid of the DelegatingClassLoader.

The problem is the following:

• The SortPomFormatterFunc directly references classes from the sortpom dependency
  • so we can't load it from the current ClassLoader, since that doesn't know about the sortpom dependencies
  • we can't load it from the JarState ClassLoader, since that doesn't know about SortPomFormatterFunc, SortPomState and FormatterFunc
  • So we need a ClassLoader, that knows about both
• My first idea was to change the FeatureClassLoader to allow loading SortPomFormatterFunc from the buildToolClassLoader
  • This would attachSortPomFormatterFunc to the buildToolClassLoader
  • As soon as the constructor is retrieved via reflection, the dependencies of the class will be tried to load with the buildToolClassLoader
  • This fails, since the buildToolClassLoader doesn't know about the sortpom package, since it is effectively a parent from the `FeatureClassLoader, and classes from it's children are invisible
• So the SortPomFormatterFunc needs to be attached to a ClassLoader, that knows about the sortpom package: the DelegatingClassLoader
  • It uses the current ClassLoader and the FeatureClassLoader as sources
  • But it doesn't load the classes directly from them (since they would be attached to the source classloaders, bringing us back to the previous problem)
  • Instead it loads the classes as resources, and then calls define class, to attach them to the DelegatingClassLoader
  • Now SortPomFormatterFunc and all classes from the 'JarState' are loaded by the same Classloader and can see each other and all is fine...
• ... except that now SortPomState and FormatterFunc are also attached to DelegatingClassLoader and the funny De-/Serializing of the state and the call to 'apply' via reflection is needed
• That's why the DelegatingClassLoader now excludes those 2 classes from the custom classloading process and just returns the Class objects already loaded
• Which only works, if the SortPomState and its member fields are public

I hope this helps to understand, why I did it in this way. If there is an easier or more elegant solution, I'm all for it. 😄

Well I broke eclipse, but I fixed PomStep. Does this approach look good to you @tisoft? You got all the hard parts working, I just massaged things around with an eye towards other parts of Spotless adopting this same "glue" approach.

@tisoft I think all we need now are changelog updates and documentation. Another fantastic PR, thanks very much! You were the savior to come and finally figure out how we can do #524, which will make the project much easier to read and contribute to.

@nedtwigg Added documentation and changelog entries.

Released in plugin-maven 2.15.0

I advise the following:

• test in a production setting to make sure that the published artifact has the glue code
• once it is confirmed working, submit a PR to https://github.com/Ekryd/sortpom showing how to use it with spotless

I also anticipate that you will want to add a version property to SortPomCfg, so that you can use the latest version of sortpom without needing to publish a whole new set of Spotless artifacts each time, but that can wait until it's needed.