Rio Resolver

Rio provides the ability to deploy and provision service artifacts and their dependencies. The resolution of artifacts is done from configured repositories, and becomes a natural extension of the build, test and deploy lifecycle.

As Rio deploys services, service artifacts and dependencies are automatically provisioned and installed on compute resources that meet declared requirements of services being deployed.

Rio addresses the issue of duplicating dependency management configuration between the development and deployment phases by ensuring that the versioned components that have been used in development, test and qualification are seamlessly carried over.

The Rio Resolver currently resolves artifacts using configured Maven 2 repositories. Using the declaration(s) found in Maven POMs and settings. The Rio Resolver is not provided by Maven, the Rio Resolver simply uses Maven repositories to obtain declared artifacts and dependencies.

Why not use Maven to resolve artifacts and dependencies for service provisioning?

• For starters, we want to abstract the underlying dependency resolution implementation in order to give the flexibility to potentially support other repository based dependency management approaches.
  
  In the future we may seek to provide support for Ivy or the OSGi Bundle Repository. Providing an abstraction on top of the concrete dependency management solutions gives us flexibility going forward.
  
  
• Secondly, the ability to embed a Maven resolver into the Rio runtime was initially tried, but we found that the Maven Embedder would not be supported until the 3.0 betas. As of this release Maven 3.0 is still at alpha. So in an effort to be in control of our own destiny, a lightweight Resolver that interacts with Maven2 repositories was created.

Artifacts are referenced in abstract terms (groupId:artifactId:[classifier:]version), rather than a (logical) file path. This is the big difference with the use of artifacts in opstrings with Rio. Previously, you declared jars as resources for both the interface and service implementation classes. With the introduction of artifact declaration in opstrings, you now just declare the groupId:artifactId:[classifier:]version instead.

The benefits here are that the declared artifact, it's dependencies and any transitive dependencies are resolved. If the machine the Monitor or Cybernode is executing on does not have the required jars available, they will be provisioned. Its that simple.

Declaring artifacts in opstrings follows the same conventions that Maven uses. Take a look at the example below:

The keyword artifact in the DSL (or Artifact in an XML document) triggers artifact resolution. You cannot have both artifact resolution and resource declarations in the same opstring.

You can also include other opstrings using an artifact. This allows external services to be included in the activation of your application.

The included artifact is resolved from configured repositories. The artifact must have a .oar extension. Once located, the resolved OAR is included in the deployment and subsequent management of the declared service(s).

Artifacts and dependencies are resolved from repositories. The Rio resolver obtains repository configuration from POMs and from your settings.xml. When service artifacts are being resolved, repository configurations are lazily obtained, appending configured repository definitions from POMs (if declared), and filtering them against any declared mirror declarations in settings.xml. Maven central is always included last.

By translating groupId:artifactId:[classifier:]version to groupId/artifactId/version we can derive the location of the artifact and download it to the (configured) local repository. If there are issues with the message digests not matching, the retrieval of the artifact is retried. If there are still issues with the message digests not matching, the Rio Resolver will not provision the artifact. In Maven terms, this follows a checksumPolicy set to fail.

Dependency scope is used to limit the transitivity of a dependency, and also to affect the resolved classpath for a service. The following scopes are automatically excluded:

• test
  This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
• provided
  Indicates you expect the dependency to be provided at runtime.
• system
  Indicates you have to provide the dependency. The artifact is always available and is not looked up in a repository.
• optional
  Although not a dependency scope, dependencies declared as optional are automatically excluded.

The "dl" classifier is used to indicate that an artifact is used for client or download access, and contains the classes (and resources) necessary for the client of the service to interact with the deployed service. An artifact with a "dl" classifier does not contain implementation classes, or have dependencies required to instantiate the backend service implementation.

The resolution of an artifacts dependencies that have a "dl" classifier is scoped to only include declared dependencies that also have a "dl" classifier. If a service has a dependency on another service for compilation, and requires classes (is a client of) of that service's "dl", you need to declare a dependency for that artifact with the "dl" classifier.

If a service's "dl" has a dependency that is not packaged with a "dl" classifier you have two options:

1. Use classdepandjar to include the requisite classes into your "dl".
2. Create a new dependant jar using the "dl" classifier, and declare that as a dependency

The Rio Resolver is not a replacement for Maven artifact resolution. It does not do all the things that an embedded Maven resolver would provide. The current known limitations are as follows:

• No wagon support. The Rio resolver only provides simple HTTP based downloading of artifacts.
• No settings.xml proxy configuration support.
• Profiles declared in settings.xml only have activation support if they are configured to have activeByDefault set to true, or if activation is triggered by a system property being set.
• No support for import scope. This scope is only used on a dependency of type pom in the <dependencyManagement> section. It indicates that the specified POM should be replaced with the dependencies in that POM's <dependencyManagement> section.