The basic idea is straight forward. Create a builder, add components, get the toolbar from the builder. This is how it looks:

And this is how it feels:

JComponent toolbar = new ToolbarBuilder()
        .add(new JButton("A"))
        .add(new JButton[]{new JButton("B"), new JButton("C"), new JButton("D")})
        .addSeperator()
        .add(new JButton("E"))
        .getToolbar();

Nothing special so far. Except for the method concatenation and the Button[] support, this could be done easily with a default toolbar. The builder supports some helper methods to make life easier when adding Button[], a ButtonGroup or Actions.

Now lets see what happens when we use one of Jeremys ButtonUI classes and activate segmentation.

You see the nice mac like segmentation. To achieve this, we had to change the builder code slightly:

JComponent toolbar = new ToolbarBuilder()
        .withUI(TexturedButtonUI.class)
        .withSegmentation(true)
        .add(new JButton("A"))
        .add(new JButton[]{new JButton("B"), new JButton("C"), new JButton("D")})
        .addSeperator()
        .createGroup()
           .add(new JButton("E"))
           .add(new JButton("F"))
        .close()
        .getToolbar();

The UI class is switched to TexturedButtonUI and segmentation is turned on. To get an idea of group creation, we added an “F” button to create another group.

Notice that the builders add() method that takes Button[], ButtonGroup, or Action[] automatically create segmented groups. The second way is createGroup(), which creates and returns a builder that groups buttons and components. The segmentation is completely controlled by the  builder and the order of components just depends on order you add your buttons and components.

Another point to notice here is the ComponentFactory supported by the builder. Its not shown in the example, but you are not stuck with JToolBar – you can pass in any Component in the ToolbarBuilder constructor and, using a custom ComponentFactory, you can control how Buttons and group containers are created.

Now, up to this point I like the builder. I can pass in by own container, use custom UIs for my buttons and also get buttons created from Actions automatically. I can created groups of segmented buttons and other components. But, I soon realized that I use two other types of toolbars regularly. Jeremys Customizable toolbar and Ken Orrs UnifiedToolbar from the Mac Widgets Project. And that’s where the trouble began. One could write two completely separated builders for the two, but, I yell at my students if they don’t follow the DRY principles so I should try to stick with my own rules and find a way to extend the existing builder. Before I explain the problem, here are the results.

This is the customized toolbar created with the following code:

JButton customize = new JButton("Customize...");
final CustomizedToolbar toolbar = new CustomizableToolbarBuilder("toolbar demo")
        .withSegmentation(true)
        .withUI(TexturedButtonUI.class)
        .add(customize)
        .add(new JCheckBox("Check box"))
        .add(new JLabel("Label"))
        .add(new JButton("Button"))
        .add(new JButton("Hidden"))
        .hide()
        .createGroupContainer()
           .add(new JButton("g1"))
           .add(new JButton("g2"))
        .close()
        .getToolbar();

Fairly straight forward. Only one new method in use ( .hide() ) which removes the last added component from the default layout. In this case the “Hidden” button is not part of the default layout of the toolbar. This time the builder was a success as it really simplifies customizable toolbar creation.

For the UnifiedToolbar – please don’t take it too serious – Mac Widget comes with a good UnifiedToolbarBuilder and this was more of a test to see how one can extend the existing builder without too much hassle. So, lets take a look at the result.

This almost looks like Kens original example, except that I used Jeremys ButtonUI. Here is the code to create the UnifiedToolbar above. Notice that I left out the component creation, but in contrast to Kens example, the component creation is straight forward. I don’t set any properties or apply any UI changes.

JComponent toolBar = new UnifiedToolbarBuilder()
        .createGroup("View")
           .withUI(TexturedButtonUI.class)
           .add(leftButton)
           .add(rightButton)
        .close()
        .center()
            .add(new JButton("MobileMe", blueGlobeIcon))
            .add(greyGlobeButton)
            .add(new JButton("Advanced", gear))
        .right()
            .createGroup("Search", textField)
        .getToolbar();

A few things to note here. The UnifiedToobarBuilder adds components to the left by default. Component placement can be switched using center() or right() ( there is also a left() ). The default UI class applied to buttons is UnifiedToolbarButtonUI that comes with MacWidgets. The builder comes with two new createGroup() methods that can be used to create “labeled” groups (i.e. the View group). As you can see, we used the TexturedButtonUI implementation again, but this time inside a group. Such configurations are always restricted to the group. This enables changing group specific parameters, without any changes to the rest of the toolbar and works for all .withXXX() methods.

