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?
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.
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.
Supporting both schemes sounds like a good idea to me.