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.

Support

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?

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.

Artifact Declaration

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


OAR artifact inclusion is only supported with Groovy based opstrings.

Artifact Resolution

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.

It is generally a good idea that the <repositories> section be removed from POMs, and repositories be specified only in settings.xml. This makes for cleaner and predictable deployments.

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.

We highly recommend the use of a repository manager.

Automatic Dependency Exclusions

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.

Limitations

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.