Working with a Java IDE and test-driven development, one can experience a process much like working with REPL, except that the results of learning are built into permanent unit tests rather than disappearing off the top of your terminal window.

Java is neglected as a language for data science and batch jobs because of the large overheard involved with creating command line scripts. Instead of seeing tools like Maven, Spring, and Log4J as being part of the solution, developers see them as part of the problem.

Centipede makes it trivial to create command line applications in Java for both research and production use.

Logging, per-developer configuration (no checking database passwords and API keys into version control) as well as documentation tools and rational error handling all come for free. The full power of Spring is available, but you'll never need to write XML if you don't want to.

Join our email list to follow developments or get support.

You can create a centipede project by by writing

mvn archetype:generate -Dfilter=centipede-archetype

selecting the centipede archetype, selecting the latest version, and entering the groupId, artifactId, version and package for your product. This creates a new maven project. You can build your new project by running

mvn install

in your project directory. Because centipede embeds configuration information and version numbers in your project, every centipede project should have a unique package name.

My experience is that scripting projects often grow to include a large number of scripts that call upon common libraries and common configuration parameters. For instance, you might want to write a number of report generators that call upon the same database. To support that goal, you can build multiple applications into a centipede project.

A Centipede Application is simply a Java class that implements CommandLineApplication, for instance:

package com.ontology2.centipedeTest;
import com.ontology2.centipede.shell.CommandLineApplication;
import org.springframework.stereotype.Component;

@Component("showVersionNumber")
public class ShowVersionNumber extends CommandLineApplication {
    @Override
    protected void _run(String[] arguments) {
        System.out.println(com.ontology2.centipedeTest.Version.get());
    }
}

the centipede shell uses the Spring framework to create your app. The easiest way to do this is to take advantage of classpath scanning. If you specify the@Component annotation before the class definition, Spring creates a Java bean with the name given in the @Component annotation. You can put any code you want in the _run method of your app.

Because Spring configures your CommandLineApplication your app can be configured using autowiring or JSR-250 standard annotations, which makes it easy to get database connections or to initialize any other subsystems used by your app.

You can also define apps by defining a bean using either XML-based or Java-based configuration in Spring, which makes it easy to build a family of apps that vary only in terms of configuration.

Running A Centipede Application is easy. If you're running UNIX with the Bash Shell, you can type

source centipedeProject/target/path.sh

to install your Centipede project in your shell. Now you can type

centipedeProject run myApp [arguments to my app]

and run your app. A similar script exists for Windows PowerShell and, since your Centipede Project is packaged as a single JAR you can easily write your own script to run your apps if the built-in scripts don't meet your needs.

People often build database passwords and API keys into small scripty applications, check them into version control and regret it. As in other affairs, Centipede aims to make it easier to do things right than do things wrong.

A Centipede application looks for the following files

$HOME/.projectName/applicationContext.xml
$HOME/.projectName/local.properties

beans defined in the local applicationContext.xml override files in the JAR; properties in the properties are made visible to Spring. You can use the property placeholder mechanism, autowiring, and annotation-based configuration to make these parameters visible to your app.

You can add additional context files specific to a given run using the [Centipede Options]{https://github.com/paulhoule/centipede/wiki/Centipede-options}

It is easy to work with Centipede Apps in an IDE, particularly if you use IntelliJ IDEA, which has a free community edition. (You can certainly use Eclipse, if you don't succumb to pluginitis).

Opening a Centipede Project with IDEA is as simple as choosing 'File > Open` and selecting the POM file for your project.

Centipede consists of two projects, centipede, which is a Java library and centipede-archetype which automatically creates new Centipede Projects that depend on the centipede library. Centipede contains an OptionsParser which you can incorporate in your project.

The Centipede Archetype is radically simple, but the implementation depends on a number of details which you should understand if you want to make changes to it.

Centipede has a few dependencies which reflect my opinionated opinions and I encourage you to take advantage of them:

• Spring -- Spring is a powerful framework for configuring projects, particularly when the same code is being used for research, development and production purposes
• Guava -- Wish you could program in Scala, Clojure or C#? Google's Guava Library adds practical support for functional programming and concise idioms in Java.
• JUnit 4 -- because the JUnit 3 dependency in maven-quickstart-archetype is archaic.
• JDK 7 -- the evolution of Java is too slow as it is; it's late in the game to develop new code for JDK 6.

Centipede depends on commons-logging for logging, largely because Spring does. The Centipede Archetype adds log4j to your project and installs a log4j.properties file in src/main/unpackaged-resources. This means you get logging that works out of the box without having to think about it.

Most people think that slf4j is a better solution than commons-logging and many people prefer logback and other packages to log4j. I considered using slf4j, but this complicates dependency management. I could hide the complexity from you for the spring packages imported by centipede but you'd need to manually manage exclusions for any other spring packages you wish to use.

If you want to use slf4j be advised that centipede continues the logging strategy used by Spring, and the same strategies used for running Spring in an slf4j system can be applied to centipede if you're willing to do the work.

Join our email list to follow developments or get support.