RH> You simply indicate which packages you want in your bundle and they are copied into it.
Huh?! So, if I write a bundle that uses the dom4j API (it is a <dependency/> in my bundle's POM) this plugin won't simply bundle dom4j.jar and add a reference to it to Bundle-ClassPath? Instead, I have to know what all of the packages are in dom4j.jar and explicitly *indicate* that they should be *copied* into the bundle so that they are available at runtime? Is that correct? I want to make sure I understand this correctly. -Aaron -----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 05, 2006 2:45 PM To: felix-dev@incubator.apache.org Subject: Re: Bundle plugin: Importing packages from non-bundles Aaron Siri wrote: > Understood. A switch or option would be nice then. My Import-Package > property is huge and always looks like a mess. > If it is calculated, then it shouldn't be something to worry about...I am sure the byte code in my class files looks like a mess too. ;-) > Still wondering about jar dependencies and auto-generation of > Bundle-ClassPath (and packaging). The older maven-osgi-plugin > supported this. > Yes, the new plugin promotes a different approach to creating bundles. You simply indicate which packages you want in your bundle and they are copied into it. Do you have the need for actually embedding JAR files into your bundle or is your desire to simply have some way to automatically embedded your dependencies (inlined or as JAR files) into your bundle? -> richard > -Aaron > > -----Original Message----- > From: Richard S. Hall [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 05, 2006 2:09 PM > To: felix-dev@incubator.apache.org > Subject: Re: Bundle plugin: Importing packages from non-bundles > > Aaron Siri wrote: > >> 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? >> >> > > The issue is Import-Package vs. Require-Bundle. I prefer > Import-Package over Require-Bundle for my dependencies. > > -> richard > > >> -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 >>> AS> how I get my dependencies packaged in the bundle (I prefer them >>> AS> as jars and not inlined.) Does this thread imply that there is >>> AS> no way 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 >>> AS> 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 >>> AS> 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 >>> AS> hand (compiling and runtime, testing, etc.) as well as how to >>> AS> limit the 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 >>> AS> available 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 >>> AS> available 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 >>> AS> artifact 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, >>> AS> then generate Import-Package, if not then embed or inline it. >>> AS> Would work nicely. But maybe there's some Maven core <-> Maven >>> AS> plugin interaction going on there that I'm missing. In either >>> AS> case, this 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 >>> AS> original 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 >>> >>> >>> >>> >>>
