I’ve created a topic on the eBay Open Source forums for capturing ideas for what needs to be addressed in the Turmeric project over the next several months. I’m looking for some input from those in the SOA, Maven, and Eclipse communities in this regard. Turmeric has not been released for very long, so I suspect most people are either kicking the tires, or taking a wait and see attitude to see what we have in-store for the next year. The Eclipse tooling currently supports what the committers on the project have termed “Legacy Mode”. This is the directory structures and locations of files where the Turmeric Eclipse Plugin will generate code, or expects it to exist.
However, during the process of bringing items to open source, we adopted many of the Maven best practices and directory structures. Unfortunately this also means that currently the Turmeric Eclipse Plugins work best in legacy mode and we need to address this as we go forward. POMs and the way Maven is used by the Turmeric Eclipse Plugins is still heavily influenced by the legacy format, but we would like to change that.
We’d also like to focus on ease of use. Turmeric projects and the framework give a lot of flexibility in the way things can be designed and configured. The problem is that most of this stuff is configured using XML files, and in many ways, the integration and content assistance is lacking. Also, testing of the service projects can be much more involved than it needs to be from within Eclipse, and we plan to address that as well with hopefully better integration with WTP, JEE, and Dynamic Web Projects.
On the Maven side of things, some thoughts are to include and leverage Maven Archtypes for creating the initial projects and directory structures. We need to figure out a way to integrate the existing Wizards for Turmeric with the Maven Archtype generation process. We also are planning to align with m2eclipse when it is released as part of the Indigo release train.
Runtime side of things, making the runtime framework play better with OSGI is on the list. This means providing P2 as well as possibly OBR repositories for runtime. This is going to take a while as we need to make the classloading mechanisms runtime uses play nicely with OSGI.
So those are just some thoughts, and planning is still in the very early stages. If you are interested in contributing ideas please do post a message on the forum topic. If you have problems registering, please see the topic on how to register for the forum.