Redmine has many of the features I like from Trac, such as the Roadmap view, version control integration, an Activity view, and built in Wiki.  It also has a bunch of plugins, one of which looks like it’ll generate burndown charts, which I’m planning to use.

It looked like Redmine was fairly well supported on Windows (box I have available) so I decided to try it out.  Redmine is based on Ruby on Rails, so the first step to installation is to get Ruby and Rails installed.

I started off trying to install Ruby and Rails under cygwin, but ran into problems with building mysql from source (no cygwin port for this!).

So instead I went down the route of installing everything outside of cygwin.  Here’s a summary of the steps:

• Install the Windows Ruby binary, along with Gem package system.
• Install the Rails 2.1.2 gem, which Redmine 0.8.X depends on
• Download and unpack the Redmine distribution
• Setup the database (running on MySQL in my case) and edit database.yml per instructions.
• I had to install older MySQL client library due to some Rails/MySQL library incompatibility (described here)
• Create the database schema for Redmine via:

  rake redmine:load_default_data RAILS_ENV="production"

• Populate a default configuration via:

  rake redmine:load_default_data RAILS_ENV="production"

• You can then run Redmine via:

  ruby script/server webrick -e production

By default, war files are packaged with all of the libraries they use embedded within them.  This is fine, unless your application uses a large number of libraries, and you have more than one war file within your enterprise application archive (ear file).  In that case, you’re causing the JVM to load the same set of classes multiple times, once for each war, which can use up a significant amount of memory, and bloating the size of your ear file.

In a skinny war configuration, the libraries are packaged at a higher level, within the ear file itself, and the war files are made to reference the libraries packaged within the ear file within their MANIFEST.MF file.  The classes are loaded once, and can be used in multiple web applications bundled in the ear.

Unfortunately, this isn’t directly supported in Maven, although there are workarounds.  As this page states, “The Maven WAR and EAR Plugins do not directly support this mode of operation but we can fake it through some POM and configuration magic”.  The workaround is to list the jars in each war, but tell Maven to exclude it from the WEB-INF/lib and to add references to the jar in the MANIFEST.MF file.

The ear file Maven project then needs to list every library it will package as a dependency.  This means that common libraries will be listed in the ear project, and each war project that uses them, causing quite a bit of bloat in the Maven project files.

This wiki page has a good description of the situation, some alternate solutions, and requirements for a long term solution.

Ideally, I’d like to be able to take the same Maven war project file, and build for standalone deployment (fat war), or deployment within an ear project where the common libraries are included once in the ear file (skinny war), without having to change the Maven war project file.

For this to work, I think the ear project would have to control whether and which war project libraries are pushed up to the ear project.  The ear project file could explicitly list those libraries that should be bundled in the ear, or it could have an option where it calculates the common libraries across the contained war files, and automatically bundles them in the ear file.  As the link above indicates, the ear project would have to have the ability to rewrite the manifest entries of the contained war projects.

Technorati Tags: maven java j2ee

I’ve been using Mercurial to work on a couple projects I’m involved with that have Subversion repositories. GIT has a good bridge to Subversion built in. Unfortunately, Mercurial is a little bit behind on this front, but it looks like things are getting better quickly.

I initially tried out Tailor, a general purpose version control bridge tool, which supports Mercurial and Subversion among a bunch of others. I had difficulty getting Tailor to work with the Subversion repository I was working on, and it didn’t seem like Tailor was being used much for Mercurial-Subversion.

I’ve been using the hgsvn package lately and it’s worked out pretty well. The only caveat is that hgsvn doesn’t directly support uploading changes from Mercurial back to Subversion. hgsvn does a good job of downloading changesets from Subversion to Mercurial though, and there are a couple solutions to handle the other direction. I’ve been pushing changes back by using the excellent Mercurial MQ extension.

A new Mercurial-Subversion bridge, hgsubversion, looks like it supports both downstream and upstream changes from Mercurial to/from Subversion, and looks very promising. I’m just waiting for it to support importing starting at a particular Subversion revision before I can start using it.

Until I can use hgsubversion, here is how I’ve been using hgsvn. I installed hgsvn as a Python egg package via easy_install:

sudo easy_install hgsvn

The hgimportsvn command is used to import change sets from an existing Subversion repository into a local Mercurial repository it creates. You can optionally have it start at a particular Subversion revision if you don’t need the full history imported:

hgimportsvn [-r svn rev] <svn URL> <local directory name>

This creates a combined Subversion working directory and Mercurial repository in the local directory you give it. Once this is done you can update the Mercurial repository with the latest Subversion changesets by executing the following in the local directory:

hgpullsvn

