+1 on the reorg. I was wondering if it might make things a bit easier to put the features/bundles/runtimes/parent pom specifying versions of things like spring, osgi, camel and stuff - in a single 'runtime' release, then release it whenever we need to. Apart from the runtime parts, most of the rest of it (bundles / features / parent pom) is mostly just pom/version stuff so we can release frequently.
e.g. we have spring+osgi in the core and wanna release it whenever those things change; so having the bundles & runtime together might reduce the amount of releasing we have to do a bit. On 29/11/2007, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > On Nov 29, 2007 4:58 AM, Bruce Snyder <[EMAIL PROTECTED]> wrote: [snip] > > Also, on a slightly different note, the SMX 4 runtime is going to be > > based on OSGi, how will this affect the ability to embed SMX into > > another Java application? I don't imagine that folks will always want > > an OSGi container running inside of their Java app, so how will we > > work around this to still allow it to be embedded? > > > There are two ways of doing that: the first one is to simply embed the OSGi > runtime in the application (a web app or not). It's quite easy to do and I > do not see any problems. I see that as the easiest way because the changes > would be minimal, as you would just get rid of things like the file poller > which automatically installs bundles etc... > The other way is to just use the jars and remove all OSGi stuff. The NMR > api has no dependency on OSGi and OSGi is mostly used through spring for > wiring everything, for classloaders and for deployment. If you want to > embed ServiceMix in your app, just use spring to wire all you need together. I've been struggling a bit lately to get stuff to work inside OSGi; am sure I'm not alone and that others will hit this too - it can take a while to get all the OSGi metadata aligned just right so that things actually deploy. So I'm wondering if the ServiceMix Runtime could also support the 'flat class loader model' approach too. (i.e. a single lib directory with a bunch of regular jars in it and one ClassLoader boots 'em all up on startup). This wouldn't deal well with hot redeployment or anything; we'd just start the whole JVM up, if things change, we kill it and restart the JVM - but it would offer a nice simple model for users who don't need hierarchal class loaders and hot-redeployment and so forth. (Am not sure if we could make a lib directory of jars appear like a single OSGi bundle or something). It'd be good to make sure we can use ServiceMix runtime with OSGi or with a simple lib dir of jars. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
