maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Ching" <>
Subject Re: OSGi bundles as dependencies
Date Wed, 27 Jun 2007 22:52:49 GMT
Hi Steven,

Thanks for the response, I very much appreciate the conceptual information.
However, being a bit new to maven, I am looking for a more practical, though
obviously less than ideal, solution to my problem, e.g. possibly a cookbook
example or even just a nudge in the right direction (e.g. I did see someone
post a vague reference to using the maven-dependency-plugin and maybe some
ant plugin to unzip the dependency, but it was a bit hard to follow how that
was all put together or even if that was the right first-step to pursue).
Maybe just treating the individual jar files in the bundles as the
dependencies is the way I should go and build up the structure that the BIRT
viewer needs?

I would absolutely love to see first-class support for OSGi bundle
dependencies, possibly even a BIRT maven plugin would help immensely, but
I'd assumed nothing like that was available when my google searches didn't
turn up much information ;-)



On 6/27/07, Steven E. Harris <> wrote:
> Craig Ching <> writes:
> > Has anyone done this or anything like this?
> Yes, but we've only "solved" it by not solving it and faking it.
> Maven's "provided" scope doesn't quite apply for bundles, as the
> entire bundle's class space should not be on the consumer's class path
> at compile-time. Similarly, "runtime" scope isn't appropriate
> either. The (entire) bundle should not be available on the
> compile-time class path, nor should it be available at run-time
> unmitigated by an intervening OSGi framework.
> In cases where we do need compile-time dependency on portions of a
> bundle, we specify it at "provided" scope and force the developer to
> be diligent about not relying on non-exported packages in the
> bundle. Unfortunately, these transgressions will only show up as
> package resolution errors in the OSGi framework when the bundle under
> development attempts resolution.
> --
> Steven E. Harris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message