An open-source, federated content repository

ModeShape Tools for Eclipse

ModeShape Tools is a set of Eclipse plugins for working with ModeShape and JCR repositories. The plugins have been available for a little while, but we wanted to make sure you knew about them.

Editor for CND files

The first plugin we’ll talk about is an Eclipse editor for the Compact Node Definition (CND) format defined in the JCR 2.0 (JSR-283) specification. Although a client application can connect to a JCR repository and programmatically register node types, it is usually easier to place the node type definitions inside a CND file and to use that file to register all the node types contained within it. ModeShape Tool’s CND editor makes it easy to edit such files.

(The JCR 2.0 API does not define how an implementation should support registering node types via CND files, but many of the implementations have a proprietary way to do it. ModeShape extends the javax.jcr.nodetype.NodeTypeManager interface with several “registerNodeTypes” methods that each take a, a, or an containing CND content. We’re hoping the JSR-333 effort for JCR 2.1 adopts our approach.)

The CND editor is a 2-page Eclipse editor used for editing *.cnd files. The first page is form-based and consists of sections for managing namespace mappings, node type definitions, property definitions, and child node definitions. The second page is a readonly view of the file content.

Take a look at the CND editor with the properties and child node sections collapsed:


When you select a node type, the editor shows the information about that node type on the right side. This includes the node type’s name, attributes, supertypes, and property and child node definitions. Add, change, or remove a property definition or child node definition by double-clicking the particular row in the section’s table or by using the section’s toolbar. Here’s a view of the editor with the properties and child node sections expanded:


The CND editor’s second page is a readonly source view of the *.cnd file. You can control the verbosity of the CND notation by a preference. The source page looks like this:


Here’s a few other features of the CND editor:

  • automatic validation of the CND file, with errors displayed in the header section
  • copy and paste CND elements within the same editor or between CND editors
  • automatic URI completion when adding standard (built-in) namespaces
  • the node type section has a search filter to quickly find and select a node type, even when there are hundreds of node types in the file
  • the ability to show/hide property definitions and child node definitions inherited from supertypes
  • attach comments to any CND element
  • Ctrl-space completion and “look ahead” typing for available supertypes and required types.
  • built-in help

You can read more detail about the CND Editor in our online documentation.

The CND Editor can edit any CND files for ModeShape or any other JCR 2.0 repository implementation. It is also possible to just install just this plugin. So even if you’re not using ModeShape, we think you’ll still find the CND Editor very useful.

Publishing files to ModeShape

The second ModeShape Tools plugin provides a way to upload files from your Eclipse workspace to a ModeShape repository. It can publish entire projects, folders, or just selected files. You select the ModeShape server, repository, workspace, and area within the workspace where the file(s) are to be placed.

To use, simply select the files and/or directories you want to publish, and then choose “ModeShape->Publish” from the context menu. You’ll then see a dialog that confirms the details of the publishing request:


Simply select “Finish” to publish the files to ModeShape.

The publishing tool can also:

  • un-publish (or delete) resources from a publish area of a ModeShape server
  • indicate which files should also be versioned (with “mix:versionable”) when they are published
  • show the output of the publishing operations in the message console view
  • show in a Servers view the repositories, workspaces, and publish areas for multiple ModeShape servers
  • always ignore certain file types from being included in the publishing operations, configured via preferences
  • built-in help


Each of these features can be installed separately or together by following these steps:

  1. Start up Eclipse 3.7 (Juno), then choose “Help > Install New Software…”
  2. Enter and hit “Enter”.
  3. When the site loads, select which feature(s) you want to install, or click the “Select All” button.
  4. Click “Next”, agree to the license terms, and install.

You can read more about ModeShape Tools in our documentation

Want to contribute?

These plugins are open source and are on GitHub, licensed under EPL and LGPL. We’re always looking for contributors to help out. If you would like to contribute, find a bug, want to suggest a new feature, or have any questions, please let us know in our discussion forum and we’ll get you started. The JIRA for these plugins is here.


