I agree that we should trust that the user has packed everything in
the war.  Otherwise, the user would have to repack his war or specify
the dependency in the deployment descriptors like Jay mentioned
earlier.  In the later case, I'd expect the user to use the
"Import-Package" in the war's manifest file or the "Import-Package"
webbundle url param to specify the dependencies.

Valentine, are you suggesting us to NOT analyze the classes now and
just make all the JRE and some standard app server capabilities as
optional imports?   Also, do we plan to honor the manifest file
specified in the web-info/lib jars?  I'd think yes, since more and
more jar files are bundlized now.

Thanks

Lin

On Mon, Oct 5, 2009 at 6:21 AM, Valentin Mahrwald
<[email protected]> wrote:
> Thinking about it again, I agree with Guillaume and Ian that assuming the
> WAR file is self-contained and hence only generating optional imports is the
> best/simplest starting point. We also probably want to generate optional
> imports for more than just the JRE packages in case the WAR assumes standard
> app server capabilities like JTA etc to be available in the runtime.
>
> I'll raise a JIRA for this later if there are no objections :)
>
> On Sat, Oct 3, 2009 at 7:36 PM, Guillaume Nodet <[email protected]> wrote:
>
>> We need to at least import all the packages that may be provided by
>> the JRE: javax.*, org.w3c.* and such things.
>> So I still think using optional imports by default would be easier.
>>
>> On Sat, Oct 3, 2009 at 20:08, Ian Robinson <[email protected]> wrote:
>> > If the aplication starting point is a vanilla war that runs in Java EE in
>> a
>> > non-OSGi context then that war would need to have been correctly packaged
>> > with all its dependencies in order to run in that environment. When
>> > converting such a war to a web application bundle we should probably
>> assume
>> > - as a starting point - that we don't need even optional imports for the
>> > packages referenced by the embedded libraries as putting these in the
>> > manifest will likely result in over-provisioning.
>> >
>> > - Ian
>> >
>> > Jay D. McHugh wrote:
>> >
>> > This may be premature - but...
>> >
>> > I am looking ahead to when Aries is in use by an app server to provide
>> > the required plumbing.  And, in a case like that, a WAR file may
>> > (probably will) be deployed that expects to have the EE framework (mail,
>> > JNDI, EJB, etc) available.
>> >
>> > This is my expectation, although we'll surely see web and other profiles
>> > that don't include everything.
>> >
>> > So, there will be WAR files that just have
>> > deployment descriptors that specify what the dependencies are.
>> > Or, would we expect that there will be some other part of the EE
>> > framework that will have to provide backward compatibility (mapping the
>> > deployment descriptor onto a OSGi manifest)?
>> >
>> > Jay
>> >
>>
>

Reply via email to