That was it. Thanks for the help - don't know how I overlooked that. About the packaging... isn't that basic maven behavior. Shouldn't the maven plugin do *something* with the dependencies in the final package? Even if I had many small bundles I'm not going to want to write the code for everything. Even if I wanted a bundle that only provides xmlbeans support or something similar how would I bundle the xmlbeans jar into the bundle jar? Whether it is many small bundles with only one third-party, dependency-defined jar or one bundle with many third-party, dependency-defined jars I wouldn't think there is much difference.
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. -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 I AS> get my dependencies packaged in the bundle (I prefer them as jars AS> and not inlined.) Does this thread imply that there is no way for AS> 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 expect AS> the JDK or a container to provide it. It is only available on the AS> 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 runtime AS> 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 the AS> plugin needs to know the <type> of the dependencies. It's an 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 work AS> 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 load AS> it into the OSGi framework, right? No other bundle will export AS> commons-logging stuff and, moreover, even if there is I 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 -- Peter Kriens Tel +33467542167 9C, Avenue St. Drézéry AOL,Yahoo: pkriens 34160 Beaulieu, France ICQ 255570717 Skype pkriens Fax +1 8153772599
