On Jul 31, 2006, at 1:56 PM, Jeremy Boynes wrote:
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?
An end user application developer could write some type of library
that gets reused by different composites. We should have a mechanism
that supports this without resorting to maven. I think we should have
some type of resolver abstraction, one implementation being a maven
downloader.
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.
That's what #2 would be used for as it is not dependent on OSGi
artifacts such as bundles. A SCDL artifact would specify the
dependencies and they could be resolved to whatever physical
packaging the host platform supports/
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.
#2 could also work with a file system through some type of "custom
resolver" mentioned above.
Jim
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