Filed under: features, news, open source, releases, tools, uncategorized

New repository backup and restore in ModeShape 3

We recently added a new feature to ModeShape 3.0.0.Beta3 that enables repository administrators to create backups of an entire repository (even when the repository is in use), and to then restore a repository to the state reflected by a particular backup. This works regardless of where the repository content is persisted.

There are several reasons why you might want to restore a repository to a previous state, and many are quite obvious. For example, the application or the process it’s running in might stop unexpectedly. Or perhaps the hardware on which the process is running might fail. Or perhaps the persistent store might have a catastrophic failure (although surely you’re also using the persistent store’s backup system, too).

But there are also non-failure related reasons. Backups of a running repository can be used to transfer the content to a new repository that is perhaps hosted in a different location. It might be possible to manually transfer the persisted content (e.g., in a database or on the file system), but the process of doing so varies with different kinds of persistence options.  Also, ModeShape can be configured to use a distributed in-memory data grid that already maintains its own copies for ensuring high availability, and therefore the data grid might not persist anything to disk. In such cases, the content is stored on the data grid’s virtual heap, and getting access to it without ModeShape may be quite difficult. Or, you may initially configure your repository to use a particular persistence approach that suitable given the current needs, but over time the repository grows and you want to move to a different, more scalable (but perhaps more complex) persistence approach. Finally, the backup and restore feature can be used to migrate to a new major version of ModeShape.

In short, you may very well have the need to set the contents of a repository back to an earlier state. ModeShape’s backup and restore feature makes this easy to do.

Getting started

Let’s walk through the basic process of creating a backup of an existing repository and then restoring the repository. Both of these steps require an authenticated Session that has administrative privileges. It actually doesn’t matter which workspace the session uses:

javax.jcr.Repository repository = ...
javax.jcr.Credentials credentials = ...
String workspaceName = ...
javax.jcr.Session session = repository.login(credentials,workspaceName);

So far, this is basic and standard stuff for any JCR client.

Introducing the RepositoryManager

Each JCR Session instance has it’s own Workspace object that provides workspace-level functionality and access to a set of “manager” interfaces: the VersionManagerNodeTypeManagerObservationManagerLockManager, etc. The JSR-333 (aka, “JCR 2.1”) effort is still incomplete, but has plans to introduce a RepositoryManager that offers some repository-level functionality. The ModeShape public API has created such an interface, and accessing it from a standard JCR Session instance is pretty simple:

org.modeshape.jcr.api.Session msSession = (org.modeshape.jcr.api.Session)session;
org.modeshape.jcr.api.RepositoryManager repoMgr = ((org.modeshape.jcr.api.Session)session).getWorkspace().getRepositoryManager();

The interface is pretty self-explanatory, and defines several methods including two that are related to the backup and restore feature:

public interface RepositoryManager {


     * Begin a backup operation of the entire repository, writing the files
     * associated with the backup to the specified directory on the local
     * file system.
     * The repository must be active when this operation is invoked, and
     * it can continue to be used during backup (e.g., this can be a
     * "live" backup operation), but this is not recommended if the backup
     * will be used as part of a migration to a different version of
     * ModeShape or to different installation.

     * Multiple backup operations can operate at the same time, so it is
     * the responsibility of the caller to not overload the repository
     * with backup operations.

     * @param backupDirectory the directory on the local file system into
     *        which all backup files will be written; this directory
     *        need not exist, but the process must have write privilege
     *        for this directory
     * @return the problems that occurred during the backup operation
     * @throws AccessDeniedException if the current session does not
     *         have sufficient privileges to perform the backup
     * @throws RepositoryException if the backup cannot be run
    Problems backupRepository( File backupDirectory ) throws RepositoryException;

