On Mar 13, 2009, at 9:43 AM, Rick McGuire wrote:
David Jencks wrote:
I read the blog entry and discussion. The entire discussion is
predicated on the idea that osgi is close to ideal as-is and we
have no need to consider any other point of view. If you step back
a bit I see two things clearly acknowledged by everyone:
1. its useful to be able to know what classes are needed to make a
jar/bundle/plugin/module work and which classes are expected to be
used elsewhere
2. its essential to know what jars/bundles/plugins/modules are
actually in your running system
In osgi-land, import-package and export-package supply (1), and
require-bundle sort of helps with (2) but AFAICT right now doesn't
support "artifact aliasing"
In maven-land, the pom dependency tracking provides a pretty good
solution for (2), including some support for overriding
"requirements" through exclusions, but it's single-classloader
model doesn't translate directly into an app server or osgi runtime
In geronimo trunk we emphasize (2) and can actually assemble
working servers using it, and have support for (1) (although its
mostly backwards from osgi specifications)
I'd say that in my (limited) experience osgi zealots typically
think that (1) is essential and brush (2) under the carpet by
working in constrained environments such as their eclipse
workspace. I'd say that our experience with geronimo is that (1)
is rarely needed if you have a working (2) (look at how many hidden-
classes and non-overriable classes filters are in our poms -- none
for the use of geronimo, and a few to make deploying applications
that include the same jars as us work)
The geronimo/maven approach to (2) is to include the dependency
information with the artifact. I'm not sure what approach(es) osgi
is considering -- OBR appears to not consider bundling dependency
info with the artifact but to have a completely external
specification. I don't know about p2.... but since jason vanZyl
seems to be looking at it I'd guess it is more maven friendly.
If you don't bundle (2) with the artifacts then you need some kind
of import-package to artifact map or resolution system. We sort of
have some vestiges of this today: when you deploy a web app as a
geronimo plugin (or export it from a server where it was deployed)
it has picked up dependencies on jetty or tomcat based on which
deployer you specified in the plugin project pom or which kind of
server you deployed on. Another example is that the car-maven-
plugin filters the view of the local maven repo so only the
versions specified in the pom are visible to the geronimo server we
run off the repo -- this allows you to build plugins for a 2.1.3
server even if you have 2.2-SNAPSHOT artifacts locally and some of
the dependencies don't specify the version required.
I don't know where the best balance for geronimo lies here. I
certainly think claiming all we need is import-package is
shortchanging most of our experience in producing geronimo as a
working server.
But on the other hand, I'd hate to have not using just Import-
package as the starting point. Given how much it is assumed in the
OSGi world, it would be best to assume its use and only step outside
of that box once we've found the intractable problem that requires
it. Starting outside of those limits means we're abandoning the
things OSGi does straight off because their may be some places where
the exception mechanisms are required.
Aren't you exhibiting exactly the same attitude as the blog posters in
saying the (2) is not really a problem we need to consider? Whereas
all our work in getting geronimo to actually work has been focussed on
solving (2). If we ditch our working system for (2) we won't have a
server.... perhaps ever. In terms of assembling a server, without (2)
the space of possible bundles to resolve to is the entire maven
central repo. ( I anticipate that any working server is going to be
able to convert plain jars to bundles on the fly. If not, no one who
is not osgi-obsessed will be willing to use it)
At the moment I'm inclined to think that require-bundle is not a
workable solution for (2) and so we might as well use import-package
plus an osgi runtime that uses and requires explicit external
dependency information such as provided by maven or geronimo-
plugin.xml to choose what bundle to resolve to. However until we get
something working we won't know much about whether this or any
proposal is a good or workable choice.
I'm still waiting for news of a working osgi system that is comparable
in scale to eclipse that primarily uses import-package.
thanks
david jencks
Rick
thanks
david jencks
On Mar 13, 2009, at 7:10 AM, Lin Sun wrote:
I think I was not too clear below. I didn't mean to say that I am
in
favor of Require-Bundle because it is a lot harder to come up with
the
right Import-Package lists. What I meant was that the reason why a
lot of people are using Require-Bundle like David mentioned in his
early notes is probably because it is a lot easier to use.
I personally had to spend quite some time to figure out the prob I
mentioned earlier - I was developing a bundle that needs to import
the javax.transaction package from the transaction in OSGi bundle,
but
two bundles have it (the basic OSGi J2SE and the transaction in OSGi
bundle). I was able to resolve this using Import-Package with the
specific version of javax.transaction package that I need. I just
tried to switch to use Require-Bundle, that is to have my bundle to
depend on the transaction in OSGi bundle as it contains the right
version of the javax.transaction package I need, but my bundle is
broken completely due to CDNFE. I don't think the Require-Bundle
offers the fine grain control that I needed for my bundle and I am
sure Geronimo would have a lot more complicated bundles than what I
was developing.
BTW, there's a good discussion here:
http://thhal.blogspot.com/2008/02/dependencies-and-package-imports.html
- in particular in the first comment from Neil Bartlett and the
limitations of Require-Bundle documented in the OSGi v 4.1 core spec
(section 3.13.3).
Lin
On Thu, Mar 12, 2009 at 11:40 PM, Lin Sun <[email protected]>
wrote:
Not sure about Require-Bundle. I personally has never used it
and I
never see it is being used in the OSGi repo. Require-Bundle may
not
offer the level of control that the Import-Package provides but
it is
probably a lot harder to come up with the right Import-Package
lists.
I think this scenario should work just fine if using Import-
Package.
