felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Siri" <Aaron.S...@efi.com>
Subject RE: Bundle plugin: Importing packages from non-bundles
Date Tue, 05 Dec 2006 23:39:28 GMT
"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."

No, it is the pom.xml that is poorly designed.

By poor design I meant that you needed only a little piece of compendium.
Little enough that taking compendium as a whole was wasteful.  You shouldn't
have to break apart jars (or bundles) to get the binaries you need.  Most
third-party jars DO NOT work like this.  If you use anything from apache,
ibm, Eclipse, etc. you usually need the .jar in full (and breaking it apart
to only pull pieces out can even be foolish.)

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

I'm not comfortable ripping apart jars that I didn't package and it is bad
form (if you don't like it then complain to the packager.)  No one I know
creates jar files by pulling apart other jar files, sticking the classes into
their own jar file along with their own binaries (even if they are more
"self-contained".)   

Anyways, Maven has nothing to do with any of this.  Maven only pulls what you
need (well - it pulls what you say you need.)  If you say your hello world
app depends on all of jakarta then that is what maven will pull down (only
once BTW, everything maven pulls is cached.)

I guess I just don't like how the Export-Package and Private-Package
instructions pull the required code into the bundle by ripping apart other
bundles/jars (honestly, I'm in awe that people find this acceptable.)  I'd
rather embed the clean jars (as is, not-unrolled), add them to the
Bundle-Classpath and then build Export-Package off of them.  Import-package
can be built off of the dependency bundles (probably what it is doing
already.)  <Private-Package> seems unnecessary.

The anti-OSGi statement was a little harsh.  I apologize if I offended.  OSGi
strikes me as promoting modularity and "self-contained" bundles, to me, seem
to contradict that.  But, I'm used to equinox and the eclipse environment
where bundles are very modular.

-Aaron

-----Original Message-----
From: Richard S. Hall [mailto:heavy@ungoverned.org] 
Sent: Tuesday, December 05, 2006 5:30 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles

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