Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of linsun.unc@gmail.com designates
 209.85.218.226 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=D/LwABSWS/VORIsXUJdgjUhPPvNfIgeFv6uKPdn1SU4yAgFYEHMlUa1PiJCnuB1w70
         VMmf3Iz+keUwXU3s5xGtIMSKmhC0Afdk8O/gSKRVbAvJZiGUEDZX+smD5B9knsSjzPrZ
         CKOas6SYTmzgLd/OVoU5LPWpGtcyAAfPhyQzo=
MIME-Version: 1.0
In-Reply-To: <713DB748-956E-4223-BDBE-EA1E96887BEC@gmail.com>
References: <b23ecedc0910020524u47e2294bs8e2c81afaa52f743@mail.gmail.com>
	 <b23ecedc0910021117h5b7d2a10w75a0a731f0ef48f1@mail.gmail.com>
	 <4AC671EC.8090603@gmail.com> <4AC79325.2000402@googlemail.com>
	 <b23ecedc0910031136j20f9a87al9010dc7d0cb04cd4@mail.gmail.com>
	 <c413d8ad0910050321u78970bc7ge76d7055240a8020@mail.gmail.com>
	 <add18bc80910050626r5b840dc2t991967ca8ff2dd38@mail.gmail.com>
	 <c413d8ad0910050641h3d6bd8cfxb60c097cc3dec1c0@mail.gmail.com>
	 <add18bc80910051021i38269fefsab7a00ba24cf9c84@mail.gmail.com>
	 <713DB748-956E-4223-BDBE-EA1E96887BEC@gmail.com>
Date: Wed, 7 Oct 2009 22:16:54 -0400
Message-ID: <add18bc80910071916l43e63b75gad7eff28747d5cfc@mail.gmail.com>
Subject: Re: Wab url handler and imports
From: Lin Sun <linsun.unc@gmail.com>
To: aries-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi, Thanks for the clarification on this.  I had a bit confused myself
with Bundle-Classpath and Import-Package.  I had hoped that by having
these web-inf/lib jars in the Bundle-Classpath (which RFC 66 mandates)
OSGi framwork would automatically detect the import-package for the
jars listed in the Bundle-Classpath thus eliminate the need to scan
these web-inf/lib jars, but it doesn't seem to be the case.

Lin


On Mon, Oct 5, 2009 at 1:32 PM, Valentin Mahrwald
<vmahrwald@googlemail.com> wrote:
> We shouldn't need to scan embedded jars (i.e. in web-inf/lib) if they have a
> valid bundle manifest.
>
> Otherwise, we probably want to scan them for the reason that they might use
> common app server packages on behalf of the war (such as Spring using JTA
> for example). However, it makes (some) sense to generate them as optional
> because otherwise common utility libraries like commons logging are going to
> generate loads of random imports that will almost certainly not be
> satisfied.
>
> As for the packages directly used from the war (i.e. out of
> web-inf/classes), they will probably not be optional most of the time. But
> then according to what Ian wrote earlier, I think the initial assumption is
> that the WAR should not be using any dependencies other than those in the
> embedded libraries and possibly standard app server dependencies.
>
> In any case generating everything as optional seems to me like the simplest
> solution that will provide some value. Even if dependencies are missing the
> user would be able to work out which ones those are from the generated
> optional imports. So we are not doing a lot worse than failing at install
> time with that.
>
> Regards,
>
> Valentin
>
> On 5 Oct 2009, at 18:21, Lin Sun wrote:
>
>> Is this scanning going to be done for the classes in web-inf/classes
>> dir or both the web-inf/classes & jars in web-info/lib dir?   RFC 66
>> requires all jars from web-inf/lib to be added to the Bundle-Classpath
>> manifest header and if we assume the user has packed the war
>> dependencies in the war file, I wonder if we need to scan the jars in
>> web-inf/lib dir?
>>
>> If we do need to scan both (the later case), would the packages needed
>> by the classes in web-inf/classes dir marked as required  (if it is
>> not importing from within the war) while the packages needed by
>> classes in web-inf/lib dir marked as optional?
>>
>> Thanks
>>
>> Lin
>>
>> On Mon, Oct 5, 2009 at 9:41 AM, Valentin Mahrwald
>> <vmahrwald@googlemail.com> wrote:
>>>
>>> My suggestion was, going with Guillaume's initial suggestion, to scan for
>>> dependencies but generate them all as optional.
>>>
>
>