Only dependencies that are of type bundle. Plain old jars would be added to the classpath. I guess it doesn't have to be the default behavior - just possible.
As a side note. You create bundles that are dependent on other bundles (to compile, I assume) but then you don't want them to be required during runtime? -Aaron -----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 05, 2006 1:56 PM To: felix-dev@incubator.apache.org Subject: Re: Bundle plugin: Importing packages from non-bundles Aaron Siri wrote: > I guess I'm expecting it to behave a little more like the war-plugin > with respect to dependency jars. Any dependency that is of type jar > and has a scope of something like compile will be included in the > bundle jar (and on the manifest classpath). For that matter, any > dependency that is of type bundle I'd expect to be included in the manifest Required-Bundles property. > Well, I definitely would not want the default handling of dependencies to be converted to require-bundle... -> richard > -Aaron > > -----Original Message----- > From: Peter Kriens [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 05, 2006 12:46 PM > To: Aaron Siri > Cc: felix-dev@incubator.apache.org > Subject: Re[6]: Bundle plugin: Importing packages from non-bundles > > Sorry for the previous mail, was not finished yet. > > I think it is : > > <configuration> > <instructions> > <Include-Resource>plugin.xml</Include-Resource> > </instructions> > </configuration> > > And not > > <configuration> > <Include-Resource>plugin.xml</Include-Resource> > </configuration> > > You can always package the bundles as jars, you just have to Include > them as resources. However, this implies you know where to find them. > > Please realize that the plugin was build for the OSGi model where you > have many small bundles. This implies that not all scenarios are > targeted with this plugin. > > Kind regards, > > Peter Kriens > > > AS> I was going to start asking similar questions. I'm wondering how > AS> I get my dependencies packaged in the bundle (I prefer them as > AS> jars and not inlined.) Does this thread imply that there is no way > AS> for library jars to be packaged in the bundle using maven-bundle-plugin? > > AS> I'm also trying to get the plugin.xml file included into the bundle via: > > AS> <configuration> > AS> <Include-Resource>plugin.xml</Include-Resource> > AS> </configuration> > > AS> Which doesn't seem to be working. Is this the right way to get it > included? > > AS> -Aaron > > AS> -----Original Message----- > AS> From: Emil Eifrém [mailto:[EMAIL PROTECTED] > AS> Sent: Tuesday, December 05, 2006 10:10 AM > AS> To: Peter Kriens > AS> Cc: felix-dev@incubator.apache.org > AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from > AS> non-bundles > > AS> On 12/5/06, Peter Kriens <[EMAIL PROTECTED]> wrote: > >>> I am not a maven expert so maybe there are better ways to do it. >>> >>> I never understood "provided" to mean include? If that is the >>> definition I can automatically include them. Can someone point me to >>> the relevant literature? >>> > > AS> Neither am I, but it actually means exclude. From > AS> http://maven.apache.org/pom.html: > > --- >>8 --- > AS> * scope: This element refers to the classpath of the task at hand > AS> (compiling and runtime, testing, etc.) as well as how to limit the > AS> transitivity of a depedency. There are five scopes available: > AS> * compile - this is the default scope, used if none is specified. > AS> Compile dependencies are available in all classpaths. > AS> * provided - this is much like compile, but indicates you > AS> expect the JDK or a container to provide it. It is only available > AS> on the compilation classpath, and is not transitive. > AS> * runtime - this scope indicates that the dependency is not > AS> required for compilation, but is for execution. It is in the > AS> runtime and test classpaths, but not the compile classpath. > AS> * test - this scope indicates that the dependency is not > AS> required for normal use of the application, and is only available > AS> for the test compilation and execution phases. > AS> * system - this scope is similar to provided except that you > AS> have to provide the JAR which contains it explicitly. The artifact > AS> is always available and is not looked up in a repository. > --- >>8 --- > > >>> The <type>bundle</type> is required by maven as far as I know, as is >>> the messy plugin setup. If you know a better way let me know. >>> > > AS> Unfortunately, I'm even less of an expert on Maven than I am on OSGi. > AS> I just want stuff to work so I can build apps. :) But this is an > AS> Apache list, I'm sure others can chime in! > > AS> What I meant in my previous mail was that I don't understand why > AS> the plugin needs to know the <type> of the dependencies. It's an > AS> OSGi-aware > plugin... > AS> just have a peek in the jar file and figure it out? If it is, then > AS> generate Import-Package, if not then embed or inline it. Would > AS> work nicely. But maybe there's some Maven core <-> Maven plugin > AS> interaction going on there that I'm missing. In either case, this > AS> would be nice-to-have functionality but it's not a showstopper for us. > > AS> [snip] > >>> Inlining or Bundle-Classpath both make no difference for the >>> Import-Package. The import header is calculated from the references >>> from all the classes on the Bundle-Classpath. >>> > > AS> Here's where I don't get it. Let's go back to the simple original > AS> example with my one-class bundle which depended on commons-logging. > AS> If the plugin would embed or inline the commons-logging jar AND > AS> generate Import-Package statements... that would break when we > AS> load it into the OSGi framework, right? No other bundle will > AS> export commons-logging stuff and, moreover, even if there is I > AS> want my bundle to > use the embedded stuff like I said in my POM. > AS> This is the core of the issue, as I see it. > > AS> Cheers, > > AS> -EE > > >
