I was going to start asking similar questions. I'm wondering how I get my
dependencies packaged in the bundle (I prefer them as jars and not inlined.)
Does this thread imply that there is no way for library jars to be packaged
in the bundle using maven-bundle-plugin?
I'm also trying to get the plugin.xml file included into the bundle via:
<configuration>
<Include-Resource>plugin.xml</Include-Resource>
</configuration>
Which doesn't seem to be working. Is this the right way to get it included?
-Aaron
-----Original Message-----
From: Emil Eifrém [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 05, 2006 10:10 AM
To: Peter Kriens
Cc: felix-dev@incubator.apache.org
Subject: Re: Re[4]: Bundle plugin: Importing packages from non-bundles
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?
Neither am I, but it actually means exclude. From
http://maven.apache.org/pom.html:
--- >8 ---
* scope: This element refers to the classpath of the task at hand (compiling
and runtime, testing, etc.) as well as how to limit the transitivity of a
depedency. There are five scopes available:
* compile - this is the default scope, used if none is specified.
Compile dependencies are available in all classpaths.
* provided - this is much like compile, but indicates you expect the JDK
or a container to provide it. It is only available on the compilation
classpath, and is not transitive.
* runtime - this scope indicates that the dependency is not required for
compilation, but is for execution. It is in the runtime and test classpaths,
but not the compile classpath.
* test - this scope indicates that the dependency is not required for
normal use of the application, and is only available for the test compilation
and execution phases.
* system - this scope is similar to provided except that you have to
provide the JAR which contains it explicitly. The 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.
Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
I just want stuff to work so I can build apps. :) But this is an Apache list,
I'm sure others can chime in!
What I meant in my previous mail was that I don't understand why the plugin
needs to know the <type> of the dependencies. It's an OSGi-aware plugin...
just have a peek in the jar file and figure it out? If it is, then generate
Import-Package, if not then embed or inline it. Would work nicely. But maybe
there's some Maven core <-> Maven plugin interaction going on there that I'm
missing. In either case, this would be nice-to-have functionality but it's
not a showstopper for us.
[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.
Here's where I don't get it. Let's go back to the simple original example
with my one-class bundle which depended on commons-logging. If the plugin
would embed or inline the commons-logging jar AND generate Import-Package
statements... that would break when we load it into the OSGi framework,
right? No other bundle will export commons-logging stuff and, moreover, even
if there is I want my bundle to use the embedded stuff like I said in my POM.
This is the core of the issue, as I see it.
Cheers,
-EE
