Allow Wisdom to run in an OSGi container without Chameleon

[magnet]

Currently, the application-configuration bundle depends on the org.ow2.chameleon.core.services package that is explicitly exported through the extra packages framework property before the actual launching take place.

We're planning on using Wisdom in an existing OSGi system with a separate launcher and we'd like to refrain from exposing this package through the said property, but as a package exported by a regular bundle. Chameleon core is actually not a bundle either, so it cannot be installed into a framework and give resolution to the package.

I suggest moving the core services to an external JAR that is also a bundle, and even better: providing TWO bundles, one for the API only and one with the implementation (the activators package in Chameleon Core). This way it should be possible to rely on different implementations for deployment such as Felix FileInstall, that is already present in our environment.

The 3rd, best solution for using Wisdom independently: actually not depending on Chameleon at all, and having application-configuration provide the interfaces for its configuration deployment capacities, and bridging it with Chameleon services or other deployment systems (or just disabling configuration reloading altogether by not providing such a service).

(I suppose the issue is sitting halfway between wisdom and https://github.com/ow2-chameleon)

[cescoffier]

There is a 'service' artifact from chameleon core for this usage. However the watch mode won't work.

Sent from my iPhone

On 4 juil. 2015, at 19:34, Simon Chemouil notifications@github.com wrote:

Currently, the application-configuration bundle depends on the org.ow2.chameleon.core.services package that is explicitly exported through the extra packages framework property before the actual launching take place.

We're planning on using Wisdom in an existing OSGi system with a separate launcher and we'd like to refrain from exposing this package through the said property, but as a package exported by a regular bundle. Chameleon core is actually not a bundle either, so it cannot be installed into a framework and give resolution to the package.

I suggest moving the core services to an external JAR that is also a bundle, and even better: providing TWO bundles, one for the API only and one with the implementation (the activators package in Chameleon Core). This way it should be possible to rely on different implementations for deployment such as Felix FileInstall, that is already present in our environment.

The 3rd, best solution for using Wisdom independently: actually not depending on Chameleon at all, and having application-configuration provide the interfaces for its configuration deployment capacities, and bridging it with Chameleon services or other deployment systems (or just disabling configuration reloading altogether by not providing such a service).

(I suppose the issue is sitting halfway between wisdom and https://github.com/ow2-chameleon)

— Reply to this email directly or view it on GitHub https://github.com/wisdom-framework/wisdom/issues/523.

[magnet]

Thanks, I didn't notice it was on chameleon core with a different classifier. I'll test that :)

[cescoffier]

It's:

<dependency>
    <groupId>org.ow2.chameleon</groupId>
    <artifactId>chameleon-core</artifactId>
    <version>1.10.7</version>
    <classifier>service</classifier>
</dependency>

That's said, I don't recommend replacing chameleon as it would break a couple of feature such as the libraries support. If you want a different set of bundles, you can build your own wisdom distribution.

[magnet]

Yeah thank you, I found it yesterday just a minute after my initial reply.

Just to let you know our use case of Wisdom: we are only using it as an OSGi Web framework/glue code for REST services (and no Web assets that we want the Wisdom maven plugin to build). Wisdom allows us to map our OSGi services to REST routes explicitly and register extensions such as filters or interceptors or Jackson modules as OSGi services using a "modern" approach to define controllers and routes.

We're not very much interested about the whole "toolchain" story :-). Thus we not using the Maven plugin or packaging neither its watch mode (we have something similar that updates our bundles as we go when we develop coupled with FileInstall), we're not particularly interested by dynamic configuration reloading and we're not interested in on-the-fly bundling of third parties libraries either as we're already working with valid bundles only.

So far we are doing the work to select only the pieces we're interested in, but it could also be interesting in a future overhaul of the project to split Wisdom the Java framework from Wisdom the Maven framework and make distributions of those with different feature sets (e.g without the Chameleon launcher) :).

I'm closing this for now.