GOM: Good Practices

There are a number of reasons why an optimal Gump Descriptor ought be a goal. Some are to be nice to Gump, and it's resources. Some are so Gump can be nice to your project. In short, don't ask Gump to do more than it needs, and don't put barriers in the way of the frequent Gumping of your project.

Selecting a minimal target

Select an ant target (from your build.xml, or whichever) that minimally compiles the code, and creates output jars. Try to avoid targets that create full distributions (in numerous formats), or perform unnecessary work like javadoc generation.

For your *-test project (see 'Use a separate Test Project') do unit tests only.

Let Gump set your final jar name

Gump runs set @@DATE@@, which ought be set into the jar name. Use a property for this.

Example

        <ant buildfile="build.xml" target="gump">
          <property name="DATE_STAMP" value="@@DATE@@"/>        	
        </ant>
  				
  			

Use optional dependencies

Use a option instead of depend when at all possible.

The fewer mandatory dependencies a project has the more often it will be Gumped, the better Friend Of Gump it'll be, and will make a much better dependency for downstream projects.

Project often set dependencies on junit or checkstyle and then fail to even get Gumped to compile when those fail. Setting those two to optional, and then making the buildfile check if they are available before attempting the task is a nice way to go.

Depend upon ant with inherit="runtime"

This way, you only pick up the jars it needs to run, you don't need more cluttering the classpath.

Use a separate Test Project

If at all possible, split your project into (at least) two -- one (named your-project) being the main compilation/archive & the other (named your-project-test) that just runs unit tests.

This requires only the second to depend upon junit, say & reduces the dependencies of the first.

This allows downstream dependees to select which of your projects they wish to depend upon. If they depend upon your-project (and perhaps optionally on your-project-test) then if some obscure unit test fails they still get Gumped & don't miss a run.