My suggestion was, going with Guillaume's initial suggestion, to scan for dependencies but generate them all as optional.
Respecting the manifest files in the embedded libs is a separate concern since that does not handle the general case. And yes, I think we should respect those as well. On Mon, Oct 5, 2009 at 2:26 PM, Lin Sun <[email protected]> wrote: > 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 > >> > > >> > > >
