Hi Martin and Rahul, Thanks for the tip! I'll definitely keep my eye on felix.
Cheers, Craig On 6/28/07, Martin Gilday <[EMAIL PROTECTED]> wrote:
http://cwiki.apache.org/FELIX/osgi-plugin-for-maven-2.html This is outdated but hints that something was/is being worked on. ----- Original message ----- From: "Craig Ching" <[EMAIL PROTECTED]> To: "Maven Users List" <users@maven.apache.org> Date: Wed, 27 Jun 2007 17:52:49 -0500 Subject: Re: OSGi bundles as dependencies 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 ;-) Thanks! Cheers, Craig On 6/27/07, Steven E. Harris <[EMAIL PROTECTED]> wrote: > > Craig Ching <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
