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

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

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:

1) if the composite is provided as a jar file, look in the jar file  
for Maven metadata stored in META-INF/maven/${groupId}/${artifactId}/ 
pom.xml and read the dependencies from there.

2) allow the user to specify a <dependencies> element in the SCDL  
file listing artifacts to be added to the classpath

We take the list of dependencies, obtain them from a maven repo and  
add them to the classpath for the composite. This would work for any  
composite not just ones used as extensions.

Does that seem like it would work?
--
Jeremy

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

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 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: 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?

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

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

Jim

> 1) if the composite is provided as a jar file, look in the jar file  
> for Maven metadata stored in META-INF/maven/${groupId}/$ 
> {artifactId}/pom.xml and read the dependencies from there.
>

> 2) allow the user to specify a <dependencies> element in the SCDL  
> file listing artifacts to be added to the classpath
>
> We take the list of dependencies, obtain them from a maven repo and  
> add them to the classpath for the composite. This would work for  
> any composite not just ones used as extensions.
>
> Does that seem like it would work?
> --
> 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