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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
