11/08/2004 update: The project is about to start on Codehaus and is now named Cargo.

Note: There is also an article and a discussion thread on TheServerSide about this inititative

Here's a new idea for an open source project I'd like to start. It could be called CCI (Container Client Interface). It would aim at providing a simple Java API to start/stop/configure/deploy Java containers (In the first version the goal would be to support J2EE containers). This Java API could then be used by lots of other projects (Ant tasks, Maven plugins, IDE plugins, Cactus, etc).

The inspiration comes from the Cactus project, which already provides an extensive API to perform such tasks. The goal is to refactor the Cactus Ant API, remove anything related to Cactus and make it a standalone project called CCI

Here's an integraton test showing what the API could look like:

    public void testStartWithOneWarDeployed()
    {
         Container container = new Resin3xContainer();
         container.setHomeDir("/apps/resin-3.0.8");
         container.setPort(8080);
         container.setInstallDir(new File("target/resin3x"));
 
         WAR war = new WAR("src/testinput/simple.war");
         URL pingURL = new URL("http://localhost:" + PORT + "/simple/index.html"); 
         war.setPingURL(pingURL);
 
         container.addDeployable(war);
 
         ContainerRunner runner = new DefaultContainerRunner(container);
 
         runner.start();
         assertTrue("Container not started yet!", new HttpUtils().ping(pingURL));
         
         runner.stop();        
         assertFalse("Container not stopped yet!", new HttpUtils().ping(pingURL));
     }

As you can see there are several main Objects/Interfaces:

• Container: This the main object that provides the API to start/stop the container.
• WAR: A WAR archive to be deployed in the container. Inherits from Deployable. There will be other types later on (WAR, EAR, RAR)
• ContainerRunner: Athough a container can be start ed without a container runner, the container runner provides advanced feature like starting the container in a different thread, verifying if the container is already started, waiting till the container is started, waiting till the container is stopped, etc.

Note that the ping URLs are the URLs that will be pinged by the ContainerRunner object to ensure the container has finished starting. Thus, after container.start() has finished executing you can be sure the container is started and the archives have been deployed and are ready for servicing requests. A better solution in the future will be to use JMX to ensure the container has finished starting. However, all containers do not yet support this feature.

A shorthand code version to start Resin 3.0.8 could look like:

        Container container = new Resin3xContainer("/apps/resin-3.0.8");
        container.setInstallDir("target/resin3x");
        container.addDeployable(new WAR("src/testinput/simple.war"));
        container.start();

This is just a taste of what he CCI API could look like. Let me know what you think!

I've just released a Maven plugin for Abbot. Abbot is a Swing unit testing framework. The Maven Abbot plugin supports the following:

• Ability to start the Abbot Costello editor using either jars defined in the POM or the jars from an already installed WebStart application.
• Ability to execute Abbot XML scripts through the Ant <junit> task
• Ability to execute Abbot XML scripts on an already installed WebStart application (end-to-end functional testing)

You can download the Maven Abbot plugin here.

Please note that this plugin was written jointly with Christian Blavier whom I thank very much for his help!

Here is a list of OSS stuff I'm considering doing in some short future (note that I'm not planning to do all of them ;-))

• Cactus v2
• Create a container OSS project that offers a Java API to configure containers, start/stop them and deploy archives. The idea is to extract the existing API from the Cactus project (which already supports these tasks for several containers: Tomcat, Orion, Resin, JBoss, WebLogic, etc). Cactus would be refactored to use this new project. This API would be nice for any other project that requires a container.
• Implement a Maven plugin for Clirr. Note: I have almost finished a first version.
• Implement suppor for history reports in Maven. For example it would be nice to get Clover reports over time, Checkstyle reports over time, Dashboard reports over time, etc. I'm currently thinking to consider reports as project artifacts and store them in the Maven repository. A history plugin could provide support to save/load them. Another solution (probably better) involves using a lightweight database (e.g. Hypersonic SQL) and considering this database file as the artifact.
• Continue adding support for RSS feeds to the existing Maven plugins, wherever it makes sense. The final idea is to offer RSS feeds to all project information so that project members can have their own Personal Project Information Portal (PPIP). Among the tools I like/use, RSS feeds are already available for: JIRA, Confluence/TWiki, FishEye, Maven Checkstyle plugin, Maven Changes plugin. Next in my list are: Maven Clover report, Maven Dashboard plugin, Maven PMD plugin, Maven XDoc plugin (for downloads).

In addition to this, I plan to continue fixing Cactus v1 bugs (albeit slowly...) and continue fixing bugs and adding enhancements to the Maven plugins I have started (changes, clover, abbot, etc).

If you're working on the same topics or if you're interested in contributing, please let me know!

The need for source code communication

When you're working in a team one of the most important aspect of development is to know what others are working on, what they are modifying. Indeed, in development everything is tied one way or another:

• if someone changes the database schema, I need to know
• if someone updates a build dependency to a newer version of a framework I need to know
• if someone changes a public API, I need to know
• if someone starts working on the same set of source files as mine, I need to know
• if someone modifies a best practice document, I need to know so that I can have a look at what's new

Basically, I need to know whenever some source file on which my work depend on is modified.

Of course, I could rely on verbal communications: "Hey Joe, I'm gonna work on this files for the coming 4 hours". Sure, that'll work too. However it's not a scalable solution (Imagine a project divided in 5 teams of 10 persons each) and it works only if the participants are acutely aware of what each developer is depending upon which is near impossible. In addition, if the team is distributed it becomes virtually impossible to communicate such small events in any efficient manner. There has to be a better solution.

And there is! There are actually 2 solutions I know of, one better than the other.

Solution 1: Diff emails on SCM commit

This first solution involves setting up a server-side hook in your SCM. Most SCMs supports executing a script upon source check-in/commit. Just write a script that sends an email containing the diffs between what the user is committing and what already exists in the repository. The reason for the diff is that we're interested by what's different and not by the full content. This is what is done in most open source projects. Here's an example:

The problems with this solution are:

• It's not very easy to let the developer choose finely what files/directories they want to monitor
• The diff information is received in your email, among all you other emails. It's good to reserve emails for actions that you have to perform. Here we're not talking about actions but about information. I believe a better channel for information is for example a RSS feed. It still comes to you but it does not clutter your other emails.

Solution 2: RSS feeds

This solution involves setting up some kind of server that will generate RSS feeds for the developers. Implementing this could be quite involved. Fortunately there's a tool called FishEye from Cenqua that does exactly this. It's an improved viewcvs. Most importantly it allows developers to generate RSS feeds on any resource (any directories and any files). Here's what the HTML view looks like:

Then here's what you get in your favorite feed reader (I'm using Newz Crawler here):

Clicking on the diff link generates the following view:

Note: Please note that FishEye currently only supports CVS. Other SCMs like Subversion are planned in the future.

Conclusion

It is relatively simple and very effective to set up a way to notify developers about changes happening in the repository. I would even suggest that not doing so is a "communication anti-pattern". In order for it to be the most effective possible, developers should not be "spammed" by tons and tons of diff information. Thus to prevent this spamming you should consider 2 options: using RSS feeds instead of emails and allowing developers to choose their feeds. There are obviously some feeds that should be more "mandatory" than others. For example, the one notifiying of database schema change, the one notifying of build changes and the one notifying of public API changes. It's important, as always, that there is a champion in the team, explaining to others the benefit of these feeds and how they should be best used. Otherwise the power of them may exist but it won't be harnessed.