Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=YB0VsTXhaTt8sIFfGqk3Krtl5Mq/dHUDoLOccMUyRvmNjGdLVo/TQ0Pu60wll9ERH54zNe9vkrwzI9Z/zFjP8McLU1hCJIMa/i2+N9jSQhsyX3kMbxuClr4pvATxnAcYeVV7G20A2d0CJ5EgLYwfVMRC2+OhyebvdD9NDvfo6TE=
  ;
Message-Id: <7B41B331-08B7-4944-8550-32775ACC848E@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: dev@geronimo.apache.org
In-Reply-To: <add18bc80903130710h2df3bb69p853cb5a9281dfb7@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Whence the geronimo kernel?
Date: Fri, 13 Mar 2009 09:27:33 -0700
References: <ED9C8D11-4250-41EF-ACFA-426F0D1B176E@yahoo.com>
 <76B612C4-8F1C-4432-A57F-23727674307D@yahoo.com>
 <CC12641D-408D-4B2E-82AF-1AE896C08001@optusnet.com.au>
 <b23ecedc0903110111q502ae153qd6224e9e6deea815@mail.gmail.com>
 <FEB191A1-3932-40D6-B4DA-58845F36F88C@optusnet.com.au>
 <BDF961F1-082E-4573-92BB-C407612CDAE8@yahoo.com>
 <5eb405c70903111127x49cd2c71xc068471b2f6d4338@mail.gmail.com>
 <6F9CE147-0968-4921-943D-F127DBF91387@yahoo.com>
 <5eb405c70903112251k4702b870q761783261d7a5a4@mail.gmail.com>
 <add18bc80903122040o50ee5771q718a245ed67f356f@mail.gmail.com>
 <add18bc80903130710h2df3bb69p853cb5a9281dfb7@mail.gmail.com>

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.
>>