You run hgpullsvn anytime you want to refresh the Mercurial repository with the latest from Subversion. You can then do anything you would do with a Mercurial repository, except committing changes of your own. Cloning, MQ, revision histories, diffs, etc all work. I tried committing a change to the Mercurial repository, then committing the same changes to Subversion, then doing an hgpullsvn to update both from the Subversion repository. This worked at first but the Mercurial repository got out of sync after a while, so I wouldn’t recommend it.

What I’ve been doing is managing the upstream changes via Mercurial Queues (MQ). This also helps me manage patches I want to apply on top of the latest code.

The first time using Mercurial Queues in a repository, you have to initialize the queue repository:

hg qinit -c

The -c option makes it so the queues repository is version controlled. You can then see what older versions of a patch were in case you need to roll back. I’m basically using patches as changesets, so it’s useful for me to be able to version control and have a history for them.

Once you have the queue repository, you can create a patch before making any changes to files:

hg qnew -g <patch name>

When you create a new patch, it automatically becomes an active patch at the top of the queue. You can then edit files as you normally would. ‘hg add’ and ‘hg remove’ commands mark files to be added or removed in the patch.

Once you’re ready to commit any changed/added/removed files to the patch, do a commit:

hg qcommit

Once committed, you can look in your .hg/patches/ directory and see the patch file.

Whenever I want to update from SVN, I pop everything off the patch queue so the Mercurial repository & Subversion working directory are pristine, and do the update:

hg qpop -a

hgpullsvn

I can then push the patches I’m working on back on top:

hg qpush -a

Whenever I’m ready to push changes into Subversion, I export the patch, then apply it to a separate Subversion working directory for commit:

hg export -g <patch name> > ../my.patch

in separate Subversion working directory,

patch -p1 < ../my.patch

The best editor for these formats I’ve found is XMLMind XMLEditor. Here is information on using XMLEditor to edit XDoc documents. The latest version of XMLEditor supports DocBook v4 and v5 out of the box, and support for Dita can be downloaded as a plugin. Currently I’m leaning towards using DocBook for technical documentation due to its wider support, although Dita sounds interesting.

Change management is one of those software software development practices that I rarely see implemented in IT projects, although it helps to organize development and cuts down on the more tedious project management activities (gathering status, updating detailed project plans). Change management is similar to defect tracking, which is frequently used, but is broader is scope. Defect tracking is really a subset of change management.

In a change management process, every proposed and actual change to an artifact is recorded and tracked in a change management tool. I say artifact rather than code because it can be used to track changes to requirements, test scripts, documentation, design; not just code. Every change to an artifact and commit to VCS has an associated record in the change management tool associated with it, describing the nature of the change, who requested it, what release it was planned for, etc.

Open source projects seem to more frequently use change management, which isn’t surprising considering they are made up of distributed teams who need a good way to keep track of what changes are planned for, and tracking the progress of those changes.

There’s a bunch of open source change management tools out there. Roundup, JTrac, XPlanner, Scarab, Mantisbt, ITracker, Trac, and Bugzilla are the tools I took a look at.

I have several criteria for a change management tool, including:

• Ability to link one change request to another
• This can be used to set up dependencies between changes or defects (this bug has to be fixed before that one can) or to break up large changes into smaller ones to be worked on by different people (e.g. have a change request to track the development of a feature, linked to smaller change requests to track the changes to implement the feature).
• RSS feeds for reports/searchs
• Support for representing enhancements and defects
• Support for components, with the ability to assign change requests to components, and to assign owners for each component
• Easy to administer – Ability to administer products, components, and users through a web UI
• Ability to authenticate against LDAP
• Active development community
• Easy to use, web-based on-demand reporting and charting
• Can run on Windows (it’s the box I have)
• Support by Mylyn

I narrowed the choice down to Bugzilla and Trac, and settled on Bugzilla after installing both. I’ve used and installed Bugzilla before, so I was already pretty comfortable with it. The Bugzilla Windows installation has come a long way since the last time I tried it (~2001). Back then I gave up and ended up installing Linux on a box just to be able to run Bugzilla. It still requires quite a few steps, but it worked without too much trouble.

I installed stable version 3.0.4 following the instructions at http://www.bugzilla.org/docs/win32install.html. At a high level, the steps were:

• Download and unpack tarball
• Install MySQL 5.0.51a
• Create Bugzilla database and database user
• Installe ActiveState Perl 5.8.8
• Installed a bunch(!) of Perl packages via bundled PPM tool
• Install & Configure Apache 2.2
• Had to upgrade Email and Mime related Perl packages (see this blog posting).
• Download and install Graphviz, and tell Bugzilla where the ‘dot’ executable can be found (Bugzilla parameters->Dependency Graphs)
• Execute perl collectstats.pl (not sure if this is doing anything)
• I had to execute the following to get graphical reports to work: ppm install Template-GD

