Aaron Siri wrote:
Very reasonable. Part of this is me making sure I'm not assuming anything
fundamentally wrong. Some of the discussion seems to be of the "yes we could
do it that way but why?" nature and I wanted to convince myself that what is
being asked for/suggested isn't unreasonable.
I don't think there is anything fundamentally wrong, just different
perspectives. Some people come from a Maven-like world and want to apply
those concepts to OSGi. Others come from an OSGi world and want to apply
those concepts to Maven. We can try to bridge those gaps.
-> richard
I anxiously await the proposal. :)
-Aaron
-----Original Message-----
From: Richard S. Hall [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 07, 2006 2:17 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundle plugin: Importing packages from non-bundles
Aaron Siri wrote:
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.
I think the issue here is that Peter is not coming from a Maven perspective,
since he doesn't use Maven.
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?
As I stated a few times before, I think it is possible to come up with a
solution, but we need the time to think about it and discuss it.
When Peter gets back from traveling, he and I will try to discuss some
approaches to dealing with this issue and we will post a proposal to the list
for discussion. Sound reasonable?
-> richard
-Aaron
-----Original Message-----
From: Peter Kriens [mailto:[EMAIL PROTECTED]
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
HL> hope ;)
).
HL> On 12/6/06, Aaron Siri <[EMAIL PROTECTED]> 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
doing.
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
HL> not the case we want to be able to embed plain old jars in our
HL> bundles (preferably not inlined, but that's not a major point).
HL> Then Import-Package should *only* contain packages that are
HL> exported by other bundles, not packages used from plain old jars
HL> that are in the 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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
jars.
(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
code.
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
