[Heads up] ServiceMix Kernel and system folder as a maven repo

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

Today, I've hit a bug in ServiceMix Kernel (namely SMX4KNL-65), which
is about the fact that moving the whole directory where the kernel has
been started the first time does lead to an incorrect behavior (well,
the kernel starts, but displays lots of errors).  The main reason is
that when starting, the bundles listed in the system folder are
installed and felix barfs when installing two bundles with the same
symbolic name / version, but with two diffferent urls.  This happen
because the url used when installing the bundle is the absolute path
to the bundle in the system dir.

Trying to fix this problem, I found a good solution would be to use
the maven url style for the system bundles themselves, which would
then make it easy to organize the system folder in a m2 style
structure.  So I've gone ahead and implemented that.  In addition I've
added a small feature to the filemonitor service to allow system
properties to be interpolated when loading properties file for the
config admin service (the purpose was to allow the use of
${servicemix.home} to define a m2 repository for the maven handler.
The last step was to allow the features service to install some
features at startup time.

In short, there are been a few enhancements to the kernel, so that we
should now be able to build the full distribution by adding the needed
files to the system folder and reference the features to be installed.
  This should be much cleaner as the current way to build the
distribution, which is to list all the new bundles in the
startup.properties file (where the upper part needs to be kept in sync
with the kernel), and is very error prone.

The only problem is that it's not a trivial change, so I think we should either:
  * do a RC2 of the kernel, or
  * create a branch from the revision before I started those changes,
release 1.0.0 from this branch, and change the version to 1.1-SNAPSHOT

I'm leaning toward the first solution, as the goal is to rework a bit
the full smx4 assembly to leverage those: the work to make the JBI
components work as OSGi bundles is nearly finished and I'll start
including those in the distribution next week (instead of using the
JBI packaged components).  So if we release 1.0.0 now, we won't use it
for the full smx4 distribution, which is a bit silly.

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

Re: [Heads up] ServiceMix Kernel and system folder as a maven repo

[Hiram Chirino <hi...@hiramchirino.com>]

Awesome.. I totally agree that's the way the kernel SHOULD work.  So
I'd too rather RC2 it.

On Fri, Jul 25, 2008 at 12:09 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Today, I've hit a bug in ServiceMix Kernel (namely SMX4KNL-65), which
> is about the fact that moving the whole directory where the kernel has
> been started the first time does lead to an incorrect behavior (well,
> the kernel starts, but displays lots of errors).  The main reason is
> that when starting, the bundles listed in the system folder are
> installed and felix barfs when installing two bundles with the same
> symbolic name / version, but with two diffferent urls.  This happen
> because the url used when installing the bundle is the absolute path
> to the bundle in the system dir.
>
> Trying to fix this problem, I found a good solution would be to use
> the maven url style for the system bundles themselves, which would
> then make it easy to organize the system folder in a m2 style
> structure.  So I've gone ahead and implemented that.  In addition I've
> added a small feature to the filemonitor service to allow system
> properties to be interpolated when loading properties file for the
> config admin service (the purpose was to allow the use of
> ${servicemix.home} to define a m2 repository for the maven handler.
> The last step was to allow the features service to install some
> features at startup time.
>
> In short, there are been a few enhancements to the kernel, so that we
> should now be able to build the full distribution by adding the needed
> files to the system folder and reference the features to be installed.
>  This should be much cleaner as the current way to build the
> distribution, which is to list all the new bundles in the
> startup.properties file (where the upper part needs to be kept in sync
> with the kernel), and is very error prone.
>
> The only problem is that it's not a trivial change, so I think we should either:
>  * do a RC2 of the kernel, or
>  * create a branch from the revision before I started those changes,
> release 1.0.0 from this branch, and change the version to 1.1-SNAPSHOT
>
> I'm leaning toward the first solution, as the goal is to rework a bit
> the full smx4 assembly to leverage those: the work to make the JBI
> components work as OSGi bundles is nearly finished and I'll start
> including those in the distribution next week (instead of using the
> JBI packaged components).  So if we release 1.0.0 now, we won't use it
> for the full smx4 distribution, which is a bit silly.
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com