What got me to try it out was the Groovy/Grails support. I’ve been doing some work with Grails and had heard they had a good plugin. After working with it a while, the Groovy support is the best out of the three major Java IDEs (Eclipse, NetBeans, IDEA). The Maven 2 support is great too.. It’s by far the best support for Maven 2 in any IDE. There are some features I would still like them to add (such as a Maven repository index/search feature), but the important things work well (handling Maven dependencies).

In general, I find myself having to fiddle with the UI less than I do with Eclipse (configuring and switching perspectives, resizing panes, etc).

The other plugin I was really interested in was the Mercurial IDEA plugin. This plugin is still early in the development cycle. Unfortunately it gave me an error when starting up – it was compiled for JDK 1.6 and I’m stuck with 1.5 on my Mac. I imported the MercurialIdea plugin source into Idea, reset it to use the Idea platform runtime, and rebuilt the plugin without success. No biggie, the Mercurial command line is easy enough to use.

At the end of this month, Yahoo will be supporting OpenID. Any Yahoo user that chooses to enable the feature will be able to use their Yahoo ID on sites that support OpenID. The announcement doesn’t mention Yahoo accepting OpenIDs from other providers, so this is probably only one-way for now. So put together the population of Yahoo users which are now getting OpenID support, and AOL users, which have had it for a while, and you have a pretty large chunk of the web population that have OpenIDs (once they enable them anyways). Now we need more websites to accept OpenIDs from other providers.

I’m waiting for Acegi to support OpenID so I can build support into a webapp I’m working on. Looks like there’s been some recent progress on that front.

Another OpenID related, if a bit old, tidbit – MyOpenId now supports Information Card as a means to authenticate with MyOpenID. So when prompted to authenticate to MyOpenID, you can present an Information Card and authenticate without using a username or password at all.

After looking into both, I ended up going with Mercurial over GIT. Both Mercurial and GIT seem to fit my needs; decentralized, fast, and flexible, but GIT didn’t seem as well supported on non-Linux platforms and the Java IDE plugins are further behind. Mercurial has binaries available for Mac, Windows, and of course Linux. On the Mac and Windows side, there are a couple different options for how to install Mercurial; using a ports packaging system such as Cygwin on Windows or MacPorts on Mac, or installing natively on the OS. The Eclipse IDE plugin is still early in development, but it sounds like the NetBeans plugin is pretty full featured.

When working with Mercurial, everything is a copy of the repository, including branches and the local repository that developers work out of. Each repository is as fully capable as any other and includes all of the change history. It sounds inefficient to have a full copy of the repository on each workstation, but it turns out that Mercurial repositories are usually smaller than a Subversion working directory. This is partly because Mercurial stores changes to files in a very efficient manner, and partly because Subversion stores a significant amount of extra data in a working directory in order to avoid accessing the server for some operations.

In Mercurial, changes to files are committed to a local repository as a unit of work, called a change set. The change sets can then be pushed or pulled from other repositories in order to share work with others. It’s then up to you how you organize your work and manage the exchange of change sets between repositories. You can have a single master repository that everyone pushes/pulls from, you can have multiple masters for better performance and reliability, you can have a hierarchical model where committers receive change sets from the community, then pass it up to module owners, who pass them up to release owners (from what I’ve heard the Linux Kernel is organized in this way), or even have no master and have members of the team exchange change sets directly with each others’ repositories (this sounds like too much work though).

Most of all, I was impressed with Mercurial’s attention to details in their design decisions:

• Mercurial never makes updates to a revision log of a file, just appends to it. This minimizes the opportunities for data getting corrupted; if you never update or delete data, there is very little chance of it being accidentally corrupted beyond repair.
• Mercurial stores the diffs to files (text and binary) rather than storing the full copy of a file for every revision. It then “replays” the diffs in order to reconstruct the full copy of a revision of a file when needed. This is much more efficient than it may seem, but after a large number of changes it can become expensive. To compensate for this, Mercurial stores a snapshot copy of a file revision for fast access when the chain of diffs becomes too long.
• Minimize locking – read and update operations have been ordered in such a manner that locking isn’t necessary for most commands. Reads and clone/pull operations don’t lock the repository at all. Mercurial uses locks to ensure only one process writes to a repository at a time, but read and clone/pull operations are not affected by this.
• Minimizing filesystem seek operations – Seek operations are relatively expensive, so Mercurial has been designed to minimize this. This is one of the reasons that Mercurial keeps repository metadata in a single directory (.hg at the root) rather than stored with each directory as Subversion does (.svn directories) – having separate metadata directories would require a seek for every directory.

I’ll follow up later with a post on setting up & working with Mercurial.

