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: Re[2]: Bundle plugin: Importing packages from non-bundles
Date Thu, 07 Dec 2006 19:07:53 GMT
I also care about what is being packaged in my bundle and via the pom *I'm*
making all my decisions - they aren't ad-hoc.  If I select an api/library to
use I usually accept it as a whole and don't start micromanaging it or pull
it apart (unless it starts to break, then all bets are off.)  I get the
impression here that some people think that maven is a form of voodoo and you
never know what it is doing or that it can't be trusted.  I always know
exactly what is going to be pulled and know when I should short-circuit the
dependency tree.  Why should *you* dictate what *I* can and can't trust?  We
are all professional coders here and can make our own decisions.

If you want to flatten and optimize the bundle then that is your prerogative,
but can't that be a separate step?  Right now the plugin doesn't even give
you an option, it forces one way of doing things.  We're just asking for more
options.  The auto Import/Export stuff is attractive which is why we don't
really want to abandon maven-bundle-plugin.  We just wish it let us choose
how jar dependencies are handled - either inline the classes and treat them
as your own code (what the plugin does now), or bundle them as is and add
them to Bundle-ClassPath (what some of us prefer.)  In both cases isn't the
bundle's integrity maintained via Export-Package?


-----Original Message-----
From: Peter Kriens [mailto:Peter.Kriens@aQute.biz] 
Sent: Thursday, December 07, 2006 10:24 AM
To: Henrik Larsson
Cc: felix-dev@incubator.apache.org
Subject: Re[2]: Bundle plugin: Importing packages from non-bundles

For me the difference between a bundle and a jar is arbitrary. I always try
to make my bundles work as jars.

I really think that the "simple" rules posted are too ad hoc and will
generate lots of problems. In my experience, the contents of your bundle need
to be designed and not some more or less arbitrary collection of jars and
packages, mostly decided by other people than me. If code gets into MY
bundle, I feel responsible and want to know exactly what the consequences
are. Leaving this up to chance and other people's ad hoc decisions seems a
tad to dangerous for me.

The plugin/bnd was designed to carve the bundle out of the classpath and then
analyze it so you can inspect the consequences.

Kind regards,

     Peter Kriens

HL> I'm a co-worker with Emil, so we share the same view on this (I hope ;)

HL> On 12/6/06, Aaron Siri <Aaron.Siri@efi.com> wrote:
>> After our discussion I decided to go back and give the old plugin a 
>> try.  It is definitely buggy.  It seems to randomly add packages to 
>> Import-Package no matter where they come from (plain old jars or 
>> bundles.)  Maybe it is just me but I can't make any sense in what it is
>> I think Emil (correct me if I'm wrong) and I would both like to see 
>> only packages from bundle dependencies added to Import-Package, not 
>> stuff from embedded plain old jars (which should instead be added to 
>> the classpath.) The new plugin's behavior for this is nice, as long 
>> as it only looks at bundle dependencies and not jar dependencies.  I 
>> think Emil is then saying that if both a bundle and a plain old jar 
>> provide a package then don't put it on Import-Package (i.e. let it 
>> resolve to the plain old jar via the
>> classpath.)  The embedded plain old jars should override bundles 
>> (maybe OSGi spec already dictates this.)

HL> Yes, this is exactly the kind of behavior we are looking for.

HL> It would be nice if everything could be bundles, but as that is not 
HL> the case we want to be able to embed plain old jars in our bundles 
HL> (preferably not inlined, but that's not a major point). Then 
HL> Import-Package should *only* contain packages that are exported by 
HL> other bundles, not packages used from plain old jars that are in the 
HL> Bundle-Classpath.

>> The Bundle-Classpath entry from the old plugin looks good though.
>> So, is anybody invited to work on the plugins?
>> -Aaron
>> P.S. I want to thank Richard and Peter for putting up with all of my 
>> questions/complaints.  I'm learning a lot in this newsgroup.

HL> Yes, thanks Richard and Peter. We very much appreciate your prompt 
HL> and elaborate replies.

>> -----Original Message-----
>> From: Richard S. Hall [mailto:heavy@ungoverned.org]
>> Sent: Wednesday, December 06, 2006 2:25 PM
>> To: felix-dev@incubator.apache.org
>> Subject: Re: Bundle plugin: Importing packages from non-bundles
>> Emil Eifrém wrote:
>> > On 12/6/06, Peter Kriens <Peter.Kriens@aqute.biz> wrote:
>> >> How can it NOT generate Import-Package for bundles that are on the 
>> >> Bundle-Classpath?
>> >
>> > Maybe this is a typo, but maybe it's important. I'm not going to 
>> > have any *bundles* on the Bundle-Classpath, I'm going to have plain
>> > (See my commons-logging example.) Does this make a difference?
>> >
>> >> This means you have unresolved dependencies in your code, which 
>> >> can give you very nasty problems during deployment and running the
>> >> That is like putting out class files that have compile errors.
>> >
>> > Hmm, then I'm mistaken about some OSGi fundamentals. I thought the 
>> > framework matched my bundle's Import-Packages to other bundles 
>> > Export-Packages. In this case, I don't want the framework to find a 
>> > bundle that provides the package since the package is provided by 
>> > the (plain, non-bundle) embedded jar on the Bundle-Classpath. 
>> > That's why I thought the plugin shouldn't add the package to the 
>> > Import-Package statement.
>> >
>> > Is this an incorrect understanding of how OSGi works?
>> Your understanding of OSGi is correct.
>> I think there is a misunderstanding about what you are describing.
>> You are saying that you don't want imports generated for the same 
>> packages contained inside of embedded JAR files on your bundle class 
>> path, correct? I think Peter thought you meant that you didn't want 
>> to generate imports for the packages required by the packages in your 
>> embedded JAR files. You want the latter, but not the former...you 
>> indicate that the former is probably a bug in the old plugin. Correct?
>> -> richard

Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599

View raw message