The future work needed is quite clear so this was a short session for people with special interest :

• Briefly covered the history of transformers, and how the builder API had made it easier to create transformers correctly.
• Outlined common mistakes people make when writing transformers.
• Common use cases in the transformers document: https://docs.jboss.org/author/display/WFLY8/Domain+Mode+Subsystem+Transformers.
• Once the common use cases are more fleshed out it could be of value to create a higher-level ‘use-case API’ on top of the existing builders to make the work easier in the future.
• Undecided whether transformers should keep on passing in the default values to the resource transformation during testing or not, both have their advantages:
  • Keep default values: You actually get to see that the effective models (i.e. with defaults resolved) are the same following transformation. It however does not check that the resource transformers handle discard/reject based on default values correctly.
  • Don't keep default values: You actually get to check that resource transformers handle discard/reject of default values correctly. However, since the builer this should get covered by the operation part of the transformation tests, so it ought to be ok as is. There is a Jira for this option ([WFLY-2589] ReadTransformedResourceOperation should set include-defaults=false when calling read-resource - JBoss Issue …) which I think I will turn down in light of this.
• Showed the WIP to make transformers less monolithic as outlined in ([WFLY-2512] Transformers chained for versions - JBoss Issue Tracker).
• Discussed idea about removeing need for resource transformers by using describe operation also for host registration [WFLY-568] Consider using a "describe" notion for providing the model to slaves on registration - JBoss Issue Tracker
• Investigate making testsuite not run transformer tests by default, this way external contributors won't get terrified when they get transformers test failures
• Discussed ideas moving transformers & tests outside of subsystem code
  • Maybe have "add on" module with all transformers and tests for them.
  • for start we could grammatically add "skip" tests in testing framework if some system prop not set
• How will transformers work with going forward and especially with management.next