Understood. A switch or option would be nice then. My Import-Package property is huge and always looks like a mess.
Still wondering about jar dependencies and auto-generation of Bundle-ClassPath (and packaging). The older maven-osgi-plugin supported this. -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 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 >> AS> 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 hand >> AS> (compiling and runtime, testing, etc.) as well as how to limit >> AS> 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 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 >> 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 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 >> >> >> >>
