I just finished working on some big changes to the connector framework. All the detail regarding the issue and the design can be found in DNA-281 (https://jira.jboss.org/jira/browse/DNA-281). However, this is a fairly significant change, so I wanted to let everyone know what's going on. (The commit email was actually too big, which is another reason for this email).

The problem stems from not having a perfect mapping between a connector and the notion of a JCR workspace. When we came up with the initial connector design, we'd hoped that a connector would map to a JCR workspace, and that we could just create multiple sources (instances of connectors) when we need multiple workspaces. Unfortunately, some of the workspace-level operations in JCR don't work too well with this. In particular, creating workspaces would have entailed setting up new RepositorySource instances, which is difficult if you have to also set up the back end system, like a database. To really fix this, we need a connector to be able to have multiple workspaces and to support creating, cloning, and destroying workspaces.

Normally, this would be that much of a surprise. We've always followed the evolutionary approach to design and development. So this change wouldn't really be that special - if it weren't for the size of the change. The connector API is affected, which means that each connector implementation is affected. Also, the Graph API is affected because we need to expose these new operations. And this meant that every code that used the Graph API may be affected, since they now need to possibly have some notion of a workspace. All in all, a lot of code has been impacted by this. And I spent several days trying different approaches that were incremental, and nothing worked. I had no choice but to make all the changes at once.

Interestingly, while making the changes, I discovered a bug in the federation code (DNA-282), and a number of existing test cases fail. And of course the Getting Started repository example fails because it relies up the federation connector. So, rather than complicate an already mess of a commit set, I decided to temporarily remove these two projects from the build.

Similarly, I have local changes to the JCR project to support writing (which was the ultimate reason why support for workspaces was needed in the first place). And these changes aren't quite complete enough to commit, yet I didn't want to spent a lot of time fixing test cases that I'll be making changes to. So this project was also pulled from the build, too.

My apologies for the state of the project, and for this massive commit. I dislike these large changes with a passion, but just couldn't figure out a way to get around it. But everything compiles, and all tests (except those listed above) run successfully.

For those of you working on connector implementations, feel free to look at the in-memory connector, the JBoss Cache connector, or the JPA Store connector. Specifically, look in the RequestProcessor implementation classes in the connectors, since that's where all the interesting stuff is. Of course, some of the source implementations have properties that define the names of "predefined workspaces" and a "default workspace", and that may be of use to you. These all support multiple workspaces, but in slightly different ways. I think the notion of workspaces would work really well in a couple of our connectors, including SVN and JDBC metadata. Of course, if you have any questions, please post to this list.