"I certainly think claiming all we need is import-package is shortchanging most of our experience in producing geronimo as a working server." << +1000
-- dims On Fri, Mar 13, 2009 at 12:27 PM, David Jencks <david_jen...@yahoo.com> 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. > > 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 <linsun....@gmail.com> 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. >>> > > -- Davanum Srinivas :: http://davanum.wordpress.com
