geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Whence the geronimo kernel?
Date Fri, 13 Mar 2009 16:37:26 GMT
"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_jencks@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.unc@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

Mime
View raw message