Using "provide" as the instruction to include the jar does seem rather
ad hoc looking at the semantics. I would actually assume the opposite
at first reading and treat it as a bundle that will be installed in
the runtime env.
Kind regards,
Peter Kriens
EE> 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?
EE> Neither am I, but it actually means exclude. From
EE> http://maven.apache.org/pom.html:
--- >>8 ---
EE> * scope: This element refers to the classpath of the task at hand
EE> (compiling and runtime, testing, etc.) as well as how to limit the
EE> transitivity of a depedency. There are five scopes available:
EE> * compile - this is the default scope, used if none is specified.
EE> Compile dependencies are available in all classpaths.
EE> * provided - this is much like compile, but indicates you expect
EE> the JDK or a container to provide it. It is only available on the
EE> compilation classpath, and is not transitive.
EE> * runtime - this scope indicates that the dependency is not
EE> required for compilation, but is for execution. It is in the runtime
EE> and test classpaths, but not the compile classpath.
EE> * test - this scope indicates that the dependency is not required
EE> for normal use of the application, and is only available for the test
EE> compilation and execution phases.
EE> * system - this scope is similar to provided except that you have
EE> to provide the JAR which contains it explicitly. The artifact is
EE> 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.
EE> Unfortunately, I'm even less of an expert on Maven than I am on OSGi.
EE> I just want stuff to work so I can build apps. :) But this is an
EE> Apache list, I'm sure others can chime in!
EE> What I meant in my previous mail was that I don't understand why the
EE> plugin needs to know the <type> of the dependencies. It's an
EE> OSGi-aware plugin... just have a peek in the jar file and figure it
EE> out? If it is, then generate Import-Package, if not then embed or
EE> inline it. Would work nicely. But maybe there's some Maven core <->
EE> Maven plugin interaction going on there that I'm missing. In either
EE> case, this would be nice-to-have functionality but it's not a
EE> showstopper for us.
EE> [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.
EE> Here's where I don't get it. Let's go back to the simple original
EE> example with my one-class bundle which depended on commons-logging. If
EE> the plugin would embed or inline the commons-logging jar AND generate
EE> Import-Package statements... that would break when we load it into the
EE> OSGi framework, right? No other bundle will export commons-logging
EE> stuff and, moreover, even if there is I want my bundle to use the
EE> embedded stuff like I said in my POM. This is the core of the issue,
EE> as I see it.
EE> Cheers,
EE> -EE
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
