Start by creating the project and canonical solution. You can use any Java development environment: for example, Eclipse .

A good way to get started is to use the JavaProjectTemplate included with the Marmoset distribution. This is also available in examples.jar.

As you are developing the canonical solution, you can start writing JUnit tests for the project. Marmoset supports three kinds of tests: public, release, and secret. Each kind of test is embodied by a class which extends junit.framework.TestCase. A test class may contain any number of test methods: each such method is considered a single test case.

Note that test classes are optional: you may provide or omit public, release, and secret tests in any combination.

Your canonical solution should pass all of the test cases.

You should define whichever combination of the "test.class.public", "test.class.release", "test.class.secret", "test.class.student" properties are needed to define which classes represent your JUnit test cases. (See Section 3, “Test Properties”).

The default security.policy file in the JavaProjectTemplate should be adequate for most Java projects. Note that Clover, the code coverage tool used by the BuildServer, needs permission to create and write a special file in /tmp and permission to create shutdownHooks. Both of these permissions are granted in the sample file. You may want to selectively grant privileges to student code for certain kinds of tests: for example, writing files.

The Java Project Template provides an ANT build.xml file that can be used to build the test-setup and canonical archives. It does this by selecting the appropriate files from the project and archiving them in a jar file. To use this file, be sure to change the properties at the top of the page to point to the right files in your project.

You can also create the jar files manually. Here is a description of what the test-setup jar file should contain:

	Warning
	The test setup jarfile should never contain any classes from the canonical solution (i.e., any classes that the student is supposed to write), because they will take precedence over the student classes at runtime. Leaving them in basically means that the test results will be for the canonical solution, and not the student's work.

The canonical solution zipfile represents what students are expected to implement, and should pass all of the project tests. The zipfile should contain the source files corresponding to classes that are meant to be implemented by the student. The source files do not need to be in any particular directory structure, although using normal Java conventions is recommended. If the an Eclipse ".project" file is present, that is used as the base directory for the project, and no files outside that directory will be extracted. If an Eclipse ".classpath" file is present, it will be used to find source directories in the project, and no source files outside those directories will be compiled.

You may optionally provide some starter files for students to use at the start of their projects. These files include the methods in the specification emptied of their implementation. Typically these empty methods simply throw a java.lang.UnsupportedOperationException. The advantage of this is that the skeleton will compile and fail all the tests. Also Submit Server recognizes this exception and accurately indicates that a test fails because the associated functionality is not implemented.

The skeleton files should be packaged into a jar file that can be uploaded into the submit server. You may also include a .submit file which is used by the Eclipse Plugin and the Command Line Submission Utility to automatically upload student submissions into the submit server. This file can be found in the Project Utilities page on the Submit Server.