Overview

Ply is a build tool. It is sensible, fast and a joy to use.

Features

• Pretty print - ply's output is clean and colored. Here's the actual output of running ply clean test from the ply-util module:

• No xml - Ply has no xml configuration. Its configuration is simple and familiar; java-style properties files. Ply even has tools built-in to help you manage your project's properties. And yes, just properties files. Good ol' simple key-value pairs, no complex syntax or DSL to learn.
• Sensible defaults - ply uses defaults which are intuitive (e.g., the default java source/target for compilation is the version of the $JAVA_HOME jdk). And because ply has sensible and intuitive defaults starting a new project is as simple as running ply init.
• Easily extensible - since ply simply executes scripts (or aliases of scripts; i.e., clean, install, test) changing or augmenting a build lifecycle is just a matter of adding/removing/replacing scripts (or re-aliasing them). The default scripts and aliases provided specify a best practice for development but if your project wants/needs to deviate from this approach doing so shouldn't feel like working against the grain. And keep in mind, scripts are anything executable (bash, perl, ruby, python, ...) so even though your project's written in one language feel free to flex your polyglot-muscles and augment your build process in any language you like!

Why Another Build Tool?

Other build tools make you work harder than you should have to. How hard? Stupidly hard:

• Copious XML configuration - many build tools use xml to configure their execution. XML is verbose and maintaining it is arduous, err prone and often mandates IDE features/plugins to prevent developer insanity.
• Rigid extensions - extending the functionality of build tools is hard and often forces developers to conform to rigid APIs (i.e., implementing an interface in a particular langauge) or in the best case forces developers to write their extensions in a set language (i.e., an extension is anything provided it is written in Ruby).
• Boiler-plate configuration for new projects - starting a new project, developers are eager to get working. Having to copy and paste configuration files from existing projects and then do find-replace operations is annoying and not productive.

Concepts

• Scripts
• Properties
• Aliases
• Scopes
• Dependencies
• Submodules

At its simplest ply just invokes a series of scripts. The following is a valid series of scripts for ply:

$ ply clean compile

The series is space delimited so the previous example ran two scripts: clean and compile

Scripts can be extended and aliased. Ply ships with property defaults and packaged scripts which allow most java projects to build with no configuration. For a list of all scripts which ply ships with see Included Scripts.

To enable a directory/project to use ply, simply run init from within the directory:

$ ply init

Ok, I Want It!

Download the tar file ply.tar or the zip file ply.zip

Un-package the tar/zip file to a directory of your choosing (say /opt/ply) and then make sure the following properties are set as environmental variables:

• JAVA_HOME -> (likely already set by your distro) set to the home directory of the java installation

• PLY_HOME -> set to the directory of where ever you untar-ed ply (i.e., /opt/ply).

Finally add ${PLY_HOME}/bin to your $PATH

Bash Tab Completion (i.e., readline support)

Within the distribution is a file ply_completion.bash which provides Bash tab completion. To enable:

   $ sudo cp ply_completion.bash /etc/bash_completion.d/

Alternatively, add this to your bash profile (where you defined JAVA_HOME / PLY_HOME)

   $ . $PLY_HOME/ply_completion.bash

Updating Ply

Once installed, ply can update itself to the most recent version. Simply run:

   $ ply update

Tutorials

• Project setup
• Building
• Adding dependencies
• Managing repositories
• Running tests
• Changing log levels