You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Craig Ching <cr...@gmail.com> on 2007/06/27 21:28:17 UTC
OSGi bundles as dependencies
Hi,
I'm a maven newbie. I have what I think is a fairly sophisticated need and
I'm looking for advice on how to resolve this need.
I'm trying to integrate the BIRT viewer into my web app. Basically, this
involves putting some static content in the right place and getting the pom
dependencies right for the plain old jar file dependencies. The one part
I'm not sure about is that the BIRT viewer has some dependencies on some
OSGi bundles as well (specifically, eclipse plugins I think). These bundles
need to go in the WEB-INF/platform directory. I'm not even sure how I begin
to set this up.
Has anyone done this or anything like this? Any advice is appreciated!
Cheers,
Craig
Re: OSGi bundles as dependencies
Posted by Craig Ching <cr...@gmail.com>.
Hi Martin and Rahul,
Thanks for the tip! I'll definitely keep my eye on felix.
Cheers,
Craig
On 6/28/07, Martin Gilday <ma...@imap.cc> 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" <cr...@gmail.com>
> To: "Maven Users List" <us...@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 <se...@panix.com> wrote:
> >
> > Craig Ching <cr...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: OSGi bundles as dependencies
Posted by Martin Gilday <ma...@imap.cc>.
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" <cr...@gmail.com>
To: "Maven Users List" <us...@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 <se...@panix.com> wrote:
>
> Craig Ching <cr...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: OSGi bundles as dependencies
Posted by Rahul Thakur <ra...@gmail.com>.
Hi Craig,
You might want to poll Apache Felix list about Maven OSGi plugin.
Cheers,
Rahul
Craig Ching wrote:
> 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 <se...@panix.com> wrote:
>>
>> Craig Ching <cr...@gmail.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: OSGi bundles as dependencies
Posted by Craig Ching <cr...@gmail.com>.
On 6/28/07, Steven E. Harris <se...@panix.com> wrote:
>
> Craig Ching <cr...@gmail.com> writes:
>
> > Would the best way to approach this be to jar up the bundle and
> > shove into the maven repo with a groupId and artifactId?
>
> Yes, I'd do that first.
>
> > Then have some way to pull and unpack the jar in the right place
> > during the maven install goal?
>
> Actually, I think this sounds more like the "package" goal if you're
> talking about composing a WAR. I've never used the "install" goal to
> move files around like you're describing, always interpreting
> "install" to mean installation of this artifact into a Maven
> repository. However, the more conventional meaning of "install" --
> say, as a Makefile target -- does sound like what you're describing.
My work flow to this point has been to do 'mvn install' in the parent
directory (I'm using a hierarchical project/sub-project layout), then cd to
my webapp project directory and run 'mvn jetty:run'. It appears that the
install goal of the webapp project is creating an exploded war *and* a .war
file and, because of this, it seemed to me that the BIRT viewer applet
should be here and ready-to-go after execution of the install goal. I don't
mind changing my work habits if something isn't working as maven would
normally expect it to ;-)
> This is starting to sound like that
> > maven-dependency-plugin/maven-antrun-plugin solution I was talking
> > about
>
> Yes, the dependency or maybe the assembly plugin could help, but note
> that the maven-war-plugin can do a lot of this file copying and
> unpacking stuff as well.¹
I'm just fiddling with the dependency plugin right now, maybe I should be
reviewing my work flow and checking on the war plugin then? ;-)
> Yeah, I know about Equinox and have played with Knopflerfish a bit,
> > so felix is an ASF sponsored OSGi implementation, sounds great!
> >
> > Thanks for all your help Steve!
>
> No problem. Sorry to have over-explained the OSGi frameworks, but it
> is good to hear that you've already started experimenting.
No problem at all. The information is very much appreciated.
Footnotes:
> ¹
> http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html
>
> --
> Steven E. Harris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: OSGi bundles as dependencies
Posted by "Steven E. Harris" <se...@panix.com>.
Craig Ching <cr...@gmail.com> writes:
> Would the best way to approach this be to jar up the bundle and
> shove into the maven repo with a groupId and artifactId?
Yes, I'd do that first.
> Then have some way to pull and unpack the jar in the right place
> during the maven install goal?
Actually, I think this sounds more like the "package" goal if you're
talking about composing a WAR. I've never used the "install" goal to
move files around like you're describing, always interpreting
"install" to mean installation of this artifact into a Maven
repository. However, the more conventional meaning of "install" --
say, as a Makefile target -- does sound like what you're describing.
> This is starting to sound like that
> maven-dependency-plugin/maven-antrun-plugin solution I was talking
> about
Yes, the dependency or maybe the assembly plugin could help, but note
that the maven-war-plugin can do a lot of this file copying and
unpacking stuff as well.¹
> Yeah, I know about Equinox and have played with Knopflerfish a bit,
> so felix is an ASF sponsored OSGi implementation, sounds great!
>
> Thanks for all your help Steve!
No problem. Sorry to have over-explained the OSGi frameworks, but it
is good to hear that you've already started experimenting.
Footnotes:
¹ http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html
--
Steven E. Harris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: OSGi bundles as dependencies
Posted by Craig Ching <cr...@gmail.com>.
On 6/28/07, Steven E. Harris <se...@panix.com> wrote:
>
> Craig Ching <cr...@gmail.com> writes:
>
> > AFAICT, the OSGi bundles aren't packaged as a single jar, they
> > appear to be much more complex (or maybe I am lacking some
> > understanding of how these bundles are packaged). For instance, in
> > WEB-INF/platform/plugins there are a number of directories with a
> > fairly complex structure.
>
> That's fine. I'd call that an "unpacked JAR", whether or not it was
> ever rolled up into a JAR to begin with. Some OSGi frameworks can use
> unpacked bundles, or, rather, bundles composed as directory structures
> on disk. The only essential artifact that makes something a bundle is
> a META-INF/MANIFEST.MF file with a few OSGi-specific headers. The
> bundle can otherwise contain anything; it need not be compiled Java
> class files, though that's the most common content.
Ah, ok, right, that makes sense. Would the best way to approach this be to
jar up the bundle and shove into the maven repo with a groupId and
artifactId? Then have some way to pull and unpack the jar in the right
place during the maven install goal? This is starting to sound like that
maven-dependency-plugin/maven-antrun-plugin solution I was talking about,
here it is:
maven mailing list reference:
http://www.mail-archive.com/users@maven.apache.org/msg56352.html
the link that refers to:
http://www.mail-archive.com/users@maven.apache.org/msg56352.html
Sounds like that's the right way to approach this?
[...]
>
> > Maybe I should also note that *none* of these are build-time
> > dependencies for my project, maybe that makes a difference? So this
> > is just about packaging the BIRT viewer in my war file.
>
> Well, do you consider composing your WAR file to be "build-time"? Are
> you looking for Maven to help inject the bundle content into your WAR?
>
[...]
Ok, my bad, I really meant no compile time dependencies, just during the
maven install goal. Yes, I want to put the various bundle dependencies into
the WEB-INF/platform/plugins directory during execution of the install goal.
> Before I get to defining specific requirements, though, I'm going to
> > need to get a better understanding of OSGi in general. What project
> > am I looking for when I'm ready for that then?
>
> Apache Felix is an easy to understand OSGi framework implementation,
> and somewhat confusingly under the same umbrella, they're collecting a
> lot of other popular Java artifacts and repackaging them as OSGi
> bundles.
>
> You'll need an OSGi framework within which to test your
> bundle. Eclipse Equinox¹ is another good choice. It's more complex
> than Felix, but at present offers more capabilities. Knoplerfish² is
> another option, but I don't have experience with it to comment
> further.
Yeah, I know about Equinox and have played with Knopflerfish a bit, so felix
is an ASF sponsored OSGi implementation, sounds great!
Thanks for all your help Steve!
Footnotes:
> ¹ http://www.eclipse.org/equinox/
> ² http://www.knopflerfish.org/
>
> --
> Steven E. Harris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: OSGi bundles as dependencies
Posted by "Steven E. Harris" <se...@panix.com>.
Craig Ching <cr...@gmail.com> writes:
> AFAICT, the OSGi bundles aren't packaged as a single jar, they
> appear to be much more complex (or maybe I am lacking some
> understanding of how these bundles are packaged). For instance, in
> WEB-INF/platform/plugins there are a number of directories with a
> fairly complex structure.
That's fine. I'd call that an "unpacked JAR", whether or not it was
ever rolled up into a JAR to begin with. Some OSGi frameworks can use
unpacked bundles, or, rather, bundles composed as directory structures
on disk. The only essential artifact that makes something a bundle is
a META-INF/MANIFEST.MF file with a few OSGi-specific headers. The
bundle can otherwise contain anything; it need not be compiled Java
class files, though that's the most common content.
[...]
> Maybe I should also note that *none* of these are build-time
> dependencies for my project, maybe that makes a difference? So this
> is just about packaging the BIRT viewer in my war file.
Well, do you consider composing your WAR file to be "build-time"? Are
you looking for Maven to help inject the bundle content into your WAR?
[...]
> Before I get to defining specific requirements, though, I'm going to
> need to get a better understanding of OSGi in general. What project
> am I looking for when I'm ready for that then?
Apache Felix is an easy to understand OSGi framework implementation,
and somewhat confusingly under the same umbrella, they're collecting a
lot of other popular Java artifacts and repackaging them as OSGi
bundles.
You'll need an OSGi framework within which to test your
bundle. Eclipse Equinox¹ is another good choice. It's more complex
than Felix, but at present offers more capabilities. Knoplerfish² is
another option, but I don't have experience with it to comment
further.
Footnotes:
¹ http://www.eclipse.org/equinox/
² http://www.knopflerfish.org/
--
Steven E. Harris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: OSGi bundles as dependencies
Posted by Craig Ching <cr...@gmail.com>.
I apologize in advance for the quoting, I'm thinking I should have used my
normal mail account instead of gmail now.
On 6/27/07, Steven E. Harris <se...@panix.com> wrote:
>
> Craig Ching <cr...@gmail.com> writes:
>
> > 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
>
> Maybe I misunderstood your question.
Nah, I don't think I properly expressed my degree of newbness ;-)
If you have an OSGi bundle
> packaged as a JAR that you'd like to depend on
AFAICT, the OSGi bundles aren't packaged as a single jar, they appear to be
much more complex (or maybe I am lacking some understanding of how these
bundles are packaged). For instance, in WEB-INF/platform/plugins there are
a number of directories with a fairly complex structure. For example,
WEB-INF/platform/plugins/org.apache.batik/ are the following
directories/files:
about.html (file)
about_files (dir)
lib (dir)
META-INF (dir)
plugin.properties (file)
Maybe I should also note that *none* of these are build-time dependencies
for my project, maybe that makes a difference? So this is just about
packaging the BIRT viewer in my war file.
, you can specify its
> Maven coordinates as follows. Let's take the Felix project's OBR
> bundle as an example. First, we'll separate its version specification
> in the dependencyManagement section of the project's root POM:
>
> <properties>
> <felix.version>0.9.0-incubator-SNAPSHOT</felix.version>
> <!-- ... -->
> </properties>
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.apache.felix</groupId>
> <artifactId>org.apache.felix.bundlerepository</artifactId>
> <version>${felix.version}</version>
> </dependency>
> <!-- ... -->
> </dependencies>
> </dependencyManagement>
>
> Then, in one of our own bundles that relies upon the Felix OBR bundle,
> we refer to it like this from a module-level POM:
>
> <dependencies>
> <dependency>
> <groupId>org.apache.felix</groupId>
> <artifactId>org.apache.felix.bundlerepository</artifactId>
> <scope>provided</scope>
> </dependency>
> <!-- ... -->
> </dependencies>
>
> That allows the code in /our/ bundle (or any other Java artifact)
> under development to refer to the classes in the Felix OBR bundle at
> compile-time.
I'll go off and digest that, thanks!
> (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).
>
> Now here I wonder if you're asking about how to build a bundle
> yourself, or possibly how to extract some classes from another
> bundle's JAR and have them packaged into your own artifact. If so,
> those operations are taken care of by declaring your artifact to be of
> packaging type "bundle":
Nope, just want to use a bundle as a dependency for now, but at some point
in the future, I will be needing to create OSGi bundles as build artifacts,
so I'll need to digest this as well.
<packaging>bundle</packaging>
>
> and configuring the maven-bundle-plugin¹:
>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> <!-- Export-Package, Private-Package, ... -->
> </instructions>
> </configuration>
> </plugin>
> </plugins>
> </build>
>
> > 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 ;-)
>
> There is some ongoing work in the other direction: tying the OSGi
> Bundle Repository together with Maven's repository, so the one could
> use OBR to install bundles that reside in a Maven repository. Perhaps
> if you could clarify what you'd like to achieve, we could point you
> toward existing solutions or at least some work underway.
My need right now is to use OSGi bundles as dependencies, but at some point,
we're going to be turning our own build artifacts into bundles as well.
Before I get to defining specific requirements, though, I'm going to need to
get a better understanding of OSGi in general. What project am I looking
for when I'm ready for that then?
Thanks much for the help!
Cheers,
Craig
Footnotes:
> ¹ http://cwiki.apache.org/FELIX/bundle-plugin-for-maven-bnd.html
> which sits atop
> http://www.aqute.biz/Code/Bnd
>
> --
> Steven E. Harris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: OSGi bundles as dependencies
Posted by "Steven E. Harris" <se...@panix.com>.
Craig Ching <cr...@gmail.com> writes:
> 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
Maybe I misunderstood your question. If you have an OSGi bundle
packaged as a JAR that you'd like to depend on, you can specify its
Maven coordinates as follows. Let's take the Felix project's OBR
bundle as an example. First, we'll separate its version specification
in the dependencyManagement section of the project's root POM:
<properties>
<felix.version>0.9.0-incubator-SNAPSHOT</felix.version>
<!-- ... -->
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.bundlerepository</artifactId>
<version>${felix.version}</version>
</dependency>
<!-- ... -->
</dependencies>
</dependencyManagement>
Then, in one of our own bundles that relies upon the Felix OBR bundle,
we refer to it like this from a module-level POM:
<dependencies>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.bundlerepository</artifactId>
<scope>provided</scope>
</dependency>
<!-- ... -->
</dependencies>
That allows the code in /our/ bundle (or any other Java artifact)
under development to refer to the classes in the Felix OBR bundle at
compile-time.
> (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).
Now here I wonder if you're asking about how to build a bundle
yourself, or possibly how to extract some classes from another
bundle's JAR and have them packaged into your own artifact. If so,
those operations are taken care of by declaring your artifact to be of
packaging type "bundle":
<packaging>bundle</packaging>
and configuring the maven-bundle-plugin¹:
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<!-- Export-Package, Private-Package, ... -->
</instructions>
</configuration>
</plugin>
</plugins>
</build>
> 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 ;-)
There is some ongoing work in the other direction: tying the OSGi
Bundle Repository together with Maven's repository, so the one could
use OBR to install bundles that reside in a Maven repository. Perhaps
if you could clarify what you'd like to achieve, we could point you
toward existing solutions or at least some work underway.
Footnotes:
¹ http://cwiki.apache.org/FELIX/bundle-plugin-for-maven-bnd.html
which sits atop
http://www.aqute.biz/Code/Bnd
--
Steven E. Harris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: OSGi bundles as dependencies
Posted by Craig Ching <cr...@gmail.com>.
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 <se...@panix.com> wrote:
>
> Craig Ching <cr...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: OSGi bundles as dependencies
Posted by "Steven E. Harris" <se...@panix.com>.
Craig Ching <cr...@gmail.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org