To recreate the original example, switch to a null UI within the view group ( .withUI(null) ). This prevents the default UnifiedToolbarButtonUI to be applied and you will end up with (mac only) segmented buttons again. The appropriate properties are applied to all buttons automatically because the constructor of UnifiedToolbarBuilder contains a line:

withProperty("JButton.buttonType", "segmentedTextured");

This applies the property to all added components. Use the withProperty() method to change the default properties.

Builder hierarchies

Ok. So far so good, I am happy with the result But I didn’t expect so much trouble on the way. The basic idea is straight forward, but the tricky part is extending the default ToolbarBuilder.  It is not enough to change the existing implementation by overriding some methods. That would be easy and works as expected. Problems arise with new methods in the extending builder.  Well, that should not be a problem. And it isn’t. At least not when we live with the drawback of loosing the ability to concatenate method calls and change the group creation to some other implementation. Ok, ok, example:

class A{
    public A methodA(){return this;}
}
class B extends A{
    public B methodB(){return this;};
}

Remember – we want to get the builder back from the method calls. This is how we can concatenate calls. In the simple scenario above, we already have a problem. new B().methodA() returns an instance of type A. From that point on, we have lost access to B and all methods in B. I know that the returned instance is actually of type B and could cast. But that doesn’t feel right because I have to assume things about the implementation that might change over time. The other thing is to give up the concatenation B b = new B(); b.methodA(); b.methodB() ... will work. Well, as long as the returned instance is of no special interest and we can be sure that it is always our ‘b’. In case of the toolbar builders, that not the case. For example, if you create groups using .createGroup(), the method returns a NEW builder instance. Call close() on that new instance and you are back in the original builder. But, as I said, this is nothing I want to know and it should be hidden from the user.
What I was looking for was a way to include the actual type of the returned builder instance and the only way I found was using generics. The generic information passed on to the actual implementations looks really really ugly (I will show you the base ToolbarBuilder in a second), but enables encoding the actual return type in all methods.

class A<T extends A>{
    public T methodA(){return (T) this;}
}
class B extends A<B>{
    public B methodB(){return this;};
}

This time, B extends A and tells it that the “global” return type should be “B”. We have to do a cast now, but thats internal and when you use the class you won’t notice (I also think the cast is fairly safe). With this structure in hand, we can do new B().methodA().methodB();. Notice that methodA() now returns an instance of type B, so we do not loose any functionality while calling methods in the builder hierarchy.
There is a major drawback tough. What if I now want to extend B ? With the example above I would be stuck in the original problem, because B is not generified and will only return instances of type B instead of, say C. We could put generics on B too and create another sub class:

class A<T extends A>{
    public T methodA(){return (T) this;}
}
class B<T extends B> extends A<T>{
    public T methodB(){return (T) this;};
}
class C<T extends C> extends B<T>{
    public T methodC(){return (T) this;};
}

This time we already generified C, but the whole thing contains another problem. Now we have to provide the generic parameter to the constructor even if it looks silly : new C<C>().methodB() returns C. Without the generic information, you will only get back a B  ( new C().methodB() returns B) due to automatic type inference.

Anyways, its ugly and I don’t want to force a new UnifiedToolbarBuilder<UnifiedToolbarBuilder>() so the final Builder classes are not generified. (They are not final though, you can still extend and override methods). There are abstract classes that carry the generic information and can be used to create new builders.

If you find the time, just try it And of course, feedback, comments and suggestions are welcome !!

Download

The ToolbarBuilder is released under the BSD License.

You can get the ToolbarBuilder.jar file here.

The sources are provided here.

API Documentaiton can be found here.

Remember to put MacWidgets , the ButtonUI and/or the Customizable Toolbar in your ClassPath. The ToolbarBuilder was tested with Java 1.5 and 1.6.

Basically create a new Live Template and set the name to something like “fpc”. The template is

firePropertyChange("$name$", $name$, this.$name$ = $name$);

and the variable definition for $name$ is variableOfType("Object"). Finally set the default value to “name” and you are ready to go. Let the IDE create a setter, remove the body, type fpc and hit tab. This will expand to the firePropertyChange statement and if you are lucky, the variable name is correct Of course, the class has to be some sort of AbstractBean and provide a firePropertyChange

    <loadfile property="svn.revision" srcFile="./.svn/entries">
        <filterchain>
        <headfilter lines="1" skip="3"/>
        <deletecharacters chars="\n"/>
        </filterchain>
   </loadfile>

