[all][osgi] how to deal with non-bundle dependencies?

[Stefan Bodewig <bo...@apache.org>]

Hi all

I must admit I've never been a fan of OSGi and likely don't know enough
about it.

Compress like many of the components around here is an OSGi bundle and I
recall I submitted a trivial patch to XZ for Java - our only dependency
as of now - to turn it into a bundle as well.

How does one deal with adding dependencies on jars that are not bundles?
Is it possible at all?

A quick search seems to imply we'd either have to bundle the dependency
jar with ours or turn it into a bundle ourselves (by wrapping it).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [all][osgi] how to deal with non-bundle dependencies?

[Bertrand Delacretaz <bd...@apache.org>]

On Thu, May 4, 2017 at 4:11 PM, Matt Sicker <bo...@gmail.com> wrote:
> ...The easiest way to do this in unit tests would
> be using something like Pax Exam...

We're doing that a lot in Sling, see
https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/org.apache.sling.commons.messaging.mail
for a simple example.

The trick is loading the bundle that you're building in the same Maven
module, in that example we use the bundle.filename system property for
that.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [all][osgi] how to deal with non-bundle dependencies?

[Stefan Bodewig <bo...@apache.org>]

On 2017-05-04, Matt Sicker wrote:

> Without a container, the "easy" way would be to embed Felix and start up
> the OSGi framework itself. The easiest way to do this in unit tests would
> be using something like Pax Exam <
> https://ops4j1.jira.com/wiki/display/PAXEXAM4/Pax+Exam>.

Ah, many thanks to you and Bertrand

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [all][osgi] how to deal with non-bundle dependencies?

[Matt Sicker <bo...@gmail.com>]

Without a container, the "easy" way would be to embed Felix and start up
the OSGi framework itself. The easiest way to do this in unit tests would
be using something like Pax Exam <
https://ops4j1.jira.com/wiki/display/PAXEXAM4/Pax+Exam>.

On 4 May 2017 at 01:11, Stefan Bodewig <bo...@apache.org> wrote:

> On 2017-05-02, Matt Sicker wrote:
>
> > Apache ServiceMix tends to repackage a lot of 3rd party libraries as
> > bundles, so that's one method. End users can use things like bnd to
> > generate a manifest for 3rd party jars (e.g., installing jars using the
> > "wrap:" URI in Apache Karaf), though that's kind of similar to
> automodules
> > in JPMS which isn't the best thing.
>
> In our case with org.brotli:dec at Compress the "automodules" approach
> would be good enough. The whole library has a single public class and no
> dependencies, the bundle definition would be trivial.
>
> We've now marked the dependency with "resolution:=optional" and hope
> this allows Compress to remain a valid bundle. Do you know whether there
> is an easy way to test whether a library would work as a bundle without
> actually trying to deploy an application using it into a container?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Matt Sicker <bo...@gmail.com>

Re: [all][osgi] how to deal with non-bundle dependencies?

[Stefan Bodewig <bo...@apache.org>]

On 2017-05-02, Matt Sicker wrote:

> Apache ServiceMix tends to repackage a lot of 3rd party libraries as
> bundles, so that's one method. End users can use things like bnd to
> generate a manifest for 3rd party jars (e.g., installing jars using the
> "wrap:" URI in Apache Karaf), though that's kind of similar to automodules
> in JPMS which isn't the best thing.

In our case with org.brotli:dec at Compress the "automodules" approach
would be good enough. The whole library has a single public class and no
dependencies, the bundle definition would be trivial.

We've now marked the dependency with "resolution:=optional" and hope
this allows Compress to remain a valid bundle. Do you know whether there
is an easy way to test whether a library would work as a bundle without
actually trying to deploy an application using it into a container?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [all][osgi] how to deal with non-bundle dependencies?

[Matt Sicker <bo...@gmail.com>]

Apache ServiceMix tends to repackage a lot of 3rd party libraries as
bundles, so that's one method. End users can use things like bnd to
generate a manifest for 3rd party jars (e.g., installing jars using the
"wrap:" URI in Apache Karaf), though that's kind of similar to automodules
in JPMS which isn't the best thing.

On 2 May 2017 at 02:30, Stefan Bodewig <bo...@apache.org> wrote:

> Hi all
>
> I must admit I've never been a fan of OSGi and likely don't know enough
> about it.
>
> Compress like many of the components around here is an OSGi bundle and I
> recall I submitted a trivial patch to XZ for Java - our only dependency
> as of now - to turn it into a bundle as well.
>
> How does one deal with adding dependencies on jars that are not bundles?
> Is it possible at all?
>
> A quick search seems to imply we'd either have to bundle the dependency
> jar with ours or turn it into a bundle ourselves (by wrapping it).
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Matt Sicker <bo...@gmail.com>