felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Bundle plugin: Importing packages from non-bundles
Date Tue, 05 Dec 2006 19:47:06 GMT
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
>>
>>
>>     
>
>   

Mime
View raw message