loads the current revision number into a property called svn.revision. I use this with svn 1.4 and 1.5 repositories and it works just fine.

save.Action.accelerator=meta pressed S

if you are on Mac OS X and

save.Action.accelerator=ctrl pressed S

if you are on Windows. The simple way to to this is

save.Action.accelerator=shortcut S

and “shortcut” will map to the meta key on the mac and to the ctrl key on windows. Remember, this is appframework specific and not a real Keystroke definition. I didn’t find the documentation anywhere ( I am sure it somewhere ), but I found that while browsing the source code. It doesn’t solve all the problems related to accelerator/mnemonic/keystrokes on differen paltforms ! But, at least for me, it solved 90% of the problems, because we develope our app in english (so no other locales involved) and “ctrl” is also fine for the linux/unix/solaris platform. I you want to do more or just want to read more about the problem, there is a thread from the appframwork mailing list.

Ok, so we need a way to manipulate the content of the persistence.xml at runtime to add the class entries and I found way, hacking into the mechanism that reads the content of the persistence.xml.
Basically, what we do is, we occupy the stream that represents the file and manipulate it at runtime. To do so, we have to extend the initialization process, but, thanks to protected variables used by the EclipseLink team, this works without any manipulation of the EclipseLink source code. We have to extend some classes, to make it work, but thats it. And it turned out that the changes are rather minimal and the hack works straight forward. So, lets jump into the code and get things running. Still, keep in mind, we work on top of internal initialization code ! There is a good chance that this breaks with a new release, although I think it will be straight forward to keep things running…at least as long as the EclipseLink team sticks to protected access modifiers for some of their variables.

The interface we have to implement is org.eclipse.persistence.internal.jpa.deployment.Archive. This defines the access mechanism used by EclipseLink and the implementations are used to access the content of the persistence.xml via the getEntry method:

/**
* Returns the InputStream for the given entry name. Returns null if no such
* entry exists. The entry name must be relative to the root of the module.
*
* @param entryPath the file name relative to the root of the module.
* @return the InputStream for the given entry name or null if not found.
*/
InputStream getEntry(String entryPath) throws IOException;

Well, we don’t want to provide a complete implementation, we just want to know when the persistence.xml is accessed. Therefore we implemented a WrapperArchive that delegates to a parent archive and checks for access to persistence.xml.

...
public InputStream getEntry(String entryPath) throws IOException {
    if (entryPath.equals("META-INF/persistence.xml")) {
        return createPersitenceString(parent
                .getEntry("META-INF/persistence.xml"));
    }
    return parent.getEntry(entryPath);
}
...
protected InputStream createPersitenceString(InputStream in) {
    BufferedReader bi = new BufferedReader(new InputStreamReader(in));
    StringBuffer b = new StringBuffer();
    String l = null;
    try {
        l = bi.readLine();
        while (l != null) {
            if (l.trim().startsWith("")) {
                if (entityCalsses != null) {
                    for (String clazz : entityCalsses) {
                        b.append("");
                        b.append(clazz);
                        b.append("");
                        b.append("\n");
                    }
                }
            } else {
                b.append(l);
            }
            l = bi.readLine();
        }
    } catch (IOException e) {
        Logger.getLogger(getClass()).error("Error while creating dynamic persistence.xml", e);
    }
    return new ByteArrayInputStream(b.toString().getBytes());
}
...

All other methods delegate directly to the parent archive and we intercept access to META-INF/persistence.xml. If someone tries to get a stream to the persistence.xml, we intercept that call, read the original stream, manipulate it and return the changed content. Well, we just look for <!–$$CLASSES$$–> somewhere in the original, and replace that with the class definitions. I know, I know, there are better ways, but this works for now.
Now, all we have to do is make sure that the WrapperArchive is used. To achieve this, we extend the PersistenceProvider:

public class DynamicPersistenceProvider extends PersistenceProvider{
    private DynamicPersistenceProvider() {
        super();
        initializationHelper = new DynamicInitializationHelper();
    }
    public DynamicPersistenceProvider(String[] classes) {
        this();
        WrapperArchive.setEntityCalsses(Arrays.asList(classes));
    }
}

The dynamic provider is initialized with the set of entity classes and we can use the openness of the EclipseLink implementation (thanks for using protected variables !!!). Internally they use an initialization helper that is used to get access to a JPAInitializer that has a method initialize(Map, PersistenceInitializerHelper) that creates the archives. To get that in, we implement the a DynamicInitializationHelper that extends PersistenceInitializationHelper:

