This is a self-assessment activity to give you practice in working with the ant build manager. Feel free to share your problems, experiences, and choices in the Forum.

We’ll use that code as a starting point for this lab. (If, for some reason, you don’t have working code for that assignment, you can use your project from this earlier lab, but those tests were not very interesting.)

1. Copy the source code from your unit testing assignment, including both the instructor-provided code and your own unit tests, into a convenient directory.

2. Create a new Eclipse Java project at that directory. Remember to add the JUnit library to the build path of the new project.

3. Your code should compile under Eclipse to start with.

   If your code was compiling but you have problem with this copied code, remember that a class packageName1.packageName2.className must be stored as .../packageName1/packageName2/className.java, where the “…” is the directory that serves as the common root of all of your source code.

4. In your project directory, create a build.xml file. You can do this with the Eclipse editor if you like. Eclipse has an ant-specific editor, basically a slightly dressed-up version of its regular text editor. There’s also a special XML editor which knows less about ant build files but offers more help with the general XML syntax.

   You can also use any other text editor outside of Eclipse, but remember to refresh your Eclipse project after adding any new fles to the project directory by non-Eclipse means.

   • Try creating a build file that will do two things at first:

     1. A build target that will compile your code (using the javac task). Make this your “default” target.
     2. A clean target that will use the delete task to delete all .class files from your project.Clean up after a compilation

     You may want to keep the Apache Ant Manual open to the “Ant Tasks” section while you are working on this.

   • Run your build script from inside Eclipse by right-clicking on the build.xml file and selecting “Run as $\Rightarrow$ ant build”. Assuming that works, check to see that hte appropriate .class files have been produced.

   • Now right-click on the build.xml file and selecting “Run as $\Rightarrow$ ant build…”. The “…” form will offer up a list of targets for you to choose from. Choose your clean target.

   • Open up a command window, cd to the directory holding your project, and try running ant from there. (You may need to install ant first, if it is not already on your system.)

In the lectures we talked about conventional ways of organizing the files that make up a project, including the Apache Foundation’s organization for Java projects.

Some important characteristics of this organization are

• All the “source” files (code and data) written by the developers go into a src/ directory.
• All the files generated by the build process go into a target directory.
• The src directory is divided into src/main and src/test.
  • Files generated from src/main are assumed to become part of the final deliverable.
  • Files generated from src/test are used during testing, but not included in the final deliverable.

• The src/main and src/test directories are further divided according to programming language and/or “type” of data. Common subdirectories are java, data, and resources.

  At a minimum, an Apache-style Java project should expect to have src/main/java and src/test/java directories.

Now we’ll look at restructuring a project to meet these guidelines.

1. Do this outside of Eclipse using normal operating system commands or GUI: Go to the directory holding your project. (If you aren’t sure where that is, right-click on the project name in Eclipse, select Properties, and look at the Resource description.) Create src/main/java and src/test/java directories. Move your non-test Java files to src/main/java and move your Unit test Java files to src/test/java.

   • Remember that, in Java, package structure must match directory structure. So if your Java project includes a class MyClass in package cs330.asst1, then you currently have it in a location cs330/asst1/MyClass.java. When moving your code to the src/main/java and src/test/java directories, you need to keep that whole directory structure. In this example, you would wind up with src/main/java/cs330/asst1/MyClass.java.

2. Return to Eclipse, right-click on your project name, and select “Refresh”. Eclipse will discover your new directory structure, but won’t know what to make of it. You’ll almost certainly wind up with error messages suggesting that your classes are in the wrong packages.

3. We need to tell Eclipse about our intentions to keep our source code in src/main/java and src/test/java. The key to doing that is the project Build Path.

   Right-click on any file of your project and select “Build path => Configure Build Path”. Go to the Source tab. This is where we tell Eclipse where to look for Java source code. Add the folders src/main/java and src/test/java, then remove whatever folders had been listed previously.

   Click OK and, within a few seconds, you should see those error messages disappear.

