The original purpose of annotation scanning was to provide config generation. That worked well at first, but then we discovered Forge and that made it easier to generate config behind the scenes while exposing basic, intuitive commands to the user. Then our Eclipse tooling really took off, and we could keep the user out of the XML configuration completely. All of this put a lot less emphasis on the role and importance of annotation scanning. One drawback with evolving annotations to include things like binding and promotion is that it starts to bleed packaging and deployment concerns into the service implementation layer. It does make things easier, but it can limit flexibility as well.
I'm totally open to expanding our toolset to non-Eclipse environments, as we recognize that not all people are Eclipse fans. Eclipse will be our primary tools platform for the forseeable future, but that doesn't mean we can't accommodate other tools as well. Some possibilities:
- Continue to evolve the Forge tooling and use that as a bridge.
- Investigate alternate serializations of the config model which are friendlier to edit directly - a DSL, for example.
- Look into a web-based editor, which is something on the radar for other concerns already.
Thanks for the quick reply Keith. I certainly understand the lack of flexibility that might be imposed by applying deployment concerns at the compiled code level. I suppose I was hoping it might be approached in the same way that CDI does interceptors and decorators. Perhaps providing something like a @ServiceBinding annotation which could be applied to a custom annotation type used to link a service interface to a gateway type, and then requiring a line in the xml to enable it. I look forward to seeing where you guys go with this, but in the meantime I'll probably just delegate the configuration tasks to someone on my team who prefers Eclipse