public class DynamicInitializationHelper extends PersistenceInitializationHelper{
    public JPAInitializer getInitializer(ClassLoader classLoader, Map m) {
        return DynamicJavaSECMPInitializer.getJavaSECMPInitializer();
    }
}

This returns our own JPAInitializer

public class DynamicJavaSECMPInitializer extends JavaSECMPInitializer {
    public static synchronized DynamicJavaSECMPInitializer getJavaSECMPInitializer() {
        if (javaSECMPInitializer == null || !(javaSECMPInitializer instanceof DynamicJavaSECMPInitializer)) {
           javaSECMPInitializer = new DynamicJavaSECMPInitializer();
        }
        initializeTopLinkLoggingFile();
        return (DynamicJavaSECMPInitializer) javaSECMPInitializer;
    }
    public void initialize(Map m, PersistenceInitializationHelper persistenceHelper) {
        initializeClassLoader(persistenceHelper);
        final Set pars = PersistenceUnitProcessor.findPersistenceArchives(initializationClassloader);
        for (Archive archive: pars) {
            AbstractSessionLog.getLog().log(SessionLog.FINER, "cmp_init_initialize", archive);
            initPersistenceUnits(WrapperArchive.createWrapperArchive(archive), m, persistenceHelper);
        }

    }
}

where we override the initialize method. The content is copy pasted from the original implementation except that we make sure that we create the WrapperArchives here. Also, again, thanks to the protected variables, we change the static reference to the JavaSECMPInitializer singleton to our dynamic version.

At the end of the day its not much code to achieve the runtime manipulation and we can do something like this

...
String[] classes = new String[]{Person.class.getName()};
EntityManagerFactory emf = new DynamicPersistenceProvider(classes)
    .createEntityManagerFactory(persistenceUnitName, loadConfiguration());

and end up with a persistence unit that contains a Person entity.
There is only one little drawback that I discovered so far. When using dynamic weaving ( -javaagent:eclipselink.jar ), the JavaSECMPInitializer singleton seems to be initialized somewhere else. My workaround for now, I close the EntityManagerFactory immediately after the first creation and recreate a new one. That way lazy loading works and I am happy for the moment. I have to digg a bit deeper to find out why we need to do that, but for the moment I am happy

Here is the source code.

I know EL basics from BeansBinding, which I use in most of my UI projects. EL itself looks pretty interesting, but, well, sort of complicated. Even finding the proper jar files seems to be a problem, or at least “another of life’s obscure mysteries” and using EL for a simple search and replace example implies implementing some internals. I was looking for something that I can just use.

Luckily, the first comment mentions the ELProperty class from BeansBinding, and that jar is just a few mouse clicks away, so I thought I give it a try…and…well…it works

public static void main(String[] args) {
    Person mom = new Person("Ann", null);
    Person son = new Person("Dave", mom);
    Dog dog = new Dog("Foxy");

    ELProperty el = ELProperty
            .create("${name}'s mom is ${mother.name}");
    System.out.println(el.getValue(son));

    ELProperty mapEL = ELProperty
            .create("${mother.name}'s dog is ${dog.name}");
    Map map = new HashMap();
    map.put("mother", mom);
    map.put("dog", dog);
    System.out.println(mapEL.getValue(map));
}

ELProperty.create() creates a new instance from a template string. You can fill the template with values using getValue() method. This one takes either an Object with proper getter methods or a Map to resolve variables. And this is the result of the simple example:

Dave's mom is Ann
Ann's dog is Foxy

Full Sample Code ( You need the beansbinding jar in the classpath)

<jar destfile="${app.id}-${app.version}.jar"
  index="true"
  filesetmanifest="merge">
  <fileset dir="${classes.dir}"/>
  <zipgroupfileset dir="${lib.dir}" includes="*.jar" />
</jar>

This takes all the files in ${classes.dir}, packs them in a jar and add the content of all the jar files in ${lib.dir}. In this case, we merge multiple manifests, but this can be changed according to the jar task documentation.

This works as long as none of your files is signed. You know that you are in trouble when you get messages like

java.lang.SecurityException: no manifiest section for signature file entry ....

I found a solution here, and the say that one has to remove the SUN_MICR files. This can be done manually, but keep it in mind when ever you update your libraries. I find it more elegant when ant just removes the files. Unfortunately it is to possible to specify excludes for zipgroupfileset. The alternative to zipgroupfileset is zipfileset, which allows exclude patterns and extraction of zip files via the src parameter. And thats the problem. You can only specify exactly one file as src. I don’t want to specify all my jars manually. Therefore I creates a single jar first, using zipgroupfileset and then move this file through a zip/zipfileset where we can exclude specific files.

