Hi Scott,
You can run your routes from the IDE easy peasy - although, not
obviously. I usually use the Maven camel:run plugin, pointing the plugin
to a Spring context that loads up my route. You can then run that from
Eclipse if you want, through a run or debug profile, and it'll kick off
your route.
One nice thing about this approach is that you're forced to separate out
all your OSGi dependencies, as the camel:run plugin is doing a non-OSGi
deployment. This can insulate you for the future: in case you ever
decide to deploy your routes in a non-OSGi container, like, say, Tomcat,
then you already have the Spring Context that can do it for you.
Hope that helps. One other thing to make sure your developers are aware
of is how to run ServiceMix in debug mode (i.e. set KARAF_DEBUG=true in
the environment) and then connect to this from an Eclipse remote
debugging session, I think using port 5005. You can then debug all your
OSGi stuff while it runs in the container.
Hope that helps! In the meantime, if you get any look with your Pax
Construct (or Pax Exam) approaches, do let me know. Am always open to
new ways to get things done.
Best,
Ade.
http://fusesource.com
On 16/09/2010 06:05, Scott Christopher wrote:
We have recently started using ServiceMix, primarily as a container for Camel
routes and so far we have had great success. However, the one thing we are
still uncertain about is setting up a practical and OSGi-friendly development
environment.
Ideally we would like to be able to "run" our Camel routes from within our IDE
while developing, though as we are making use of OSGi features in our code, we need to
fire up an OSGi environment and load up our bundled Camel routes.
Currently each developer is running a separate local instance of ServiceMix and
deploying the compiled bundle whenever they need to test their development,
however it would be preferable to keep this contained within the IDE.
We have looked into using Osmorc [1] and the Pax Construct Maven plugin [2],
both with varying degrees of success. Pax Construct seems to be closest to what
we want (the scan-features option takes care of resolving most of the bundle
dependencies) though the plugin doesn't appear to cache any of maven downloads,
which is annoying when having to wait for it to download the internet every
time you fire it up.
Can anyone respond with how they have had success in achieving this, or a
similar setup?
Regards,
Scott Christopher
[1] http://www.osmorc.org/
[2] http://www.ops4j.org/projects/pax/construct/maven-pax-plugin/index.html