S-RAMP -> Maven Repository Facade

[eric.wittmann]

Overview

One component currently being worked on in the S-RAMP project is a Maven Repository Facade on top of the S-RAMP repository.  The reasons for doing this include:

• Provides the ability to easily browse the S-RAMP repository in a familiar way using standard Maven repo tools (not so important)
• Enables developers to directly add S-RAMP artifacts as dependencies in their Maven projects (interesting!)

The Problem

The S-RAMP specification and the Maven Repository format have some things in common, and I'm confident that a mapping between the two can be done in a sensible way.  The problem is how do we map the Maven Repo concepts (groupId, artifactId, version, type, classifier, etc) to the S-RAMP artifact concepts (artifact model, artifact type, uuid, etc)?

Strawman Solution

I have started writing the code for the Maven Repository Facade in the S-RAMP project using a relatively straightforward (naive?) mapping between these two systems.  Here are the details:

Maven Concept	S-RAMP Concept Mapping	Example
Group Id	{model}.{type}	xsd.XsdDocument
Artifact Id	{uuid}	4c0bee48-54f6-4b44-aeb3-86f8c91dde12
Version	Artifact Version or 1.0 if no version (version is optional in S-RAMP)	1.0
Type	{model}	xsd
Classifier	n/a	n/a

So for example, I might upload my XML Schema (XSD) to S-RAMP.  The result will be a new XsdDocument with a UUID of 4c0bee48-54f6-4b44-aeb3-86f8c91dde12 added to S-RAMP.  As a Java developer I can add a dependency to my Maven project with the following markup:

<dependency>
    <groupId>xsd.XsdDocument</groupId>
    <artifactId>4c0bee48-54f6-4b44-aeb3-86f8c91dde12</artifactId>
    <version>1.0</version>
    <type>xsd</type>
</dependency>

This approach is workable (my current implementation does exactly this) but not ideal.  The groupId and artifactId, for example, are not easily known.  This problem can be mitigated with tooling, obviously.

I'm interested in suggestions for how to better map the S-RAMP space onto the Maven space.

[objectiser]

Although the two usecases mentioned in the overview are a good starting point, and I think were previously discussed as the initial functionality for the maven/sramp integration, I think the missing usecase may provide some answers to your problem:

• Enable maven artifacts, representing a service implementation (or a group of documents representing the service contract), to be pushed to the S-RAMP repository using "maven deploy"

If we take this usecase, then the repository will be given the GAV details so that when it unpacks the maven artifact, it could automatically associate them with the service implementation representation in S-RAMP.

So maybe the approach should be to add extra attributes to the relevant model components in the repository to store the GAV details - and only expose those artifacts via the maven facade?

[objectiser]

I also should have said that I think users would want to be able to specify their own group, artifact and version details anyway - so I think we need to store these attributes in the repo.

[eric.wittmann]

I think allowing users to specify their own GAV info makes a lot of sense.  Initially I had stayed away from that idea thinking we would want the Maven Repository Facade (MRF?) to work with any S-RAMP compliant implementation.  Perhaps we can have both, however.  We can use S-RAMP properties to store the GAV information.  If that information does not exist, you can still get at the resource using my strawman scheme above.  But if the GAV information exists as properties on the S-RAMP artifact, then you could get at the artifact that way.  In other words, you can get at any artifact using its model, artifact type, and uuid.  But a subset of artifacts in the repo can also be accessed via their extended GAV properties.

We might even be able to do this and still have the MRF be able to go against any spec-compliant S-RAMP impl.  I'm confident we can implement enough of the MRF for use by maven itself (since Maven will always use full paths to resources, based on the GAV info).  I'm not sure if we'll be able to fully implement the maven repo folder structure though.  I'll need to check the Query section of the S-RAMP spec to see.  I suspect not.  In that case we can have full maven repo browse functionality when using the Overlord S-RAMP impl, but only partial functionality when using another spec-compliant impl.

As for the use case of pushing data into the repository - that makes sense and shouldn't be too hard.  I haven't looked into it but presumably Maven defines some sort of DAV interface for doing this.

[objectiser]

Supporting both schemes sounds like a good idea to me.