Apache JCR Commons

In the Apache Jackrabbit project we've decided to create a new JCR Commons subproject for developing and managing the set of generic JCR tools that has grown over time around the core Jackrabbit content repository implementation.



The JCR Commons subproject will to some extent resemble the Apache Commons project, and I'm hoping to use some of the ideas put forward by Henri in his blog post about a "federated commons".



I'm hoping to flesh out the details of this new subproject over the next month or two. It would be nice to have releases of all the new JCR Commons components ready to be used as dependencies for the upcoming Jackrabbit 1.6 release.

Changing IT landscape

Here's the latest top five list of countries with most monthly visits to the jackrabbit.apache.org web site:

1. United States


2. Germany


3. China


4. France


5. India

India just replaced United Kingdom on the fifth place, and while China is still far from the United States and Germany, it's rapidly closing the gap.

It was very interesting to hear tidbits from the recent Apache Meet Up and BarCamp Beijing events. I heard rumours about a potential followup event next year. I hope I'll find a good excuse to attend...

Apache Jackrabbit 1.5.0 released

Apache Jackrabbit 1.5.0, the latest and greatest release of the best content repository I know, is now available! Get it from the Jackrabbit web site or through the central Maven repository while it's hot!



The most notable changes since version 1.4 are:

• The standalone Jackrabbit server component. The runnable
  jackrabbit-standalone jar makes it very easy to start and run
  Jackrabbit as a standalone server with WebDAV and RMI access.
  


• Search performance improvements. The performance of certain kinds
  of hierarchical XPath queries has improved notably.
  


• Simple Google-style query language. The new GQL query syntax
  makes it very easy to express simple full text queries.
  


• Transaction-safe versioning. Mixing transactions and versioning
  operations has traditionally been troublesome in Jackrabbit.
  This release contains a number of improvements in this area and
  has specifically been reviewed against potential deadlock issues.
  


• Clustered workspace creation. A new workspace created in one
  cluster node will now automatically appear also in the other
  nodes of the cluster.
  


• SPI improvements. The SPI layer introduced in Jackrabbit 1.4
  has seen a lot of improvements and bug fixes, and is shaping
  up as a solid framework for implementing JCR connectors.
  


• Development preview: JSR 283 features. We have implemented
  a number of new features defined in the public review draft of
  JCR 2.0, created in JSR 283. These new features are accessible
  through special "jsr283" interfaces in the Jackrabbit API. Note
  however that none of these features are ready for production use,
  and will be replaced with final JCR 2.0 versions in Jackrabbit 2.0.
  

See the release notes for all the details.

Flashback: SusiSGML, Midgard, and Cocoon

Heikki wrote a nice post about how the Midgard project got started some ten years ago.  Bergie's comment also a briefly mentions the SusiSGML system that we used before Midgard.

SusiSGML was a custom SGML vocabulary with a set of DSSSL stylesheets that we used to cook the structured content into HTML with styling based on tables and all that stuff one used before the CSS revolution.

Architecturally SusiSGML was pretty much like early versions of Apache Cocoon, only with SGML and DSSSL instead of XML and XSL. Had we been at it a few years later, Midgard might have been based on Cocoon. :-)

My home away from home

Since July I've had two homes, one in Switzerland and one in Finland. I now live in Basel, Switzerland where I have a nice apartment within walking distance from the old city center and the Day office where I work. Since arriving here I've spent countless hours walking and biking around Basel and neighbouring areas, so I already feel pretty comfortable with the surroundings. Basel is just the kind of place I like, a beautiful city with lots of history and details to discover. And the rest of Switzerland isn't too bad either. :-)

My other home is back in Finland where Kikka, my future wife, and our two cats, Juuso and Nöpö, live cozily close to the nature. I fly back to stay with them for roughly a week per month, and meanwhile we call each other frequently. I especially love the skype video feed on our cats. This month I'm not flying to Finland, as a week ago Kikka visited me here in Basel and next week we're both heading to Turkey for a week of vacation together. 

Kikka is staying in Finland until she finishes her PhD studies at the sleep lab in Helsinki. She's doing some kick-ass research on the neurobiological mechanisms of sleep, and while at times I find myself understanding little of what she does, it still sounds totally awesome. I'm so proud of her.

I guess it's still too early to tell how well this living more than a thousand miles apart thing will work out, but so far I think we're doing great. I feel that the time we spend apart just makes our days together more special.

git clones of Apache codebases

In the past few months we've been discussing on the infrastructure-dev mailing list about various ways of extending or improving the version control functionality available to Apache projects. One of the main themes of the discussion has been making it easier to access Apache codebases using git or other distributed SCM tools.

The new svn.eu.apache.org mirror that was recently announced supports git-svn use when accessed as an authenticated user over https. Unfortunately that access is limited to Apache committers and git-svn can be notoriously slow when making initial clones of complex codebases in svn.

To work around these issues I set up a collection of git mirrors of selected Apache codebases on my server. You can find these unofficial mirrors at http://jukka.zitting.name/git/. The mirrors are automatically updated daily.

The mirrors work pretty much like normal git repositories in that you don't need git-svn or any other svn tools to work with them. The only significant difference to normal git repositories is that svn tags are mapped to branches named "tags/..." in the mirrors due to the different way git and svn handle tags. Also, settings like svn:ignore, svn:eol-style, etc. are not replicated in these git mirrors.

Let me know if you're interested in seeing other Apache codebases mirrored. I'm also interested in other feedback or ideas related to these git mirrors.

Locales vs. consistent builds

[MOJO-1193] Locale support for formatting dates and times

I wanted to use the Maven buildnumber plugin to generate a date string like "31-Jul-2008" for inclusion in an automatically generated release notes document. This way I could minimize the amount of manual tweaking I need to do when publishing the release.

This was easy enough (though quite verbose) to achieve:

    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>buildnumber-maven-plugin</artifactId>
      <configuration>
        <format>{0,date,dd-MMM-yyyy}</format>
        <items>
          <item>timestamp</item>
        </items>
      </configuration>
      <executions>
        <execution>
          <phase>validate</phase>
          <goals>
            <goal>create</goal>
          </goals>
        </execution>
      </executions>
    </plugin>

Unfortunately, the resulting date string would be the expected "31-Jul-2008" on one computer, but "31-heinä-2008" (in Finnish) on my laptop. Instead of changing the settings of my laptop I wanted to explicitly set the locale that the buildnumber plugin should use when formatting the date. I wasn't too surprised that the required functionality didn't yet exist (it's quite common for people to forget about locales), but luckily it wasn't too hard to add. Thus MOJO-1193.

With my patch the required configuration becomes:

      <configuration>
        <format>{0,date,dd-MMM-yyyy}</format>
        <locale>en_US</locale>
        <items>
          <item>timestamp</item>
        </items>
      </configuration>

Consistency is good.