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
