My first impressions of the Eclipse tooling
oehme Nov 17, 2013 8:54 AMFirst of all I want to say that I really like the idea behind Switchyard. I'm all for more typesafety, less configuration and better tooling. So while the feedback below is mostly negative, I'm just trying to help you improve this great framework.
I tried the Eclipse tooling a few weeks ago and only built a very small "Hello World" example. But even while doing that I stumbled upon many usability/maintenance issues that I would like to point out. Some of those may be due to my lack of knowledge, so please feel free to point me in the right direction if you think that any of the below points is not justified.
No refactoring support
When I use JDT's rename refactoring to rename a class or method, those changes are not reflected in the Switchyard configuration. I have to fix the XML file by hand.
Also, there is no way to "autogenerate a WSDL" from an Interface, meaning that any new methods are automatically added to the WSDL. I think this would be pretty convenient.
String constants all over the place
The autogenerated classes (e.g. Transformers) have String constants smeared all over the place. If I am to change a class or method name, there are still lots of silently broken Strings pointing at the old name.
Questionable use of annotations
This one really puzzled me. If I annotate a method with @Transformer, I have to use a special build plugin that then adds this method to the XML file which is then evaluated at runtime. Why is this annotation not evaluated at runtime directly? This seems like unnecessary indirection and code duplication to me.
Internal interfaces take too much effort
Often times, I just want to define some internal services (e.g. for splitting, routing or filtering messages with camel). To do so, I define "ESB" interfaces, because adding Java interfaces for such trivial things seems wasteful. But I need to define that interface two times. Once when defining the service and another time when referencing the service. Why can't the interface be inferred in the second case?
Some features are well hidden
It took me some time to discover that I can add Validators via the properties menu. The visual editor should at least contain a small hint to that.
Frequent crashes
The visual editor crahses quite frequently. All the edit panes are gone and the only way to get it back is to restart Eclipse
Silent failure
I accidentally defined two endpoints with the same name. This did not lead to a clear error message. Instead, the first endpoint was used for all requests, resulting in puzzling error messages when confronted with messages that where intended for the second endpoint.
Tightly bound to Maven
The whole tooling seems to be tightly bound to Maven. While this is nice if I'm actually using Maven, it will probably put off users of Gradle and other build systems. But even for Maven users, modifying the pom.xml is not such a great idea. You usually have dependencies managed in a parent POM, but the tooling always modifies the POM of the current project, probably overriding any parent configuration.