On Jul 30, 2006, at 6:33 PM, Jim Marino wrote:
On Jul 30, 2006, at 5:21 PM, Jeremy Boynes wrote:
On Jul 30, 2006, at 2:55 PM, ant elder wrote:
What about the dependencies of the extension? It looks like right
now all
the dependency jars still have to go in the boot directory and
only the
extension in the extension directory. Is that what you intend?
The spec does not define way to specify the classpath for a
composite so for now everything has to be bundled in it on in a
parent classloader (and the boot classloader is the parent to the
each of the extension composites).
The jar classpath will still work so if you provide a Class-Path
entry in the manifest dependencies specified there should be found.
Longer term I think we need a way to define a classpath in the
composite. I had a quick discussion a while ago with Oisin about
using a Maven repository to hold SCA artifacts and perhaps we can
use that here. I can think of two ways we could allow users to do
this:
For system services I think this is fine but I wouldn't want to
require this of applications.
I don't see the distinction here. We are saying that system services
are just composites and this is a way of associating resources with a
composite (specifically Java class files) - why would there be any
difference?
There are a couple of other options we could also provide, based
off of OSGi semantics:
1. Allow a jar to specify its dependencies using "pure" OSGi
manifest entries when the composite is packaged as a bundle and
deployed to an OSGI environment
2. Allow the SCDL to specify dependencies using OSGI semantics.
These would then be "baked" down to whatever packaging the host
environment supported, perhaps through a pre-deploy step
3.As part of #2, have a way to specify a maven bundle and have the
pre-deployer pul it from maven and repackage it.
Generally I don't like pre-packagers but that may be the price
people have to pay for deploying on host environments with
problematic classloading semantics - e.g. J2EE app servers. In an
OSGi or jar launcher environment, things should just work without a
predeploy step.
These seem like alternatives. If the user wants to use OSGi semantics
then this would be a way to support them. However, there are a lot of
things out there that do not have OSGi manifests and we need to be
able to support them two.
Also, these only work if the composite is packaged as a bundle and I
think that it's important to allow people to deploy composites that
are simple XML SCDL files (no archive involved). That means we need a
way in the SCDL to be able to specify what the dependencies are.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
