Re: Composite classpaths, was: How to use extensions with the standalone launcher?

[Jim Marino <jm...@myromatours.com>]

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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Composite classpaths, was: How to use extensions with the standalone launcher?

[Jeremy Boynes <jb...@apache.org>]

On Jul 31, 2006, at 11:42 PM, Jim Marino wrote:
> 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.

I agree.

We need an abstraction for "dependent artifact" and a way of locating  
and resolving them; using a Maven repository would be one concrete  
implementation of that abstraction.

>>> 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/

This seems like it can be implemented on top of a repository for OSGi  
artifacts or a repository of Maven artifacts - this sounds good.

>
>> 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.

So the key here is the abstraction for artifact resolution. The  
interface I had proposed before was:
interface CompositeRepository {
     URL locate(String name);
     URL locate(String groupId, String artifactId, String version,  
String identifier);
}

We probably need to extend this to capture the formal concept of an  
Artifact so I would recast this as:

class Artifact {
     String group;       // a conceptual grouping of artifacts such  
as publisher
     String name;        // the name of the artifact
     String version;     // the version of the artifact
     String classifier;  // a classifier such as hardware platform or  
language
     boolean optional;   // whether the artifact is required
}

class ResolvedArtifact extends Artifact {
     URL url;            // a URL where the artifact can be obtained  
(typically a file: URL)
     Collection<ResolvedArtifact> dependencies; // list of  
dependencies the artifact has
}

interface ArtifactRepository {
    ResolvedArtifact resolve(String name); // lookup based on a  
simple string supplied by the user
    ResolvedArtifact resolve(Artifact artifact); // lookup based on  
explicit information
}


I think this is general enough to cover both Maven and OSGi artifact  
naming schemes (and hopefully more).

--
Jeremy


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org