You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Peter Kriens <Pe...@aQute.biz> on 2006/12/05 18:32:48 UTC
Re[6]: Bundle plugin: Importing packages from non-bundles
Hmmm. I think you mean to say that the <include-maven> instruction
would make you happy because then you have a choice?
So we only have to decide if the JAR is copied or inlined?
Kind regards,
Peter Kriens
JEC> On Tue, 2006-12-05 at 15:49 +0100, Peter Kriens 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?
JEC> Provided means that the jar is provided or available (somehow - like
JEC> another bundle in the felix framework) at runtime.
JEC> Although the maven doc says:
JEC> "provided - this is much like compile, but indicates you expect the JDK
JEC> or a container to provide it. It is only available on the compilation
JEC> classpath, and is not transitive."
JEC> <tangent not-the-main-point-I-want-to-make="but just thought of it">
JEC> Now this can't be right, if you think about it anything scoped as
JEC> provided would have to be available on maven's compilation, AND test AND
JEC> run classpaths as well. (How else could you test your project?)
JEC> </tangent>
JEC> The Problem I really wanted to point out ---->
JEC> When using the old OSGi plugin it was necessary to ALWAYS specify the
JEC> scope 'provided' for any dependency, (let's call it depx that were/are
JEC> bundles themselves and would be 'provided' at runtime) to prevent them
JEC> from being embedded into the bundle (bundleA) along with their 'compile'
JEC> scoped siblings.
JEC> Unfortunately there is a side effect to using the scope element to
JEC> determine the embedding of jars into the bundle.
JEC> With provided, Maven no longer tags the artifact (depx) as transitive to
JEC> bundleA, and thus other maven projects that now use the newly
JEC> built/artifact bundleA as a dependency have lost transitive 'sight' of
JEC> that depx. Oops!
JEC> So is it possible to allow compile and provided scoped dependencies to
JEC> be included or not included in the bundle? If so we can offer the
JEC> community an OSGi bundling plugin without sacrificing maven's transitive
JEC> dependency functionality.
JEC> cheers,
JEC> John
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Bundle plugin: Importing packages from non-bundles
Posted by "Richard S. Hall" <he...@ungoverned.org>.
John E. Conlon wrote:
> On Tue, 2006-12-05 at 18:32 +0100, Peter Kriens wrote:
>
>> Hmmm. I think you mean to say that the <include-maven> instruction
>> would make you happy because then you have a choice?
>>
> YES
>
>> So we only have to decide if the JAR is copied or inlined?
>>
> Did we determine if there is a performance hit with the copied versus
> the inlined?
>
There is a performance hit at installation time, since the embedded JAR
files need to be extracted. This also implies extra consumption of disk
space. Otherwise, there should be no additional run-time overhead, I
don't think...except for needing more open files.
-> richard
> cheers,
> John
>
>
>> Kind regards,
>>
>> Peter Kriens
>>
>>
>>
>> JEC> On Tue, 2006-12-05 at 15:49 +0100, Peter Kriens 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?
>>>>
>> JEC> Provided means that the jar is provided or available (somehow - like
>> JEC> another bundle in the felix framework) at runtime.
>>
>> JEC> Although the maven doc says:
>> JEC> "provided - this is much like compile, but indicates you expect the JDK
>> JEC> or a container to provide it. It is only available on the compilation
>> JEC> classpath, and is not transitive."
>>
>> JEC> <tangent not-the-main-point-I-want-to-make="but just thought of it">
>> JEC> Now this can't be right, if you think about it anything scoped as
>> JEC> provided would have to be available on maven's compilation, AND test AND
>> JEC> run classpaths as well. (How else could you test your project?)
>> JEC> </tangent>
>>
>> JEC> The Problem I really wanted to point out ---->
>> JEC> When using the old OSGi plugin it was necessary to ALWAYS specify the
>> JEC> scope 'provided' for any dependency, (let's call it depx that were/are
>> JEC> bundles themselves and would be 'provided' at runtime) to prevent them
>> JEC> from being embedded into the bundle (bundleA) along with their 'compile'
>> JEC> scoped siblings.
>>
>> JEC> Unfortunately there is a side effect to using the scope element to
>> JEC> determine the embedding of jars into the bundle.
>>
>> JEC> With provided, Maven no longer tags the artifact (depx) as transitive to
>> JEC> bundleA, and thus other maven projects that now use the newly
>> JEC> built/artifact bundleA as a dependency have lost transitive 'sight' of
>> JEC> that depx. Oops!
>>
>> JEC> So is it possible to allow compile and provided scoped dependencies to
>> JEC> be included or not included in the bundle? If so we can offer the
>> JEC> community an OSGi bundling plugin without sacrificing maven's transitive
>> JEC> dependency functionality.
>>
>>
>> JEC> cheers,
>> JEC> John
>>
>>
>>
>
>
Re: Re[6]: Bundle plugin: Importing packages from non-bundles
Posted by "John E. Conlon" <jc...@verticon.com>.
On Tue, 2006-12-05 at 18:32 +0100, Peter Kriens wrote:
> Hmmm. I think you mean to say that the <include-maven> instruction
> would make you happy because then you have a choice?
YES
>
> So we only have to decide if the JAR is copied or inlined?
Did we determine if there is a performance hit with the copied versus
the inlined?
cheers,
John
>
> Kind regards,
>
> Peter Kriens
>
>
>
> JEC> On Tue, 2006-12-05 at 15:49 +0100, Peter Kriens 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?
> JEC> Provided means that the jar is provided or available (somehow - like
> JEC> another bundle in the felix framework) at runtime.
>
> JEC> Although the maven doc says:
> JEC> "provided - this is much like compile, but indicates you expect the JDK
> JEC> or a container to provide it. It is only available on the compilation
> JEC> classpath, and is not transitive."
>
> JEC> <tangent not-the-main-point-I-want-to-make="but just thought of it">
> JEC> Now this can't be right, if you think about it anything scoped as
> JEC> provided would have to be available on maven's compilation, AND test AND
> JEC> run classpaths as well. (How else could you test your project?)
> JEC> </tangent>
>
> JEC> The Problem I really wanted to point out ---->
> JEC> When using the old OSGi plugin it was necessary to ALWAYS specify the
> JEC> scope 'provided' for any dependency, (let's call it depx that were/are
> JEC> bundles themselves and would be 'provided' at runtime) to prevent them
> JEC> from being embedded into the bundle (bundleA) along with their 'compile'
> JEC> scoped siblings.
>
> JEC> Unfortunately there is a side effect to using the scope element to
> JEC> determine the embedding of jars into the bundle.
>
> JEC> With provided, Maven no longer tags the artifact (depx) as transitive to
> JEC> bundleA, and thus other maven projects that now use the newly
> JEC> built/artifact bundleA as a dependency have lost transitive 'sight' of
> JEC> that depx. Oops!
>
> JEC> So is it possible to allow compile and provided scoped dependencies to
> JEC> be included or not included in the bundle? If so we can offer the
> JEC> community an OSGi bundling plugin without sacrificing maven's transitive
> JEC> dependency functionality.
>
>
> JEC> cheers,
> JEC> John
>
>