<jar destfile="${app.id}-${app.version}.jar"
  index="true"
  filesetmanifest="merge">
  <fileset dir="${classes.dir}"/>
  <zipgroupfileset dir="${lib.dir}" includes="*.jar" />
</jar>
<zip destfile="temp-jar-file.jar">
  <zipfileset src="${app.id}-${app.version}.jar" excludes="META-INF/*.RSA, META-INF/*.DSA, META-INF/*.SF" />
</zip>
<move file="temp-jar-file.jar" tofile="${app.id}-${app.version}.jar"/>

You end up with a single, signature free jar file. This is not the most elegant solution, which would be either to enable multiple src files in zipfileset or an excludes parameter for zipgroupfileset that matches against the content of files, not the input files. But still, its small and does not need any third party ant tasks.

Just reminds me, we had a java class that did that for QAlign 2 Panta Rei source code distribution.

Yeah, there it is, May 21, 2005 written in Michas old apartment in Barcelona while working on QAlign2.

The QAlign2 crew

And – do never ever trust Micha when he says that he never copied a “Start Wars – Episode I” script into a static final String variable in one of the source code files

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;
import java.nio.Buffer;
import java.nio.CharBuffer;
import java.util.ArrayList;
import java.util.Collections;
import java.util.HashSet;
import java.util.Iterator;
import java.util.List;
import java.util.Set;

/*
 * Created on May 21, 2005
 */

/**
 * Class scans given directory for sourcefiles and appends a disclaimer
 *
 * This is a quick hack version of a good appending methods and it is NOT memory efficient. Thats
 * why "Start Wars - Episode I" will not work as disclaimer. The disclaimer itself should NOT be inlined
 * in sourcecode comment tags, this is done by {@see #readDiscalimer()} (Let it be the pure disclaimer, without any \/* *\/).
 * Also the size of source files is limited to the heap size of the vm. If one uses this with large source
 * or disclaimer files extend the VM max heap size (e.g. -Xmx512m).
 *
 * Remember, the scanFile() method automatically appends "\r\n" to each line while writing the files.
 *
 * parameters
 * -d  The source directory
 * -f  The disclaimer
 * -v <0..2> verbose output
 * @author Thasso
 */
public class AppendDisclaimer {
    /**
     * the input directory
     */
    public static String inputDir = ".";
    /**
     * Filename of the disclaimer
     */
    public static String disclaimerFile = null;
    /**
     * String representation of the disclaimer
     */
    public static String disclaimer;

    /**
     * verbose level
     */
    public static int verbose = 0;

    public static void main(String[] args) {
        if(args.length < 1){
            printUsage();
        }
        // Parse arguments
        for (int i = 0; i < args.length; i++) {
            if(args[i].equalsIgnoreCase("-d")){
                inputDir = args[i+1];
            }
            if(args[i].equalsIgnoreCase("-v")){
                verbose = args[i+1] != null ? Integer.parseInt(args[i+1]):2;
            }
            if(args[i].equalsIgnoreCase("-f")){
                disclaimerFile = args[i+1];
            }
        }
        if(disclaimerFile == null)
            printUsage("Discalimer file not set ! Use -f to define a disclaimer");

        readDiscalimer();        

        // read filelist from directory
        File input = new File(inputDir);
        if(!input.isDirectory() ||!input.canRead()){
            printUsage("Can not read from directory " + input.getAbsolutePath());
        }
        if(verbose > 0)
            System.out.println("Scanning Directory :\n\t"+input.getAbsolutePath());

        List javaFiles = readDirectory(input, ".java");
        //Scan files and append disclaimer
        for (Iterator it = javaFiles.iterator(); it.hasNext();) {
            File f = (File) it.next();
            scanFile(f);
        }
    }

    /**
     * read the disclaimer from file
     */
    private static void readDiscalimer() {
        File f = new File(disclaimerFile);
        StringBuffer d = new StringBuffer();
        if(!f.exists())
            printUsage("Disclaimer " + disclaimerFile + " not found");
        if(!f.canRead())
            printUsage("Disclaimer " + disclaimerFile + " not readable");

        try {
            BufferedReader in = new BufferedReader(new FileReader(f));
            d.append("/*\r\n");
            String l = in.readLine();
            while(l != null){
                d.append(" * "+l+"\r\n");
                l = in.readLine();
            }
            d.append("*/\r\n");
            disclaimer = d.toString();
            in.close();
        } catch (FileNotFoundException e) {
            printUsage("Disclaimer " + disclaimerFile + " not found");
        } catch (IOException e) {
            printUsage("Error while reading from file " + disclaimerFile);
        }
    }

