forked from skeeto/sample-java-project
-
Notifications
You must be signed in to change notification settings - Fork 0
Example Ant-based Java project
License
git4ruby/sample-java-project
Folders and files
| Name | Name | Last commit message | Last commit date | |
|---|---|---|---|---|
Repository files navigation
This is a reference for setting up a new Ant-based Java project. It contains most of the little Ant tricks I've learned over the years. When I start a new Java project I clone this repository, remove sections of build.xml that I don't care about for that particular project, set the project properties, clear out the sample sources, and get to work. Building this project requires that Ivy be available to Ant. All you need is ivy.jar in Ant's classpath (in your $CLASSPATH, $ANT_HOME/lib, or ~/.ant/lib). You will need to have Astyle installed and in your path for the "format" target to work. If it's missing, that's fine. It won't affect any other targets. Ant will be looking for Checkstyle if you try to use the "check" target. Like a hardcore bureaucrat, Checkstyle will harshly criticize any stylistic mistakes and missing documentation, requiring you to dot every "i" and cross every "t". That can keep idle hands pretty busy. Ant will be looking for ProGuard if you try to use the "optimize 5877 " target. This tool does a bytecode analysis to shorten (and obfuscate) identifiers and remove unreachable code. There is a "hotswap" target for replacing live code while an application is running. You'll need the hotswap Ant extension installed to use it. This target is to be used alongside the "run-hotswap" target, which enables hotswapping in the JVM. You can demo this for yourself by running "run-hotswap" in a terminal, editing the printed string in the code, and running "hotswap" in another terminal. The printed message in the running program should change to the new string. Note that ProGuard, hotswap, Ivy, and Checkstyle are needed only in the build classpath, not your project's classpath. That means you probably don't want them in lib/. They should be where Ant can get to them, not your project. Take note of the sample pom.xml file. This is not actually for Maven builds -- this is an Ant project afterall -- but for publishing builds for a Maven repository. It's packed up by the "bundle" target, which creates a bundle.jar containing your project's signed artifacts. To use the "bundle" target you need to have GnuPG set up in your path, a generated key pair, and a running gpg-agent, unless you like typing your passphrase a bunch of times in a row. I hate coding absolute paths in my build script and I hate including built files as part of the base project. My philosophy is that the *environment* should be set up so that the tool can easily find the external resources they need (JUnit, etc.) from the system, not within the project. It's the system or dependency manager that provides the libraries. Anyone who has the proper development environment set up -- one that works across many projects -- should be able to clone the repository and do a build simply by running the build program with no special arguments. There should be no need to edit or install anything into the project space for the initial build.
About
Example Ant-based Java project
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published
Languages
- Java 100.0%