I am interested in creating FUSE ESB archetypes using the q4e Maven plugin for Eclipse (http://code.google.com/p/q4e/) rather than using the Maven plugin bundled with the IONA FUSE Tooling. The immediate advantage of q4e over the FUSE Tooling is its ability to create Camel and CXF projects from within the Eclipse IDE which the FUSE Tooling does not currently support. Q4E also appears to be the initial codebase for the new Eclipse Integration for Apache Maven (Eclipse IAM) Technology project starting up at the Eclipse Foundation so I would prefer our developers become familiar with its UI etc.
Unfortunately, Q4E cannot co-exist in the same workspace as the Maven support bundled in the IONA FUSE Tooling. So if I want to use all the non-Maven pieces of the IONA FUSE Tooling, is there a way to disable just the Maven pieces of the IONA FUSE Tooling plugin? Also, how much of the IONA FUSE Tooling's ability to deploy artifacts to the WTP-based FUSE ESB server dependent upon the Maven portion of the Maven tooling?
We're also looking at replacing the existing m2eclipse code with q4e -- as you have already discerned, there were some changes made to the m2eclipse code base, which I gather were not accepted back into the main development stream. It's a good move for us to replace the existing m2eclipse dependency with q4e.
So, let's get to your questions - first, we haven't been updating our m2eclipse code to track the latest versions of that project. We're going to go down the road of q4e to replace, rather than having a messy catchup. I hope this statement will cover all of the questions in your first post.
Q: if I want to use all the non-Maven pieces of the IONA FUSE Tooling, is there a way to disable just the Maven pieces of the IONA FUSE Tooling plugin?
There's no straightforward way to do this, I think. The
org.maven.ide.eclipseplugin contributes some 20 extensions to Eclipse, ranging from the usual commands and decorators, to launch pages, wizards, natures and builders. A replace will need to fill out these extensions, mapping them to their own implementation. The
org.maven.ide.eclipse.wtpplugin contributes a handful, mostly around facets and a server publisher - which I think leads in to the next question.
Q: Also, how much of the IONA FUSE Tooling's ability to deploy artifacts to the WTP-based FUSE ESB server dependent upon the Maven portion of the Maven tooling?
org.maven.ide.eclipse.wtpplugin provides an extension to allow the publishing of artifacts to servers (in the context of the WTP Service Framework). The publishing is actually done using maven2 also - the code in the publisher will execute maven2 against a goal that is conventionally named moduleId.publish.goal</tt>. So maven is in there all the way.
Thanks for your detailed response. Do you have an idea of the major tooling features I would give up by using a combination of Eclipse STP, q4e, and the Cimero WTP Server Runtime instead of the IONA FUSE Tooling in the short term until IONA delivers a next-generation Tooling platform?
I have a requirement to provide support for creating CXF top-down and bottom-up services that are deployable to the FUSE ESB Server and that can leverage the JAX-WS STP features. Once I have a cxf-se-service-unit project imported into Eclipse, do you what manual steps might be required to STP-enable such a project? I'll be trying to reverse engineer this capability in the near future and then hopefully automate such a process. Any tips you could provide would be appreciated.