In a centralized version control system, there’s a single repository that tracks the changes to all files, and any version control operations (check out, commit, merge, etc) must go through the central repository. Lately I’ve been tracking the decentralized version control systems that have come out and have been getting attention. As the name implies, in a decentralized version control system, there isn’t a single central repository and server responsible for tracking changes to files. In a decentralized version control system, you can have any number of repositories tracking changes to the same set of files. Each repository is as fully capable as the next and able to carry out all of the version control operations (commit, checkout, merge, etc) on the files. No repository is inherently more important than another. The changes to files (change sets) can be pushed and pulled from one repository to another. Although no repository is inherently more important than another, when teams work with decentralized version control systems, they typically designate one repository as the “master” repository to which all changes ultimately get pushed and from which other repositories can pull changes. Another variation on this is to have two or more “master” repositories which exchange change sets between them. This model of having multiple repositories extends all the way down to the workstation. In most decentralized VCSs, developers work off a local repository, which is just as full fledged and capable as any “master” repository.

There are several real world “itches” I experienced that got me looking into decentralized version control systems:

Working offline

I sometimes work somewhere that doesn’t have a connection to the central Subversion repository – either I’m working somewhere without an internet connection, or don’t have a connection to the internal network where the Subversion repository resides. This is actually not that uncommon for me. With a central repository, this means I can’t rename files in Subversion, commit changes, create a new branch to work on an independent change, merge work, etc. I’m basically limited to editing files without renames/moves. With a decentralized VCS, I could do everything I can do with a central repository while disconnected, because every developer has a full fledged repository they are locally working from. When I’m again connected with the “master” repository, I can push my changes up to it.

Delays in getting central VCS repository set up

Sometimes getting a new repository added to a centralized VCS for a new project can take quite a while. The repository has to be set up, permissions have to be granted, and the person responsible for it may be out, or have a million other things to do. Until the repository is set up, the team has to share source code by some other means (email, etc) which is error prone and no versioning information is captured. With a decentralized VCS, a team could start working together using their own repository, then push all of the changes into a “master” repository when it becomes available. The team is able to get work done without being blocked, and the system administrators are able to control access to the authoritative VCS.

Distributed teams with poor network access

When working with distributed teams, the network access for offsite teams has frequently been average to poor. Sometimes connectivity to the central repository goes down altogether, and when connectivity is up, operations such as commits, merges, and updates from the repository are painfully slow. Teams work around this by falling back to sharing code via email (error prone, cumbersome), or holding off sharing changes, which makes for muddled commits and makes integration more difficult.

Moving a repository from one server to another

Sometimes you need to switch a VCS repository from one server to another; maybe the server needed to be used for something else, a more powerful server was needed, or the VCS repositories were being consolidated onto fewer servers. With a centralized VCS, when this happens, the entire team needs to switch over at the same time. This means that any changes that are going on have to be committed (hopefully they don’t break the build), the repository has to be copied over to the new location, the continuous integration process needs to be switched over, and all developers need to switch their workstations to point to the new repository. Needless to say this disrupts development and incurs a real cost.

With a decentralized VCS, the new repository could be set up with a copy of the old repository while the old repository is still being used. The continuous integration process and developers could gradually switch to the new repository when practical (e.g. after completing development of a story). All the while, the new repository can pull any changes that are committed to the old repository, ensuring the new repository is up to date. You could also have changes committed to the new repository flow back to the old repository while it is still in use. Whenever you have migrated all of the processes and people to the new repository, the old repository can be turned off. Everything has switched over without disrupting development.

Repository going down

Unfortunately, VCS servers do go down, more frequently than it seems they should. Usually you just need to restart the server process, but sometimes hardware failures can take the repository down for longer periods. If you are diligent about keeping backups of your repository, maybe you can get back up and running without much delay. The worst case of this I remember was when using ClearCase in a large development team where everyone used virtual views, which was recommended by the ClearCase admins. When the ClearCase server went down, no one could even access their code (since the files are served up from a virtual filesystem by ClearCase), so most of the development team just went home after a couple hours of being down. I’ve heard that ClearCase virtual views aren’t recommended for this reason, but I don’t know enough about the intricacies of ClearCase to say.

If using a decentralized VCS, you can set up one or more mirrors of the main VCS repository, so if one goes down, people can use one of the others without interrupting development. Also, since everyone has a full repository on their workstations, it’s pretty easy to clone one of those repositories and set up a temporary main repository for everyone to push/pull changes to. But for short outages, the development team likely won’t even notice since people mostly work off their local repository and holding off from pushing changes to the main server for a while isn’t a big deal. In short, a decentralized VCS is much more fault tolerant than a centralized VCS.

There are several capable decentralized version control systems available, including Bazaar, Mercurial, SVK, GIT, and more. Some of these are being used on major open source projects such as the open source JDK, OpenSolaris, and the Linux kernel.

Since this post is getting lengthy, I’ll follow up with another post on my experience after having switched to a decentralized VCS.