One important request: We're renaming Overlord S-RAMP! In order to highlight the project as a viable standalone solution, as well as to better distinguish between the project and spec names, we're currently brainstorming new ideas. If you have a suggestion, please add it to https://developer.jboss.org/thread/249956!
Another topic to highlight is the deprecation of Jetty, Fuse, and Fuse Fabric support. It was decided that the amount of work necessary to support them was taking too much time away from new features and bug fixes. Further, it's our understanding that none of them were used in the community. Note that they have not been completely removed. Rather, they're simply pulled out of the Maven model under SRAMP-620. If you feel strongly about either of them and would like to see continued support, please let us know: https://community.jboss.org/en/overlord. I am definitely not against re-enabling them if there is an actual need.
New Feature and Enhancement Highlights:
- Overlord S-RAMP is now around 95% compliant with the OASIS S-RAMP spec. Remaining tasks are tracked under SRAMP-462. A notable task was full support for the SOA and ServiceImplementation logical models (SRAMP-167).
- 100% spec compliance should be expected in the next release, which would most likely constitute a 1.0 release candidate.
- SRAMP-609
A new "ArtifactBuilder" extension contract was created, replacing the old "Deriver" and "Linker" concepts. This provides a powerful means to automatically generate custom metadata, relationships, and derived content whenever relevant artifacts are deployed to S-RAMP. A suite of built-in Builders are provided, covering most use cases. However, developing your own is also supported. See http://docs.jboss.org/overlord/sramp/0.7.0.Final/html/_overlord_s_ramp_implementation.html#_extending_custom_artifactbuilder for more info. - SRAMP-580
If an artifact is deployed to S-RAMP, without explicitly providing the artifact's model and type, the server now automatically attempts to detect it. Another extension contract was added to support this: "ArtifactTypeDetector". As with "ArtifactBuilder", S-RAMP also provides several Detectors OOTB, but custom implementations are possible. - SRAMP-531
Previously, archive expansion (discovering artifacts within a jar/war/ear/zip) was handled by each individual client. Instead, this was moved to the server. So, regardless of the client, archives will be exploded and parsed in a consistent, automatic manner. - SRAMP-601
The deleteContent action is now supported, allowing a document artifact's content to be completely deleted (the spec, as well as some use cases, require this). See the next bullet for a discussion about constraints. - SRAMP-541
The update, updateContent, delete, and deleteContent actions now have a set of restrictive constraints that must first be dealt with. These include custom metadata, relationships, etc. This guarantees data integrity, as well as furthering the "impact analysis" use cases. Further, updateContent and deleteContent now automatically regenerate and delete all applicable derived content, respectively. See https://developer.jboss.org/thread/250173 for more discussion and details. - SRAMP-466
When deploying artifacts through S-RAMP's "batch" capability, the entire batch is now given priority when relationships are resolved, as opposed to first checking the existing artifacts in the repo.
