Sorry - thought it was implied. Since this is a maven plugin I'd want the process automated (with reasonable overrides.) :)
Again - like the war-plugin, osgi-plugin (and most other packaging maving plugins that I am familiar with) jar dependencies (with the compile scope) are automatically added to the artifact (in this case, a bundle) as-is and made available to the runtime (in this case added to Bundle-ClassPath.) Specifying where in the bundle the jars should go (i.e. META-INF/lib, lib, etc.) would be a bonus. With all due respect, having to specify the <Private-Package/> instruction to pull in dependencies seems a little goofy and anti-maven. Via the POM I already specified the dependencies and if they need to be part of the artifact. Finer-grained visibility control can then be done via the Export-Package instruction. -Aaron -----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 05, 2006 3:26 PM To: felix-dev@incubator.apache.org Subject: Re: Bundle plugin: Importing packages from non-bundles Aaron Siri wrote: > RH> You simply indicate which packages you want in your bundle and > RH> 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. > Yes, you understand. Often the only thing that is required is something like: <Private-Package>org.dom4j.*</Private-Package> But you didn't answer my question, are you interested in having embedded JAR files (as opposed to inlined JAR files) or interested in simply automating the above process? -> richard > -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 >>>> AS> you 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 >>>> AS> an Apache list, I'm sure others can chime in! >>>> >>>> AS> What I meant in my previous mail was that I don't understand >>>> AS> why the plugin needs to know the <type> of the dependencies. >>>> AS> It's an 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 >>>> >>>> >>>> >>>> >>>> >>>>
