In Unix, this is relatively easy using the sed tool (using “;” as separator):

sed -e "s/;/\\n/g" myfile.txt

But Windows doesn’t provide a built-in tool for things like that, and shell emulators like cygwin are not available on all computers.

However, if you have access to Ultraedit, you can simply to a Search & Replace. Search for your separator (“;”) and replace it with “^p”. Voila, you just created a readable list of your output.

Rather, ant checks the contents of the existing archive file and compares them to the files which are supposed to be archived. Any files that are not already in the archive (or which have changed since the last build) are then put in the already existing archive, overwriting existing files:

<target name="jar-update">
  <jar basedir="DirToJar" update="true" destfile="test.jar"/>
</target>

But what happens if you delete a file in the directory you want to archive? Does ant realize that you deleted the file and will also delete this file in the target archive file?

The answer to that question is: no, ant does not delete files from an archive file if the “update” atribute is set to “true”. This can lead to nasty surprises in some rare cases. However, deleting the target archive file (for example during a “clean”) solves this problem.

Option 1: JAR file in %ANT_HOME%/lib

If you put the antcontrib.jar file in the lib directory of your ant installation, the library will be available by default. All you have to do is to load the ant tasks from this library:

<taskdef resource="net/sf/antcontrib/antlib.xml"/>

From this point on, all ant tasks defined in antcontrib.jar are available in your ant build file.

Option 2: JAR file anywhere

In most cases you don’t want to “dirty” your ant installation by putting a custom library in the lib directory. So, you have to specify the location of the JAR file (which would be in some sub directory of your project):

<taskdef resource="net/sf/antcontrib/antlib.xml"
  classpath="path/to/antcontrib.jar"/>

Using namespaces in Ant

To keep your custom ant tasks distinct from default ant tasks, you can add namespaces to each custom library. Here is a toy example:

<project name="MyProject" xmlns:antcontrib="net/sf/antcontrib"/>
<taskdef uri="net/sf/antcontrib"
  resource="net/sf/antcontrib/antlib.xml"
  classpath="path/to/antcontrib.jar"/>

<!-- now we have to use the prefix "antcontrib:" to access
  the antcontrib tasks -->
<antcontrib:foreach ... />
</project>

Optimistic Version Control

Optimistic version control is the default setting in prominent tools like CVS or Subversion. A conflict is created and resolved the following way:

• Persons A and B get resource X from the repository
• Person A checks his changes into the repository
• Person B tries to check in his changes and is alerted of a conflict
• Person B merges his changes into the version of X checked in by Person A

Pessimistic Locking

Pessimistic version control avoids conflicts altogether by locking resources.

• Person A gets resource X from the repository, locking it
• Person B tries to get resource X from the repository but cannot, since it is locked
• Person A checks in his changes into the repository, unlocking resource X
• Person B can now get resource X from the repository an do his changes

This technique is pessimistic in that it expects the worst, which in this case is persons A and B editing resource X at the same time.

Why Pessimism is bad

In my opinion, pessimistic version control is just a measure of some manager to let the poor developers feel who’s the boss. The term “pessimistic” alone should be enough to think about another solution (try explaining to someone not involved in software development why we are pessimistic about version control…).

The main reason for my opinion is the fact that while resources are locked by someone, no one else can work on these resources, effectively blocking the progress of everyone else, who just now needed to change something. Plus, if I want to change a resource someone else is currently blocking, I have to call this someone and tell him to drop me a note when he’s finished, which is organizational overhead. For resources that are changed often (like configuration files or central source files) this can be a severe problem!

I often hear the argument “But when a resource is locked, we don’t have to merge anymore. And merging is evil, because it is much work and error prone”. It is not. There are tools to help the developer to merge files. These tools are proven. In most cases you only have to look at the tools’ output an confirm it. Merging files only gets nasty when a file has completely changed…which is rarely the case.

Another argument for pessimistic locking is this: “In large teams, many people are working on the same repository. Thus, optimistic version control would result in a lot of merging”. Besides the previous argument that merging is neither difficult nor dangerous, a large team should work on a large project. What is the chance that 2 out of 20 developers try to access the same resource (out of 20 000) at the same time?

Additionally to the above argumentation for optimistic version control I have had some rather bad experiences with pessimistic version control. Someone always forgets to check his sources back into the repository. Very frustrating if this someone is not reachable by phone because he’s sick or on vacation. Furthermore, not all tools boasting the locking feature really work. In my case, the locking mechanism didn’t always work and you had to merge anyways. Or the tool let the developer choose whether to lock or not. This made it possible for Person B to check in his changes while Person A had the resource locked…automatically creating a branch without letting the developer know this. I don’t want to know what changes were lost due to this bug… . Very ugly, indeed.

So…why not let the developers actually work instead of letting them twiddle their thumbs while waiting for someone to release a lock?

Constants Interfaces

Constants Interfaces are created in order to save the lazy coder some key strokes. A constants interface is an interface defining nothing but constants and looks like this:

public interface MyConstants {
  public static final String MY_CONSTANT_1 = "foo";
  public static final String MY_CONSTANT_2 = "bar";
  // ...
}

This interface can then be “implemented” by other classes  that need access to the constants. The constants can be used without the prefix “MyConstants.”.

public class MyClass implements MyConstants{
  public void doSomething(){
    System.out.println(MY_CONSTANT_1 + MY_CONSTANT_2);
  }
}

Why is this bad? There are several reasons (some of which may be subject to flavor-discussions).

The Code Smell

First of all, interfaces were designed to describe the behavior of a component (i.e. its methods). Thus, an unbiased programmer expects an interface to describe behavior and will be irritated if he only finds constants.

Second, the use of such an interface encourages the habit of simply implementing the interface, even if only one or two of perhaps 50 constants are used. Thus, 48 constants are visible in the implementing class but are not used, which violates encapsulation. Furthermore, if the implementing class is part of a class hierarchy, all subclasses will also have direct access to the constants defined through the interface. In my current refactoring assignment the constants of a single interface were visible in >100 classes of a rather unflexible class hierarchy (which should also be subject to refactoring). Worse: some classes high up in that hierarchy implemented more than one constants interface, making all constants visible in sublasses.

Third, though admittedly a weak argument, using a constant with its class prefix (MyConstants.MY_CONSTANT_1) is more self-documenting than using the constant name alone. Assuming, of course, that the class and constants names are well chosen. If the class prefix is always used, the single advantage of constants interfaces is lost.

Better Solutions

In conclusion, interfaces defining nothing but constants are bad practice and should be avoided. If such interfaces are already present, they should be refactored into either enums or final classes with a private constructor.