Christian,
I agree with you that there should be a more straightforward way to do this. The way this is set up at the moment actually has a bit of a background.
The matter of Custom Service Tasks was a goal from the start of the Designer project. The idea was that developing an extension to the tool should be as easy as possible. The focus was on developing the extension. Forcing the developer to implement a complete Eclipse bundle using PDE was considered too much of a hassle. The artifact to produce should be little else than a simple JAR file.
This approach implies that the way to add the functionality in the JAR to Eclipse that makes most sense is to add it to the user libraries of Eclipse. At the moment, this is a manual job, which I agree, sucks for the user. We assumed originally that an expert would customize the tool and then hand it off. The extension is a customization of the tool and not of a single project, so even if we could evaluate the Maven dependency container or simply the project's classpath, I'm not sure the Maven dependencies would be the right place for this. For instance, how would you ensure the dependencies are always in the pom.xml for new projects created?
Still, I think this could be easier, but before we move to change or extend this, I want to think through the options, especially if we have to maintain two options. For instance, would you find it bothersome to develop a plugin for your Custom Service Tasks or do you think the distribution gain (Eclipse's update system) would be worth the extra effort? Or would you rather have an easy way to develop an SDK-like distribution that can set the user libraries itself? That seems too complicated to me. A custom solution to point to a URL for your customizations would also be an option, although I think that's just re-inventing the wheel. There may be other options I haven't thought of.
