I think it makes sense to include all dependencies as optional for a
first pass solution.
However, I think there is value in the scenario Jay mentioned. Suppose
we have a WAR file that was built to be installed in a full JavaEE5
server. If we attempt to install that in an Aries enabled Web only
server with all dependencies as resolution:=optional it will
successfully install but fail to run. We could potentially highlight
the user error during installation if we attributed special significance
to known JavaEE5 imports and not include those with the catch-all
optional resolution.
Joe
Valentin Mahrwald wrote:
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
--
Joe
