Content Management Interoperability Services(CMIS) interface for Modeshape.

[oleg.kulikov]

Content Management Interoperability Services (CMIS) is an open starndard that defines an abstraction for controlling diverse repositories using web services. It seems that best way is to use Apache Open CMIS (Chemistry) implementation so I've started work in this direction.

Chemistry allows to configure CMIS bridge for only one repository. That means one WAR for each repository. Since each ModeShape engine has support for multiple repositories, it would be far better to have a single WAR that supported multiple repositories than having a separate WAR (which must be configured) for each repository. This is especially since ModeShape makes it very easy to add repostiories (in embedded or in JBoss AS7). Using separate WARs is complicated even more in case of AS7, since we have to deploy all dependencies inside each WAR. Otherwise, trying to share dependencies via AS7 modules results in a conflict with XMLInputFactory (AS7 defines via system properties a different implementation than what Chemistry is expecting, and this results in errors/exceptions).

After some time of investigation, we've tried various ways of getting Chemistry to work with multiple repositories via a single WAR file, but ran into problems. Therefore, we have several options:

1. Use Chemistry as-is, and configure a separate WAR for each repository. This is far from ideal, as it makes setup and administration much more difficult and error prone.
2. Help to improve Chemistry to be able to support multiple repositories, providing patches or fixes. We don't want Chemistry to *have* to support multiple repositories with each WAR, but it'd be nice if there was a way to do that out of the box. Of course, this assumes that the Chemistry community is open to this enhancement.
3. Provide our own CMIS implementation.

Our preference is #2, and options #1 and #3 are far less ideal.

Any thougth on this subject from community are very much appreciated. We'll be approaching the Chemistry community to find out if they are at all interested being able to support multiple repositories in a single WAR file.

[rhauch]

I concur that we'd really like to re-use Chemistry. But at this point we do need the additional capability to support multiple repositories; having one WAR per repository is just too big of a hassle for our users.

BTW, nice work on prototyping this, Oleg. I know that you went through lots of variations to try to get Chemistry to work, and that none of these were successful.

Anyone that wants to see what option #1 might look like can view Oleg's pull request, which is referenced from MODE-295.

[vasilievip]

Randall Hauch wrote:

Anyone that wants to see what option #1 might look like can view Oleg's pull request, which is referenced from MODE-295.

There is no link to pull request in issue

Randall Hauch wrote:

I concur that we'd really like to re-use Chemistry. But at this point we do need the additional capability to support multiple repositories; having one WAR per repository is just too big of a hassle for our users.

Totally agree

Oleg Kulikov wrote:

Any thougth on this subject from community are very much appreciated. We'll be approaching the Chemistry community to find out if they are at all interested being able to support multiple repositories in a single WAR file.

I'm currently trying to use federation feature of Modeshape 2.8 to have multiple repositories available via CMIS (met some issues, will provide some testcase for review)

[rhauch]

There is no link to pull request in issue

Fixed.

I'm currently trying to use federation feature of Modeshape 2.8 to have multiple repositories available via CMIS (met some issues, will provide some testcase for review)

That would be great to see. What kind of connector are you using?

We'll be adding federation in 3.1; work is well underway, though we'll likely not have all the connectors completed by 3.1.

[vasilievip]

Randall Hauch wrote:

That would be great to see. What kind of connector are you using?

For attached testcase - inmemory and filesystem connectors, please see attachment to MODE-295 (just run "mvn clean install" to execute tests, please note "mount-path=/fed" in repository.properties)

workspace jcr:name="offset" - mapping to existing repo with existing branch, looks working

workspace jcr:name="mirror" - mapping to existing repo root, looks not working

workspace jcr:name="map" - mapping to existing repos, looks not working

[vasilievip]

Randall Hauch wrote:

We'll be adding federation in 3.1; work is well underway, though we'll likely not have all the connectors completed by 3.1.

Well, I'm working on own (soap client based) implementation of connector (similar to filesystem one) and I would vote to have CMIS connector available in 3.<not too far away>. I'm not clear on what to do with versioning provided by external repo as well as native search, but all of this already is in modeshape jira

[rhauch]

Well, I'm working on own (soap client based) implementation of connector (similar to filesystem one) and I would vote to have CMIS connector available in 3.<not too far away>. I'm not clear on what to do with versioning provided by external repo as well as native search, but all of this already is in modeshape jira

We have a JIRA for a CMIS connector: MODE-650. We recently retargeted it to 3.2 due to time constraints of 3.1. We also pushed to 3.2 the changes to the connector SPI for versioning and native search. Any information you can share as comments on that issue would be greatly appreciated. We'd welcome any contribution you can make!

[vasilievip]

Randall Hauch wrote:

That would be great to see.

Randall, do you have any comments on the issues with federation? I've attached my project to the MODE-295: cmis-modeshape-2.x-federation.zip

[rhauch]

Please open a separate bug in JIRA and attach your files again.

[vasilievip]

Done

https://issues.jboss.org/browse/MODE-1730

[rhauch]

I'd recommend that you look into trying out federation that's already available in our 'master' branch and will be released shortly as 3.1.0.Final. ModeShape 3 is substantially improved over 2.x in every possible way. We also hope it's far easier to implement a connector; see the code for our file system connector and Git connector. (The latter is far more complicated than the file system connector, but it is also mapping different subgraphs in the projected content into various functionality in Git.)

[vasilievip]

Will check and provide feedback, thanks

[rhauch]

Ivan, can you take a look at our connector SPI in 3.1.0.Final? Hopefully you can switch from 2.8.x to ModeShape 3. One reason is that 3 is simply far better all around. Second is that we don't think there will be too many more 2.8.x releases (see here).

WDYT?

[vasilievip]

Randall Hauch wrote:

Ivan, can you take a look at our connector SPI in 3.1.0.Final?

Once you released 3.1 we started looking into migration. I think connector API is much easier to understand and document types discovery API may be critical feature for us in near future. So, modeshape 3 is definetely our preference. Not sure how quickly we can migrate our code (I have map-based connector implemented), but yeah, we are working on this

More examples on how to programmatically configure engine (federation) and add connectors, would be very helpful: https://github.com/ModeShape/modeshape-examples

Thank you very much for getting back to me, really appreciate that.

[vasilievip]

Randall Hauch wrote:

I'd recommend that you look into trying out federation that's already available in our 'master' branch and will be released shortly as 3.1.0.Final. ModeShape 3 is substantially improved over 2.x in every possible way. We also hope it's far easier to implement a connector; see the code for our file system connector and Git connector. (The latter is far more complicated than the file system connector, but it is also mapping different subgraphs in the projected content into various functionality in Git.)

Randall,

I can't get federation working for simple case, not sure if I've got configuration properly:

https://github.com/vasilievip/modeshape-examples/commit/89a992aff4d49f35b7f16463b6eaf24bc65f5a65