    /**
     * Memory consuming scna file method.
     * Creates a buffer and appends the disclaimer. Than reads the file and appends it to
     * the buffer, line by line, adding \\r\\n to each line.
     * When done, writes out the file with a simple and absolute inefficent buffer.toString() call.
     *
     * @param f
     */
    private static void scanFile(File f){
        BufferedReader in = null;
        StringBuffer content = new StringBuffer();
        content.append(disclaimer+"\r\n"+"\r\n");
        if(verbose > 1)
            System.out.println("Reading file " + f.getName());

        try {
            in = new BufferedReader(new FileReader(f));
            String line = in.readLine();
            while(line != null){
                content.append(line+"\r\n");
                line = in.readLine();
            }
            in.close();
        } catch (FileNotFoundException e) {
            printUsage("File  not found " + f.getName());
        } catch (IOException e) {
            printUsage("Could not read file " + f.getName());
        }finally{
            try {
                in.close();
            } catch (IOException e1) {}
        }
        if(verbose > 1)
            System.out.println("Writing file " + f.getName());

        BufferedWriter w = null;
        try {
            w = new BufferedWriter(new FileWriter(f));
            w.write(content.toString());
            w.close();
        } catch (IOException e) {
            printUsage("Could not write file " + f.getName());
        }finally{
            try {
                w.close();
            } catch (IOException e) {}
        }
    }

    /**
     * Recurcive scan directory for files with given suffix
     *
     * @param dir directory to scan
     * @param suffix files suffix
     */
    protected static List readDirectory(File dir, String suffix) {
        ArrayList files = new ArrayList();
        if(dir.isFile())
            return null;

        if(verbose > 1)
            System.out.println("Scanning Directory :\n\t"+dir.getAbsolutePath());

        File[] all = dir.listFiles();
        ArrayList dirs = new ArrayList();
        for (int i = 0; i < all.length; i++) {
            if(all[i].isFile()){
                if(all[i].getName().endsWith(suffix)){
                    files.add(all[i]);
                }
            }else if(all[i].isDirectory()){
                dirs.add(all[i]);
            }
        }
        for (Iterator it = dirs.iterator(); it.hasNext();) {
            File d = (File) it.next();
            List l = readDirectory(d, suffix);
            files.addAll(l);
        }
        return files;
    }

    /**
     * print string and the usage
     * @param string
     */
    private static void printUsage(String string) {
        System.err.println(string + "\n\n");
        printUsage();
    }

    /**
     * print the usage
     */
    private static void printUsage() {
        System.err.println(""
                +" This is a quick hack version of a good appending methods and it is NOT memory efficient. \r\n"
                + " Thats why "Start Wars - Episode I" will not work as disclaimer.\r\n"
                + " The disclaimer itself should NOT be inlined\r\n"
                + " in sourcecode comment tags, this is done automaticaly (Let it be the pure disclaimer, without any /* */) \r\n"
                + " Also the size of source files is limited to the heap size of the vm. If one uses this with large source\r\n"
                + " or disclaimer files extend the VM max heap size (e.g. -Xmx512m).\r\n"
                + " \r\n"
                + " Remember, the scanFile() method automatically appends "\\r\\n" to each line while writing the files.\r\n"
                + " \r\n"
                + " parameters\r\n"
                + " -d  The source directory\r\n"
                + " -f  The disclaimer\r\n"
                + " -v <0..2> verbose output\r\n"

        );
        System.exit(1);
    }

}

src/ - all java soources in here
lib/
  devel/ - development libraries
  runtime/ - runtime libraries

If your project follows this struicture, you can get the following tasks out of the box:

Buildfile: build.xml

Main targets:

 clean          Clean
 compile        Compile all source files
 compile-tests  Compile all source files
 dist           Build library and pack jar file
 dist-one       Build library and pack jar file
 doc            Create Javadoc
 html-reports   Creates HTML from test reports
 test           Run JUnit Tests
Default target: dist

You can modify the properties to adapt different names or a different project structure. The script creates a target directory that contains the results.

Compiling and packing should work out of the box, but the test sections expects a junit and ant-junit jars in lib/devel. They can also be placed in one of Ants lib directories.

The build file