I think it is:
<configuration>
<instructions>
AS> I was going to start asking similar questions. I'm wondering how I get my
AS> dependencies packaged in the bundle (I prefer them as jars and not inlined.)
AS> Does this thread imply that there is no way for library jars to be packaged
AS> 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 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 (compiling
AS> and runtime, testing, etc.) as well as how to limit the transitivity of a
AS> 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 the JDK
AS> or a container to provide it. It is only available on the compilation
AS> classpath, and is not transitive.
AS> * runtime - this scope indicates that the dependency is not required for
AS> compilation, but is for execution. It is in the runtime and test classpaths,
AS> but not the compile classpath.
AS> * test - this scope indicates that the dependency is not required for
AS> normal use of the application, and is only available for the test
compilation
AS> and execution phases.
AS> * system - this scope is similar to provided except that you have to
AS> provide the JAR which contains it explicitly. The artifact is always
AS> 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 Apache
list,
AS> I'm sure others can chime in!
AS> What I meant in my previous mail was that I don't understand why the plugin
AS> 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 generate
AS> Import-Package, if not then embed or inline it. Would work nicely. But maybe
AS> there's some Maven core <-> Maven plugin interaction going on there that I'm
AS> missing. In either case, this would be nice-to-have functionality but it's
AS> 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 example
AS> with my one-class bundle which depended on commons-logging. If the plugin
AS> would embed or inline the commons-logging jar AND generate Import-Package
AS> statements... that would break when we load it into the OSGi framework,
AS> right? No other bundle will export commons-logging stuff and, moreover, even
AS> 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
