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 22:29:54 GMT
On Dec 5, 2006, at 5:15 PM, Aaron Siri wrote:

> In your example, if I'm not mistaken, you are taking binaries from one 
> bundle
> and including them in your own bundle (instead of depending on the 
> bundle at
> runtime).  Now this seems anti-OSGi :)

Not at all anti-OSGi...the OSGi framework automatically deals with 
multiple providers of the same package (in my example the Log Service 
exports the log package). The spec used to recommend packaging a bundle 
with its interfaces...I am not sure if it still does or not, but it is 
definitely not anti-OSGi.

To me, using Require-Bundle for dependencies is the anti-OSGi thing to 
do, but that is a whole other debate.

> You don't seem to be using the bundle as a bundle, but rather as a 
> simple,
> but very big, third party library (i.e. bunch of class files.) Yeah - 
> it's
> self contained, but doesn't really take advantage of the modular 
> nature of
> the OSGi infrastructure.  However, I don't know the details of the 
> bundles
> you are talking about and assume there are good reasons for doing it 
> the way
> you are.

Nowhere did I say that you should do this for every dependency you 
have, but only for the ones that it makes sense. For the rest, you let 
the plugin generate Import-Package declarations and it is all 
automatic.

> But, the case you made seems to only really make sense for poorly 
> designed
> bundles (as this compendium bundle seems to be - including a logging 
> API that
> can't be separated from the rest)  I'd hope the maven plugin is 
> designed with
> such a situation as the exception instead of the rule.  Either you 
> depend on
> compendium or you don't.  In your case the answer is "Sort of.  I drag 
> what I
> need into my own bundle."
>
> I'm trying to target the 80% that are using the plugin like they use 
> all
> other maven plugins.  Via the POM I've expressed what the dependencies 
> are
> and if I want them in the artifact.  That should be enough to get them
> bundled.  I can then fine tune visibility via the plugin's 
> instructions.

If that is your definition of poorly designed, then I guess nearly all 
JAR files are poorly designed judging by the amount of stuff that gets 
downloaded by Maven for any simple operation. Pulling in 20MB of stuff 
to compile a "hello world" program does scream "poor design", but it is 
not the "hello world" program that is poorly designed.

Rarely any JAR file is perfectly cohesive and as a result dependencies 
on a JAR file are generally going to pull in too much.


> As a start, I'd suggest that a <Bundle-ClassPath> instruction is 
> added.  You
> can specify "<none>" (do what it does today), or actual packages/jars. 
>  If it
> isn't specified at all then the dependencies are added to the
> Bundle-ClassPath manifest entry.  Whether or not the .jars are actually
> packaged in the bundle would be determined by how the dependencies were
> defined.  I'm shooting from the hip here but it could be a start.  The
> interplay with Export-Package and Private-Package would have to be 
> addressed.

Yes, I think we can look into it.

-> richard

>
> -Aaron
>
> -----Original Message-----
> From: Richard S. Hall [mailto:heavy@ungoverned.org]
> Sent: Tuesday, December 05, 2006 4:13 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundle plugin: Importing packages from non-bundles
>
> Aaron Siri wrote:
>> Sorry - thought it was implied.  Since this is a maven plugin I'd want
>> the process automated (with reasonable overrides.) :)
>>
>> Again - like the war-plugin, osgi-plugin (and most other packaging
>> maving plugins that I am familiar with) jar dependencies (with the
>> compile scope) are automatically added to the artifact (in this case,
>> a bundle) as-is and made available to the runtime (in this case added
>> to Bundle-ClassPath.) Specifying where in the bundle the jars should
>> go (i.e. META-INF/lib, lib,
>> etc.) would be a bonus.
>>
>
> I still feel like my question wasn't totally answered. I understand 
> that you
> want the process automated; we all do, which is why we have a plugin. 
> What I
> don't understand is whether it is a requirement that you want the JAR 
> file
> embedded or if inlining of the JAR is acceptable.
>
> I am asking this question to get a better understanding of how 
> possibly to
> devise a solution.
>
>> With all due respect, having to specify the <Private-Package/>
>> instruction to pull in dependencies seems a little goofy and
>> anti-maven.  Via the POM I already specified the dependencies and if
>> they need to be part of the artifact.  Finer-grained visibility
>> control can then be done via the Export-Package instruction.
>>
>
> If you consider it anti-Maven, then maybe it is, I don't know. Maven 
> doesn't
> really work exactly like I would like it to.
>
> For example, we have a very simple Log Service implementation in Felix.
> The actually Log Service interface package is in the compendium bundle.
> This means that the Log Service bundle has a dependency on the 
> compendium
> bundle. If I follow the "pro-Maven" approach, then to use this very
> lightweight log service I have to download the fairly large compendium 
> bundle
> and the servlet bundle, since compendium has a dependency on that.
>
> I don't know of any real "pro-Maven" approach for eliminating this 
> situation
> other than copying the Log Service package source code from the 
> compendium
> project into my Log Service project. The downside of this approach is 
> that I
> now have to maintain two copies of the source code.
>
> With the maven-bundle-plugin, I can simply include the package I need 
> from
> the compendium dependency and now I have a completely self-contained,
> lightweight Log Service bundle.
>
> This approach may not suit every purpose, but it definitely comes in 
> handy if
> you ask me.
>
> I can see the other side to the argument too, so we just have to think 
> up a
> good solution for both, I think.
>
> -> richard
>
>> -Aaron
>>
>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Tuesday, December 05, 2006 3:26 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>
>> Aaron Siri wrote:
>>
>>> RH> You simply indicate which packages you want in your bundle and
>>> RH> they are
>>> copied into it.
>>>
>>> Huh?!  So, if I write a bundle that uses the dom4j API (it is a
>>> <dependency/> in my bundle's POM) this plugin won't simply bundle
>>> dom4j.jar and add a reference to it to Bundle-ClassPath?  Instead, I
>>> have to know what all of the packages are in dom4j.jar and explicitly
>>> *indicate* that they should be
>>> *copied* into the bundle so that they are available at runtime?  Is
>>> that correct?  I want to make sure I understand this correctly.
>>>
>>>
>>
>> Yes, you understand. Often the only thing that is required is
>> something
>> like:
>>
>>     <Private-Package>org.dom4j.*</Private-Package>
>>
>> But you didn't answer my question, are you interested in having
>> embedded JAR files (as opposed to inlined JAR files) or interested in
>> simply automating the above process?
>>
>> -> richard
>>
>>
>>> -Aaron
>>>
>>> -----Original Message-----
>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>> Sent: Tuesday, December 05, 2006 2:45 PM
>>> To: felix-dev@incubator.apache.org
>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>
>>> Aaron Siri wrote:
>>>
>>>
>>>> Understood.  A switch or option would be nice then.  My
>>>> Import-Package property is huge and always looks like a mess.
>>>>
>>>>
>>>>
>>> If it is calculated, then it shouldn't be something to worry
>>> about...I am sure the byte code in my class files looks like a mess
>>> too. ;-)
>>>
>>>
>>>
>>>> Still wondering about jar dependencies and auto-generation of
>>>> Bundle-ClassPath (and packaging).  The older maven-osgi-plugin
>>>> supported this.
>>>>
>>>>
>>>>
>>> Yes, the new plugin promotes a different approach to creating 
>>> bundles.
>>> You simply indicate which packages you want in your bundle and they
>>> are copied into it.
>>>
>>> Do you have the need for actually embedding JAR files into your
>>> bundle or is your desire to simply have some way to automatically
>>> embedded your dependencies (inlined or as JAR files) into your 
>>> bundle?
>>>
>>> -> richard
>>>
>>>
>>>
>>>
>>>
>>>> -Aaron
>>>>
>>>> -----Original Message-----
>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>> Sent: Tuesday, December 05, 2006 2:09 PM
>>>> To: felix-dev@incubator.apache.org
>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>
>>>> Aaron Siri wrote:
>>>>
>>>>
>>>>
>>>>> Only dependencies that are of type bundle.  Plain old jars would be
>>>>> added to the classpath.  I guess it doesn't have to be the default
>>>>> behavior - just possible.
>>>>>
>>>>> As a side note.  You create bundles that are dependent on other
>>>>> bundles (to compile, I assume) but then you don't want them to be
>>>>> required during runtime?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> The issue is Import-Package vs. Require-Bundle. I prefer
>>>> Import-Package over Require-Bundle for my dependencies.
>>>>
>>>> -> richard
>>>>
>>>>
>>>>
>>>>
>>>>> -Aaron
>>>>>
>>>>> -----Original Message-----
>>>>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>>>>> Sent: Tuesday, December 05, 2006 1:56 PM
>>>>> To: felix-dev@incubator.apache.org
>>>>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>>>>>
>>>>> Aaron Siri wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> I guess I'm expecting it to behave a little more like the
>>>>>> war-plugin with respect to dependency jars.  Any dependency that
>>>>>> is of type jar and has a scope of something like compile will be
>>>>>> included in the bundle jar (and on the manifest classpath).  For
>>>>>> that matter, any dependency that is of type bundle I'd expect to
>>>>>> be included in the manifest
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Required-Bundles property.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Well, I definitely would not want the default handling of
>>>>> dependencies to be converted to require-bundle...
>>>>>
>>>>> -> richard
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -Aaron
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
>>>>>> Sent: Tuesday, December 05, 2006 12:46 PM
>>>>>> To: Aaron Siri
>>>>>> Cc: felix-dev@incubator.apache.org
>>>>>> Subject: Re[6]: Bundle plugin: Importing packages from non-bundles
>>>>>>
>>>>>> Sorry for the previous mail, was not finished yet.
>>>>>>
>>>>>> I think it is :
>>>>>>
>>>>>>  <configuration>
>>>>>>       <instructions>
>>>>>>          <Include-Resource>plugin.xml</Include-Resource>
>>>>>>       </instructions>
>>>>>>  </configuration>
>>>>>>
>>>>>> And not
>>>>>>
>>>>>>  <configuration>
>>>>>>          <Include-Resource>plugin.xml</Include-Resource>
>>>>>>  </configuration>
>>>>>>
>>>>>> You can always package the bundles as jars, you just have to
>>>>>> Include them as resources. However, this implies you know where to
>>>>>> find
>>>>>>
>> them.
>>
>>>>>> Please realize that the plugin was build for the OSGi model where
>>>>>> you have many small bundles. This implies that not all scenarios
>>>>>> are targeted with this plugin.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>>      Peter Kriens
>>>>>>
>>>>>>
>>>>>> AS> I was going to start asking similar questions.  I'm wondering
>>>>>> AS> how I get my dependencies packaged in the bundle (I prefer
>>>>>> AS> them as jars and not inlined.) Does this thread imply that
>>>>>> AS> there is no way for library jars to be packaged in the bundle
>>>>>> AS> using
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> maven-bundle-plugin?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> AS> I'm also trying to get the plugin.xml file included into the
>>>>>> AS> bundle
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> via:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> AS> <configuration>
>>>>>> AS>         <Include-Resource>plugin.xml</Include-Resource>
>>>>>> AS> </configuration>
>>>>>>
>>>>>> AS> Which doesn't seem to be working.  Is this the right way to
>>>>>> AS> get it
>>>>>> included?
>>>>>>
>>>>>> AS> -Aaron
>>>>>>
>>>>>> AS> -----Original Message-----
>>>>>> AS> From: Emil Eifrém [mailto:emil@eifrem.com]
>>>>>> AS> Sent: Tuesday, December 05, 2006 10:10 AM
>>>>>> AS> To: Peter Kriens
>>>>>> AS> Cc: felix-dev@incubator.apache.org
>>>>>> AS> Subject: Re: Re[4]: Bundle plugin: Importing packages from
>>>>>> AS> non-bundles
>>>>>>
>>>>>> AS> On 12/5/06, Peter Kriens <Peter.Kriens@aqute.biz> 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?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> AS> Neither am I, but it actually means exclude. From
>>>>>> AS> http://maven.apache.org/pom.html:
>>>>>>
>>>>>> --- >>8 ---
>>>>>> AS> * scope: This element refers to the classpath of the task
at
>>>>>> AS> hand (compiling and runtime, testing, etc.) as well as how
to
>>>>>> AS> limit the transitivity of a depedency. There are five scopes
>>>>>>
>>>>>>
>>> available:
>>>
>>>
>>>>>> AS>     * compile - this is the default scope, used if none is
>>>>>>
>> specified.
>>
>>>>>> AS> Compile dependencies are available in all classpaths.
>>>>>> AS>     * provided - this is much like compile, but indicates
you
>>>>>> AS> expect the JDK or a container to provide it. It is only
>>>>>> AS> available on the compilation classpath, and is not transitive.
>>>>>> AS>     * runtime - this scope indicates that the dependency is
>>>>>> AS> not required for compilation, but is for execution. It is
in
>>>>>> AS> the runtime and test classpaths, but not the compile 
>>>>>> classpath.
>>>>>> AS>     * test - this scope indicates that the dependency is not
>>>>>> AS> required for normal use of the application, and is only
>>>>>> AS> available for the test compilation and execution phases.
>>>>>> AS>     * system - this scope is similar to provided except that
>>>>>> AS> you have to provide the JAR which contains it explicitly.
The
>>>>>> AS> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> AS> Unfortunately, I'm even less of an expert on Maven than I
am
>>>>>> AS> on
>>>>>>
>> OSGi.
>>
>>>>>> AS> I just want stuff to work so I can build apps. :) But this
is
>>>>>> AS> an Apache list, I'm sure others can chime in!
>>>>>>
>>>>>> AS> What I meant in my previous mail was that I don't understand
>>>>>> AS> why the plugin needs to know the <type> of the dependencies.
>>>>>> AS> It's an OSGi-aware
>>>>>> plugin...
>>>>>> AS> just have a peek in the jar file and figure it out? If it
is,
>>>>>> AS> then generate Import-Package, if not then embed or inline
it.
>>>>>> AS> Would work nicely. But maybe there's some Maven core <->
Maven
>>>>>> AS> plugin interaction going on there that I'm missing. In either
>>>>>> AS> case, this would be nice-to-have functionality but it's not
a
>>>>>>
>>>>>>
>>>>>>
>>>> showstopper for us.
>>>>
>>>>
>>>>
>>>>>> AS> [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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> AS> Here's where I don't get it. Let's go back to the simple
>>>>>> AS> original example with my one-class bundle which depended on
>>>>>>
>>>>>>
>>> commons-logging.
>>>
>>>
>>>>>> AS> If the plugin would embed or inline the commons-logging jar
>>>>>> AS> AND generate Import-Package statements... that would break
>>>>>> AS> when we load it into the OSGi framework, right? No other
>>>>>> AS> bundle will export commons-logging stuff and, moreover, even
>>>>>> AS> if there is I want my bundle to
>>>>>> use the embedded stuff like I said in my POM.
>>>>>> AS> This is the core of the issue, as I see it.
>>>>>>
>>>>>> AS> Cheers,
>>>>>>
>>>>>> AS> -EE
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>


Mime
View raw message