4. One nice thing about adopting a standard project directory organization is that build files for that organization tend to be pretty similar. You can often re-use build files from one Apache-style project for another.

   This build file, for example, is a simplified version of an example from the lectures, boiled down to the essentials for an Apache-style project. Get it and replace your build.xml with it. Keep it named build.xml. Edit the beginning to change the project name and description to something more fitting.

   Run the build.xml from within Eclipse. You should find that your project code compiles, but your test cases do not. The error messages will point to problems locating org.junit.

5. Incorporating 3rd-party libraries like JUnit into a build is a bit of a challenge. We’ll look at a proper solution to this in a few weeks (Configuration Management). For now, we need a quick fix.

   Download the JUnit and Hamcrest-core jar files from junit.org. Put them somewhere convenient. (You could put them inside this project, but that makes sharing them with other projects difficult.) I put mine, for example, in /home/zeil/src, a directory I use for all kinds of downloaded libraries.

   Then edit the test.compilation.path in your build.xml to add those two Jar files, e.g.,

   <path id="test.compilation.path">
       <pathelement path="target/classes"/>
       <pathelement path="/home/zeil/src/junit4.jar"/>
       <pathelement path="/home/zeil/src/hamcrest-core.jar"/>
   </path>
   

   Run the build.xml again. It should complete successfully.

6. Refresh your Eclipse project (as you have done earlier). Eclipse should notice the existence of your new target directory,created by the ant build. Browse through that and see what has been placed there.

7. Outside of Eclipse, use your normal operating system commands to look carefully through the project directory. Do you notice a problem?

   You should see that you have duplicate sets of .class files. One set will be in target, because that’s where our build.xml file said to put them. The other set is where Eclipse has been putting them when it compiles the Java code.

   This duplication could create problems down the road if one set is more up-to-date than the other. Imagine testing or debugging your code, making changes to your source code, and, because you are executing the out-of-date copies of the .class files, seeing no changes in the behavior of the program. That could get incredibly confuging and frustrating.

8. For the fix, we again look to the Eclipse Build Path. Right-click on any file in the Eclipse project and select “Build path => Configure Build Path”. Go to the Source tab.

   Select the box “Allow output folders for source folders”. Then use the Browse button to select your target/classes folder as the default location for .class files.

   But we don’t want all of our .class files to go there. To redirect our unit test compilation, select the src/test/java source folder and use the expand control to it’s left to view the details. Select its “Output folder”, click the “Edit…” button, and change the output folder to target/test-classes.

   Click OK, and your Eclipse project settings are now consistent with your Ant build settings. If you re-examine the project directory in he operating system, you should find that the duplicate .class files have disappeared. If you make changes to your code and allow Eclipse to compile them, the updated executable code will be in target/.

1. Download and unpack this zip file in your project directory.

2. Create settings.gradle and build.gradle files mirroring the simple Java build

3. Check the build by asking for some basic information:

   ./gradlew tasks --all
   

   (For Windows, omit the “./”).

4. Try running the actual build from the command line:

   ./gradlew build
   

   (For Windows, omit the “./”).

   Look through the build/ directory to see what was done.

5. Delete the build/ directory. Launch the Gradle GUI:

   ./gradlew --gui
   

   Try running the build through the GUI. Explore some of the other targets available to you.

6. Install the “BuildShip” Gradle extension in your Eclipse environment (from the “Eclipse Marketplace” in the Help menu).

7. Delete your project from Eclipse (but do not delete the files).

8. Right-click in the Eclipse Project Explorer area, and select “Import…”, Gradle, Gradle Project, and point it at the directory where your project was located.

   For the gradle version, indicate that you are using the gradle wrapper.

9. Try launching your project build from the Gradle Tasks tab in the lower central panel.

   I generally don’t run Gradle this way, as I find it easier to just run the Gradle GUI in a separate window. Nonetheless, you want the Gradle extension so that, when you have a project with 3rd party libraries, Eclipse can find and use those as it error-checks your code.