     * Begin a restore operation of the entire repository, reading the
     * backup files in the specified directory on the local file system.
     * Upon completion of the restore operation, the repository will be
     * restarted automatically.
     * The repository must be active when this operation is invoked.
     * However, the repository <em>may not</em> be used by any other
     * activities during the restore operation; doing so will likely
     * result in a corrupt repository.

     * It is the responsibility of the caller to ensure that this method
     * is only invoked once; calling multiple times wil lead to
     * a corrupt repository.

     * @param backupDirectory the directory on the local file system
     *        in which all backup files exist and were written by a
     *        previous {@link #backupRepository(File) backup operation};
     *        this directory must exist, and the process must have read
     *        privilege for all contents in this directory
     * @return the problems that occurred during the restore operation
     * @throws AccessDeniedException if the current session does not
     *         have sufficient privileges to perform the restore
     * @throws RepositoryException if the restoration cannot be run
    Problems restoreRepository( File backupDirectory ) throws RepositoryException;

Next, we’ll take a look at each of these two methods.

Creating a backup

The backupRepository(...) method on ModeShape’s RepositoryManager interface is used to create a backup of the entire repository, including all workspaces that existed when the backup was initiated. This method blocks until the backup is completed, so it is the caller’s responsibility to invoke the method asynchronously if that is desired. When this method is called on a repository that is being actively used, all of the changes made while the backup process is underway will be included; at some point near the end of the backup process, however, additional changes will be excluded from the backup. This means that each backup contains a fully-consistent snapshot of the entire repository as it existed near the time at which the backup completed.

Here’s an code example showing how easy it is to call this method:

org.modeshape.jcr.api.RepositoryManager repoMgr = ... backupDirectory = ...
Problems problems = repoMgr.backupRepository(backupDirectory);
if ( problems.hasProblems() ) {
    System.out.println("Problems restoring the repository:");
    // Report the problems (we'll just print them out) ...
    for ( Problem problem : problems ) {
} else {
    System.out.println("The backup was successful");

Each ModeShape backup is stored on the file system in a directory that contains a series of GZIP-ed files (each containing representations of a approximately 100K nodes) and a subdirectory in which all the large BINARY values are stored.

It is also the application’s responsibility to initiate each backup operation. In other words, there currently is no way to configure ModeShape to perform backups on a schedule. Doing so would add significant complexity to ModeShape and the configuration, whereas leaving it to the application lets the application fully control how and when such backups occur.

Restoring a repository

Once you have a complete backup on disk, you can then restore a repository back to the state captured within the backup. To do that, simply start a repository (or perhaps a new instance of a repository with a different configuration) and, before it’s used by any applications, load into the new repository all of the content in the backup. Here’s a simple code example that shows how this is done:

Here’s an code example showing how easy it is to call this method:

org.modeshape.jcr.api.RepositoryManager repoMgr = ... backupDirectory = ...
Problems problems = repoMgr.restoreRepository(backupDirectory);
if ( problems.hasProblems() ) {
    System.out.println("Problems backing up the repository:");
    // Report the problems (we'll just print them out) ...
    for ( Problem problem : problems ) {
} else {
    System.out.println("The restoration was successful");

Once a restore succeeds, the newly-restored repository will be restarted and will be ready to be used.

Migrating from ModeShape 2.8 to 3.0

Earlier I mentioned that backup and restore can be used to migrate from one version of ModeShape to the next major version of ModeShape. This is how we plan to support migrating from a ModeShape 2.8 repository instance to a new ModeShape 3.0 instance. We plan to cut one more release of ModeShape 2, which we’ll christen 2.8.4.Final, and that will include a utility that will create a 3.0-compatible backup of the ModeShape 2.8 instance. Then, simply use the “restoreRepository” method on the new (and empty) ModeShape 3.0 repository to load all the backed-up content.

Questions or feedback

This feature is still relatively new and was introduced in ModeShape 3.0.0.Beta3, and we’d love to get your feedback on our forums before we freeze the public API and cut the 3.0.0.Final release.

Filed under: features, jcr, repository, techniques, tools

Moving to Maven 3

The ModeShape project is planning to move to Maven 3 for our build system, and away from Maven 2.0.9 (or 2.2.1). We’ve been struggling for quite some time with a number of Maven 2’s quirks, including difficulties with dependencies in our assemblies, and everything we’ve heard is that Maven 3 is a significant improvement all around. Unfortunately, we’ll have to make some changes to our POM files to get Maven 3 working, and once we commit these changes Maven 2 will no longer work. In other words, project developers will have to upgrade their local Maven installations before they’ll be able to build ModeShape.

If you have any thoughts or comments on this effort (especially if you’re opposed!), please let us know by commenting on the JIRA issue.

Filed under: news, open source, tools

ModeShape moves to Git

The ModeShape project’s official source code repository is now at GitHub:

We’re adopting the Fork+Pull method of development. The basic idea is that you first fork the “official” ModeShape repository on GitHub. Then, you do all your development locally, push your proposed changes into your fork, and generate a pull-request describing your proposed changes. The ModeShape committers will review and discuss your changes and pull them into the “official” repository (using this process).

For details on this process, see our ModeShape Development Workflow article. We’ve started a discussion thread for any questions or lessons learned. We’ll hopefully improve the documentation in the coming days and weeks. And to learn more about Git, we recommend the following resources:

Filed under: news, open source, techniques, tools

Announcing ModeShape 2.2

I’m very happy to announce that ModeShape 2.2 is now available. Yes, it’s just a few weeks since releasing 2.1, but we’ve managed to add a couple of great features and fix several bugs. As usual, ModeShape 2.2 is available in the JBoss Maven repository (under the “org.modeshape” group ID) and on our downloads page. We’ve updated our Getting Started Guide, Reference Guide , and JavaDoc.

ModeShape 2.2 has several improvements and new features:

  • Deploying on JBoss AS – We’ve improved the kit for deploying ModeShape into JBoss Application Server introduced as a technology preview in the previous release. It still is as simple as downloading and unzipping into a profile directory. ModeShape will run as a service in JBoss AS, so you can simply deploy applications that use the standard JCR 2.0 API to find and access their javax.jcr.Repository instance. You also get the WebDAV and RESTful services, and use JOPR for monitoring, alerting, and administration. We’ve also added several sequencers to the default configuration.
  • JDBC driver – We’ve improved the JDBC driver that was introduced as a technology preview in 2.1. And it’s now possible to use JDBC metadata, even if the driver is running in a remote process.
  • Teiid relational model sequencerTeiid Designer is a visual tool that enables rapid, model-driven definition, integration, management and testing of data services without programming using the Teiid database virtualization and federation engine. This new sequencer is able to parse parse relational model files produced by Teiid Designer, and extract the structured data model of the relational database design, including catalogs/schemas, tables, views, columns, primary keys, foreign keys, indexes, procedures, procedure results, procedure results, and logical relationships. This means that when these models are uploaded into a ModeShape repository, the sequencer writes to the repository all this relational metadata, where it can be queried and accessed by JCR, RESTful, and JDBC clients.
  • Teiid VDB sequencer – This new sequencer parses the virtual database archive files produced by the Teiid Designer, and extracts the structured relational data model described by each of the contained XMI files. This means that when VDB files are uploaded into a ModeShape repository, the sequencer writes to the repository all this virtual database and relational metadata contained in the VDB, where it can be queried and accessed by JCR, RESTful, and JDBC clients.

There are other smaller features, improvements, and quite a few bug fixes. See the release notes for the complete list.

ModeShape is  lightweight, fast, pluggable, open-source JCR repository that federates and unifies content from multiple systems, including files systems, databases, data grids, other repositories, etc. It implements all of the required JCR 2.0 features (repository acquisition, authentication, reading/navigating, query, export, node type discovery, and permissions and capability checking) and most of the optional JCR 2.0 features (writing, import, observation, workspace management, versioning, locking, node type management, same-name siblings, orderable child nodes, and shareable nodes). That means you can use the JCR API to access the information you already have, or use it like a conventional JCR system (just with more ways to persist your content).

Many thanks to the ModeShape community of users and contributors, who have (once again) shown what a fantastic and active community can do in a very short time!

Give ModeShape 2.2 a try and let us know what you think!

Filed under: features, jcr, news, repository, rest, tools

New Maven repository at recently announced a new Maven repository. The new instance uses Nexus and has a lot of very nice features and a very usable navigation and search web interface.

Those of you using ModeShape in your own applications or projects likely have Maven settings that involve multiple Maven repositories, including the old JBoss Maven 2 repository. This will continue to work (at least for a while), but you should change your settings to use the new repository. And, you will continue to need other Maven repositories for 3rd party artifacts. Chances are, you’re already doing this.

If you are a contributor to ModeShape (or any other project hosted at, you’ll want to use a different configuration that will download all artifacts through the repository (which in this mode will proxy the 3rd party artifacts). This will be faster, plus it ensures these artifacts are always available to JBoss to build our projects/products (even should other 3rd party repositories disappear).

If you have any questions or problems, please let us know on our forum.

Filed under: news, open source, tools

Git and SVN: the beginning

My previous post about Git and SVN hopefully intrigued you enough to want more. Yes, you can use Git locally even though your stuck with using Subversion for the central repository. In this post I’ll show you how to get started, while in the next post we’ll see how the Git Eclipse plug-in.

1. Install Git

You can install it several different ways, depending on your platform and your preference. I have a Mac, so I could download and compile it using MacPorts, or I could grab the latest installer. I like simple, so since I don’t yet have MacPorts I went for the installer. Piece of cake. I also chose to manually set up my path, so in my .bashrc file I added these statements:

export MANPATH=${MANPATH}:/usr/local/git/manexport PATH=${PATH}:/usr/local/git/bin:/usr/local/git/libexec/git-core/

(Okay, I actually used some variables in my real .bashrc to keep things DRY. I thought the above might cut through all that noise.) Note that we added “git/libexex/git-core/” to the PATH. This directory contains all the commands that start with “git-” (e.g., “git-svn …” is really the same as running “git svn …”).

2. Clone a remote SVN repository

The next step for me was creating a local git repository that mirrored the remote SVN repository.

$ git svn clone -s local_dir

The “-s” option tells git that the Subversion repository use the “standard” naming convention of using “trunk”, “branches”, and “tags” directories. When this command runs, it creates a subdirectory called “local_dir”, initializes the git repository in that “local_dir”, connects to the SVN repository at the URL (which does not include “trunk” or any other branch/tag information), proceeds to download all of the history (including branches and tags) in the SVN repository, does some cleanup, and checks out the equivalent of the SVN “trunk” to our working area. And, because of Git’s bridge with SVN, we’ll be able to regularly pull changes from SVN into our git repository, and we can even upload changes we make locally back into SVN.

We now have our new Git repository, so cd into it:

$ cd local_dir

If you look closely, you’ll see a couple of things. First, Git doesn’t proliferate your working area with “.svn” folders. Instead, there’s just one “.git” directory at the top. Git also uses a different technique than SVN for remembering which files and directories should be ignored. But we can bootstrap Git’s ignore information automatically from SVN’s. We’ll use the “.gitignore” file in our working area, since we want this information to be versioned and we want everyone using the repository to be able to use it. If your SVN repository already has a “.gitignore” file, then someone’s done the work for you. Otherwise, you’ll have to run the command to generate the file:

$ git svn show-ignore > .gitignore

This will take a minute or two, depending upon the size of your working area. I would then commit this new file, placing it in the master branch.

3. Committing (locally)

To commit our new file, we first have to tell Git that we want to start tracking this file. Or, in Git parlance, we want to stage the file by adding it to the index:

$ git add .gitignore

We can use the status command to see a summary of what’s already staged, what’s being tracked but hasn’t been staged, and what’s not being tracked at all:

$ git status .

We can also get a more detail report showing all the individual changes that have been staged:

$ git diff

We can then commit our staged changes:

$ git commit -m "Description of commit" .

or, if we want to automatically stage any modified or deleted files, we can add use the “–all” (or “-a”) option:

$ git commit -a -m "Description of commit" .

With the “commit” command, Git records the entire set of staged changes as a single commit to our current branch, and it moves the branch’s HEAD pointer to this last commit. Remember, Git works locally, so this commit is recorded locally. This may sound strange at first, but really it allows you to commit (locally) much more often, which can improve your development process since backing out things that don’t work is really easy.

To see the history of commits, use the “log” command

$ git log

This displays each time, message, and SHA-1 hash (the unique identifier) for the last n commits. You can use these hashes (or the first 4 characters or so) in the diff command.

$ git diff <hash>

displays the difference between a previous commit and changes, while:

$ git diff <hash1> <hash2>

displays the difference between two previous commits.

There are a lot of things Git can do – way too many to cover here. But look at “git bisect”, “git grep”, “git revert” jut to name a few. But let’s get back to our workflow.

4. Updating from Subversion

If you’re familiar with Subversion, you’re hopefully used to doing “svn update” before committing your changes. This pulls any revisions that others have made since you last updated, and its good form to do this and to make sure everything compiles and runs locally before committing.

In Git, you do this with the “git svn rebase” command. This command fetches revisions from the SVN used by the current HEAD (of the current branch), and “rebases” any current commits on the branch to apply to these latest SVN changes. This is analogous to creating a patch file for each local commit (relative to that commit’s parent) since the last rebase, updating the branch with the new SVN revisions, then sequentially applying the patches. In other words, it takes all your local changes (in the form of commits) and reapplies them to the latest SVN revisions.

Here’s the actually command to rebase the current branch:

$ git svn rebase

If you want to fetch all of the revisions on all branches in the SVN repository and rebase any local commits on those branches, you can add the “–fetch-all” option.

5. Committing back to Subversion

Once you have rebased your local commits on a branch, you will still have changes to that branch that aren’t yet in Subversion. We want to do the equivalent of an SVN commit, which in Git is to commit each diff on the branch back to SVN:

$ git svn dcommit

This creates a new revision in SVN for each local commit on the branch. Of course, if you want them to look like a single revision, you’d need to squash the commits before running the dcommit command.


This post focused mostly on how to get started with Git using a remote Subversion repository, so I didn’t talk much about how to go about branching and merging. I think you’ll agree, though, that Git’s Subversion bridge seems very intuitive, and in fact many of the same concepts used by the Subversion bridge are the same concepts used by the rest of Git. And once again I’m going to suggest reading the Git Community Book or watching Bart Trojanowski’s presentation.

Note: Portions of this post were taken from a previous post on my personal blog.

Filed under: techniques, tools

Git it together with Subversion

This is the first in a series of posts about how I use Git to work on JBoss DNA. Like many other projects, all of the code for DNA lives in a central Subversion repository. And for a long time, I naturally used a combination of the Subversion command line client and the Subversive Eclipse plug-in.

Git works a little differently than SVN. Git is a distributed version control system, and that means that you have a local copy of your project’s Git repository. Yup, the whole thing. But that’s a game changer, because you can commit, branch, view history, or whatever while your disconnected from the web. And it’s fast (since everything is done locally) and surprisingly space-efficient. Then, when you’re ready, you can push or pull changes to other Git repositories.

Git also works really well pushing and pulling from a remote SVN repository. In fact it’s built right into Git. So if your remote repository is SVN, you can still use Git locally. The only difference is how you push to and pull from the remote repository.

What really convinced me to try Git, though, was how brilliantly it does branching. Actually, branching and merging. Quite a few source control management systems can branch, but the problem is they don’t merge – or if they do, they don’t do it well. Git, on the other hand, makes merging easy. In fact, it’s really easy to create branches, switch between branches, and merge branches.

So why am I so hung up on branches? Well, being able to branch and merge means that I can use branches for everything – bug fixes, new feature work, prototypes, or maintenance. I can create a branch where I do all my work, and I can commit as many times as I want. I can even use tags to help me remember important commits (e.g., “all tests pass”). And when my work is complete, I can merge my changes onto as many branches as I need to. All of this is done locally, without polluting the main repository’s trunk or branches. Of course, if I’m working with other people on a feature or bug (e.g., “please review these changes and provide feedback”), I could expose my own repository or we can leverage a shared repository. And when the work is all complete, merging onto the official branch(es) is cake, too.

In forthcoming posts, I’ll show how to install and use Git with a central Subversion repository, describe some of the tooling I use with Git, and outline a number of very common use cases: simple branching and merging, stashing your work to fix a bug, and so on.

Until then, if you want to learn more about how to use Git, watch Bart Trojanowski’s presentation. It is 2 hours long, but it really is a brilliant tutorial if you’re interested in learning the fundamentals how Git works and how to use Git.

Portions of this post were taken from a previous post on my personal blog.

Filed under: techniques, tools

AtomPub, REST, repositories … and Starbucks?

InfoQ has a great article on how REST and AtomPub work, using a “Starbucks” example. (Via Joel Amoussou.)

One thing this article does well is explain how representations can contain URIs for followup activities (e.g., what can be done next with a resource). In addition to the “next” used in the article, activities might include undoing the last change, or “publishing” some artifact. This works extremely well when coupled with some sort of state transition (process) engine on the back end and allows clients to “discover” the process, even when that process changes! And note that the process might include lifecycle changes and/or workflow.

Now, how does REST and AtomPub relate to JBoss DNA and JCR repositories? Well, it’s always useful to have a REST API into a JCR repository. For the most part, I think a generic repository library like JBoss DNA will provide a generic REST interface. After all, working with a JCR repository doesn’t have a lot of process – it’s mostly just simple get/post/put/delete operations on the nodes (resources). But AtomPub only defines three levels (services, collections, and entries), and this doesn’t really map well to a hierarchical repository. (Yes, I could conceive of several different mappings, but the question is whether any of them really are useful.)

So while a content repository system might not provide a generic AtomPub, a domain that uses a JCR repository may very well want to use AtomPub to allow clients to work with the domain’s content. Consider a SOA governance repository, which may have multiple collections (e.g., “services”, “published services”, “news”, “policies”, etc.), and workflow (e.g., uploading a service, publishing a service, etc.). Here, AtomPub can be mapped to the SOA governance domain pretty easily, but this mapping is probably different than other domains.

It would be nice if JBoss DNA could have a generic “AtomPub” facility that is content-driven: specify the collections (maybe defined as queries), map the entities to workflow processes, etc. But that’s getting ahead of ourselves. First things first.

Filed under: rest, techniques, tools

JBoss DNA is on Ohloh

The JBoss DNA project is now on Ohloh, which offers a pretty cool analysis of open source projects. If you’re a user, have a look and give us a vote. Or, if you’re a contributor, go to the contributors list and click on your name to claim your commits.

According to their analysis, we have 140K lines of code containing almost 74K lines of Java and 52K lines with comments. Oh, and remember that they’re including all the test resource files and DocBook source, which is why they’ve listed the languages to include Flex, XML Schema, JavaScript, CSS, etc. Here are the latest stats:

Filed under: tools

ModeShape is

a lightweight, fast, pluggable, open-source JCR repository that federates and unifies content from multiple systems, including files systems, databases, data grids, other repositories, etc.

Use the JCR API to access the information you already have, or use it like a conventional JCR system (just with more ways to persist your content).

ModeShape used to be 'JBoss DNA'. It's the same project, same community, same license, and same software.