Handling features (was Re: Reorganizing the svn tree)

[Guillaume Nodet <gn...@gmail.com>]

On Nov 30, 2007 6:17 PM, James Strachan <ja...@gmail.com> wrote:

> +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.
>

I need to play a bit more with OBR, but downloading, installing and starting
a feature (which includes several bundles) using OBR can be done in a single
command from the gshell console.   Using the latest distribution, you should
be able to run the following commands from the shell:

   obr/addUrl http://www.knopflerfish.org/repo/bindex.xml
   obr/start ksoap-osgi

The first one will add the knopflerfish obr repo to the list of available
repos (we can easily configure obr so that the default repo points to our
own OBR repo).
The second one will look for the bundle "ksoap-osgi" in the configured
repos, download all the needed bundles by analysing the imported packages
and selecting the appropriate bundles to download, install them and start
them.
I think it should be quite easy to reuse the same code to select the needed
bundles at build time so that we can create custom distributions easily by
providing a list of features to include.   But it would not easily include
additional resources to include in the distribution (like shell scripts,
configuration files, etc...).   Another downside is that OBR uses dependency
resolution to select bundles to download, so that a feature which may
include several bundles (not linked by an export/import package) would
require an additional bundle to define these dependencies.

The current 'features' is quite the opposite as it's just a zip which is
easy to use at build time, but not so easy to install at runtime.  In
addition, there's no really concept of dependencies and I envision problems
with the maven transitive dependencies (which brings easily 100s jars).

I will experiment a bit more with OBR, but the fact that the latest bundle
plugin automatically update the OBR index is really interesting.




>
>
> On 29/11/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > On Nov 29, 2007 4:58 AM, Bruce Snyder <br...@gmail.com> 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
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/