Link: Added: This issue Cloned from MODE-1027

Security: Added: Public

Writer: Added: Darrin

The ModeShape code was recently changed (via MODE-1027) so that the JsonRestClient will no longer first delete an existing file before publishing. Instead, the client checks whether there is an existing published file in the repository (at the desired location), and if so it does an update (via PUT); otherwise, the client adds the file to the repository (via POST).

Then, the RESTful service behavior on PUT is slightly different. If the node that is to be updated is not already 'mix:versionable', then the RESTful service merely updates the node/subgraph. However, if the node being updated already is 'mix:versionable', then the RESTful service first does a JCR checkout of the node before updating, and after updating does a checkin.

Therefore, while we are not changing the default behavior of the JsonRestClient to use JCR versioning, it now properly updates any existing content, and the RESTful service will properly use JCR versioning patterns if required when updating the content. We don't want to enable versioning by default, because the use case doesn't require it. After all, the ModeShape repository is NOT intended to be a Version Control System; it is used for publishing metadata and models for access at runtime via VDBs and JDBC.

In the future releases we can let Eclipse plugin users decide whether they want to enable versioning. Since this change, the Eclipse plugin can be changed and used with SOA-P 5.1, and the repository will behave correctly.

Release Notes Docs Status: Added: Documented as Known Issue
Release Notes Text: Added: ModeShape publishing in JBDS will not support artifact versioning in the first release.    

Document as a KI.

Link: Added: This issue is related to MODE-1080

This is the jira enhancement for enabling versioning from the eclipse plugin.