| CPSC 329 | Software Development | Fall 2026 |
This lab takes you through configuring your Eclipse environment for this course and getting started with using Git in Eclipse — you'll set up a project, create a local repository, and practice two core workflows typical for solo developers. It also introduces some useful features of Eclipse that you might not be aware of — but would like to be. Later labs will introduce more advanced Git usage and workflows suited for team development projects.
Labs are for learning and practice — you may help and be helped by others when it comes to figuring out what to do, but in the end you need to understand and be able to do the things for yourself.
You may not use AI to figure out what to do or to do the task for you.
due Fri 9/4 at the start of class
To hand in your work:
Locate the directory labeled with your username in the class handin directory /classes/cs329/handin, and create a subdirectory lab1 in your personal handin directory.
Make sure the three screenshots have the filenames directed, and copy them into the lab1 folder you created in your handin directory.
It is assumed that you have used Linux at HWS before and that you are familiar with accessing Linux, navigating the Linux desktop, and working with the Linux filesystem (including terms home directory and root directory, path notation, and tasks like browsing the filesystem, creating directories, and copying files). Be sure to ask if that's not the case and you encounter something unfamiliar.
Some notes:
Please remember to log out when you are done using Linux — leaving yourself logged in and then logging in a second time from another location can lead to problems — and, in Demarest 002, also reboot your computer to Windows as a courtesy to the next user.
If you are off campus, you will need to connect to the VPN before starting up the VDI — note that VPN access is no longer enabled by default for students and you will need to contact the Help Desk to request access.
IT's documentation on accessing and using Linux is linked from the main course page — it is a good starting point even if it is not always completely up-to-date.
It is also assumed that you have used Eclipse before and that you are familiar with terms like workspace, project, perspective, view and basic tasks like creating a new project and importing files. Be sure to ask if that's not the case and you encounter something unfamiliar.
We'll be using the following directory layout, which keeps everything for this course together under the same top-level directory (~/cs329) but separates the Git spaces from Eclipse's.
~/cs329 ← parent folder for all cs329 coursework
+-- dev/ ← parent folder for all your Git repositories
| +-- lab1/ ← each project gets its own independent Git repository
| + .git/ ← the repository itself
| + .gitignore ← identifies files to keep out of the repository
| + src/ ← Java source code (.java files)
| + bin/ ← Java build output (.class files) — never committed
+ workspace/ ← Eclipse workspace (bookkeeping only, no files)
+ .metadata/ ← Eclipse's internal state — never committed
Create the top-level directory ~/cs329.
Create the repository parent directory ~/cs329/dev.
Create the Eclipse workspace directory ~/cs329/workspace.
The first time you start Eclipse (or if you have used Eclipse before but have configured it to ask each time), you will be prompted to specify a workspace directory — choose the directory you created above. If you are only using Eclipse for this course (or want to default to the workspace for this course), you can check the "Use this as the default and do not ask again" box — otherwise Eclipse will prompt you for the directory every time it starts up. To change to a different workspace once Eclipse is running, go to "File"→"Switch Workspace".
If you are starting Eclipse for the first time with a new workspace, you may get a welcome screen. Close it to get to the workbench display.
One useful feature of an IDE is the ability of the IDE to handle some of the grunt work for you — Eclipse can auto-format your code to adhere to a particular whitespace convention and can auto-generate some standard code (such as class headers and getters and setters) and comments. Eclipse stores these settings with the workspace so you can use different configurations for different sets of projects. (This also means that you will need to repeat these configuration steps for any new workspace you create.)
Start Eclipse and make ~/cs329/workspace the current workspace if you haven't already done that.
From the "Window" menu, choose "Preferences" (Window→Preferences). On the left side, expand "Java".
Specify how code should be formatted:
Expand the "Code Style" item under "Java", then click "Formatter".
On the right side of the window, click "Import..." and then navigate your way to /classes/cs329/eclipse (start with "File System" and then double-click on each directory in turn).
Highlight cs329-formatter.xml and click "OK".
Make sure that cs329 is shown as the "Active profile".
Specify options for code generation:
Expand the "Code Style" item under "Java", then click "Code Templates".
On the right side of the window, click "Import..." and then again navigate your way to /classes/cs329/eclipse.
Highlight cs329-codetemplates.xml and click "OK".
At the bottom of the right side of the window, click the "Automatically add comments for new methods, types, modules, packages and files" box. (It should be checked.)
Tell Eclipse about the convention of naming instance variables ending with _:
Choose the main "Code Style" entry under "Java".
On the right side of the window, click on "Fields" in the box under "Conventions for variable names:" to highlight it, then click the "Edit..." button. In the box that pops up, enter _ (an underscore) in the "Suffix list" box and click OK.
Tell Eclipse to enforce Java 21 syntax rules:
Choose the main "Compiler" entry under "Java".
Set the compiler compliance level to 21.
Tell Eclipse to store compiled classes separately from source files:
Choose the main "Build Path" entry under "Java".
Make sure that the "Folders" option is selected under "Source and output folder", and that the source folder name is src and the output folder name is bin.
Finally, click "Apply and Close" at the bottom of the Preferences window to apply the new settings and close the window.
In Eclipse, create a new project named lab1 but located within your dev directory instead of the Eclipse workspace:
Uncheck the box "Use default location" and set the Location: click Browse... and navigate to ~/cs329/dev, click Open, and then manually add lab1 so that the Location refers to a lab1 subdirectory within your dev directory.
Make sure the "Create module-info.java file" box is not checked — uncheck if it necessary.
Note: if the project shows up in the Package Explorer with the name dev instead of lab1, first verify (via the system File Browser) that the directory structure is OK — there should be a directory ~/cs329/dev/lab1 containing subdirectories src and bin — and then update Eclipse's internal project name: in the Package Explorer, right-click on the project name (dev) and choose Refactor→Rename... Type lab1 and click OK.
Create a (very) simple counter program that just prints out a static value:
Leave Package blank (delete the entry lab1)
public class Counter {
public static void main(String[] args) {
System.out.println("Count: 1");
}
}
So far you just have a normal Eclipse project stored outside the workspace directory hierarchy. Time to get Git involved and create the repository!
Creating a new repository from an existing project is known as sharing the project. Eclipse's Git plugin (EGit) unfortunately has a well-known quirk when it comes to creating repositories with certain directory structures so don't use the straightforward right-click on the project then Team->Share Project... approach. Instead:
This creates the .git folder and a default .gitignore file within the project folder. Verify this by visiting ~/cs329/dev/lab1 in the system File Browser — you'll need to turn on "show hidden files" (View→Show Hidden Files) to be able to see things whose names start with ..
Back in Eclipse, you should see the lab1 repository in the Git Repositories view — the project folder and its contents will be under "Working Tree". (This is Git's working area.) You should also seem some additional decorations in the Project Explorer view — [lab1 main] is displayed after the project name, indicating what branch the current working copy is associated with, and other icons (mostly with question marks) provide information about each file's status. Keep an eye on those icons as you carry out various steps below to pick up on their meanings.
Only source code and other files that should be shared belong in a repository — generated files (such as compiled .class files) and configuration specific to a particular local environment (such as Eclipse's metadata files) do not belong in a repository. The .gitignore file provides a place to configure these exclusions so you don't have to keep avoiding them with every commit.
A default .gitignore was (probably) created as part of the previous step. If you don't see it in the Package Explorer view:
Now update it:
/bin/
/.settings/
/.classpath
/.project
Make sure there aren't any spaces at the beginning of any of the lines. Starting with / means that the path is interpreted relative to the project root — only the bin directory at the top level of the project will match in this case, not other bin directories farther down in the hierarchy.
Recall that there are two steps in creating a snapshot: staging the changes that belong in the new snapshot and then saving the snapshot to the repository.
The core solo developer workflow is the basic loop: edit, checkpoint, and repeat.
Edit:
Checkpoint:
Repeat:
Viewing history and snapshot diffs:
Document your progress so far:
Undoing/reverting:
To discard any uncommitted changes in your working area (i.e. revert to your last commit), right-click the file in the Package Explorer and choose Replace With→HEAD Revision.
To go back to an older commit, open the History view, right-click the snapshot you want to revert to and choose Reset... "Hard" makes your working area match the snapshot you've reset to — any uncommitted changes are lost along with the changes made since the snapshot you are resetting to — use a hard reset when you want to discard work done. "Mixed" and "soft" keep uncommitted changes and changes since the old snapshot as local modifications. Use "soft" when the work was good but you want to recommit different (so changes are grouped differently in snapshots) and "mixed" when there are some things to fix up before recommitting — you don't want to dump the work, but you are doing more than just regrouping commits.
To try this out:
At this point you should be back to the "Count: 1" program with only one snapshot in the history.
Branches let you try something — a new feature, a risky refactor — without touching your working main line until you are sure the new changes are good.
Create a branch:
Edit and checkpoint on this branch:
The loop has been successfully implemented, so this feature is ready to be incorporated into the main line. Switch back to the main line, then merge in the feature branch:
If there are no conflicting changes (which should be the case here), Eclipse auto-merges everything and main now contains the reset feature.
Document your progress so far:
Conflicts can arise if there are changes to the line being merged into after the branch was created. If this happens, Eclipse marks the file as conflicted in the Package Explorer and lets you resolve the problems manually.
First, try to set up a situation where conflicts arise. The idea here is to reset the main line to the point where the loop feature branched off, then make a change that overlaps with the changes implemented in the feature.
To resolve conflicts, double-click the file to open the merge editor, which shows the two versions side by side. Pick the correct lines (or edit manually). When you are done, save the file and then right-click the file in the Package Explorer and choose Add to Index to mark the conflict as resolved. Repeat until all of the conflicts are resolved, then commit to finalize the merge commit.
Document your progress so far:
Once merged, you can delete the feature branch if you don't need it anymore: first switch the working area away from it if needed, then in the Git Repositories view, expand Branches→Local, right-click the branch to delete, and choose Delete Branch.
The rest of this lab is an introduction to Eclipse — some things are basic procedures that you likely already know (and already had to do earlier in this lab) and some things are useful features you might not have seen. You are encouraged to read through it, carrying out and experimenting with any new features so that you become familiar with them. (You might need to work through some earlier steps to have the proper setup for a later task.) It is optional — only the setup and Git material above is required for completion of the lab.
Sometimes you'll want to include already-existing code in your project. To do this, you must import a resource:
Specify the destination where the imported files will be placed:
In the Package Explorer tab, right-click on the folder you want to import the files into within your project (choose src — all .java files will go under src or a subdirectory of it) and choose "Import...".
Specify what to import: (in this case, files from the file system)
In the Import dialog box, reveal the "General" tab, highlight "File System", and click "Next>".
For the "From directory:", navigate to the directory containing the file(s) you wish to import. In this case, navigate to /classes/cs329/lab1. Note that you are only selecting the directory containing the files to import in this step — you'll choose the files next!
Click on the checkboxes to select the files you wish to import (all of them — Builder.java, FindGuitarTester.java, Inventory.java, Type.java, Wood.java). If you don't see those files listed on the right side of the window, expand (but don't check the checkboxes) the necessary directories on the left.
Check the destination location:
Verify that the "Into folder" is lab1/src (the folder you want to import into) — fix it if necessary.
Complete the process:
Click "Finish".
If you are successful, you'll now see the five files listed under your project in the "Package Explorer" tab. You may need to expand the "src" and "(default package)" items — make sure that the files end up under "(default package)" and not at some other level in the directory structure. Importing files like this copies them to your project directory — any changes you make will not affect the original copy.
You may notice that some of the files have a little red X icon next to them in the Package Explorer.
Ever helpful, Eclipse warns you about potential problems and syntax errors — the little red X indicates errors while yellow ! icons are warnings. Errors and warnings are noted in multiple places: icons in the Package Explorer show files containing errors and packages/directories/projects containing files with errors; icons on the left side of the editor flag individual lines of code with problems; red and yellow boxes on the right side of the editor window show the location of problems within the whole file; icons in the "Outline" tab on the right show classes, methods, and variables with errors; and the "Problems" tab at the bottom lists information about the errors.
You can double-click on an error in the "Problems" tab or single-click on the red/yellow box on the right side of the editor window to go that error.
Double-click on the first error in the "Problems" tab. This should take you to a line near the beginning of the main program.
Eclipse will provide suggestions about how to fix the problem, and even carry out the fix for you.
Hover the mouse over the red X icon to the left of the line with the error. Don't click! In a moment, a description of the error will pop up.
Click on the red X icon to get a list of possible fixes.
Double-click on the correct fix. In this case, the problem is that the type Guitar is used but there is no Guitar class — choose "Create class 'Guitar'".
Verify that everything is correct in the new class dialog (it should be), check the "Generate comments" box if it isn't already selected, and click "Finish".
You should have a new (but empty) class Guitar, and the first error in FindGuitarTester should have gone away (though there are now new errors).
Important: Eclipse is often right about the cause of the problem — but sometimes it isn't. Don't just always choose the first fix, or assume that the correct fix must be one of the choices! Make sure you understand what the problem is and what the fixes are that Eclipse is suggesting before selecting one.
To fix the remaining errors, it is necessary to implement the Guitar class.
Add declarations for the following instance variables in the Guitar class: (remember to make them private)
Now, we need a constructor to initialize all the instance variables. You could type it by hand, or you can get Eclipse to do it for you:
Position the cursor where you want the constructor to go.
Choose "Source"->"Generate Constructor Using Fields" from the menu.
Select options for the constructor: there should be a parameter for each field (make sure all of the names are checked), it should be public ("Access modifier"), and comments should be generated (check the "Generate constructor comments" box).
Click "OK".
Voilà! A complete constructor, except for needing to fill in the comments. (You can skip that for this lab.)
Save Guitar.java. If you go back to FindGuitarTester, you should notice that some of the errors have disappeared.
Next, we need getters for each instance variable and a setter for the price. Again, you could type them by hand, but why?
Position the cursor where you want the getters to go.
Choose "Source"->"Generate Getters and Setters" from the menu.
Select the getters and setters you want — you can click the fields if you want both getters and setters, or reveal the little tab to select just the methods you want. Create getters for everything, but only the price should also have a setter.
Select additional options for the getters/setters: make them public ("Access modifier" should be "public") and generate comments (check the "Generate method comments" box).
Click "OK".
Whee, instant getters and setters! You can again skip filling in the comments.
Save Guitar.java. All of the errors in the project should now be gone.
The guitar store is expanding, and would like to also sell mandolins.
First, create a new class:
"File"->"New"->"Class"
Check over the options in the dialog box that pops up, but probably the only thing you'll need to do is fill in the name (Mandolin) in the "Name" box.
Click "Finish".
Now, implement the class:
Add the following instance variables: (make them private)
Add a constructor to initialize the instance variables from values passed in as parameters. Let Eclipse generate it for you.
Add getters and setters: getters for everything and a setter for the price. Let Eclipse generate them for you.
While you now have complete Guitar and Mandolin classes, the formatting may be a bit messy. Eclipse can fix this for you, so there's no excuse for handing in poorly formatted code.
Open Guitar in the editor.
"Source"->"Format" or press ctrl-shift-F.
Repeat for Mandolin.
At this point there shouldn't be any more errors in the program, so it is time to run it.
Right-click on the file FindGuitarTester.java (the main program) in the "Package Explorer" view and choose "Run As...->Java Application".
You should see the program's output below the editor tab — two guitars should match Erin's specifications.
Even properly formatted, Guitar and Mandolin may be a bit disorganized. To sort the elements of the class (instance variables and methods):
Open Guitar in the editor.
"Source"->"Sort Members..."
Choose whether or not you want to include instance variables in the sorting. It's OK in this case, so select "Sort all members".
Click OK.
Note that all of the instance variables are now at the beginning of the file, and the variables and methods have been sorted in alphabetical order.
Repeat for Mandolin.
Sometimes you need to change the name of something — a project, a package, a class, a method, a variable... This often involves a lot of search-and-replace while you hope you don't miss a spot — or you just decide the original name wasn't so bad after all. Eclipse makes renaming easy so there's no excuse to stick with poor naming choices.
In the example program, the name Type for the guitar type enumerated type is not the best because "Type" is pretty generic and doesn't give any clues as to what it is the type of. "GuitarType" is a more descriptive name, particularly when there may be other kinds of instruments with their own types.
Find somewhere Type is used (e.g. the declaration of the type_ instance variable in Guitar) and right-click on it. Choose "Refactor"->"Rename" from the menu.
When the "Enter new name, press Enter to refactor" prompt pops up, type in the new name. (Don't press "Enter" yet!)
Eclipse gives you control over how extensive the renaming changes are. The default is to just update references, but you can also update related usages (such as getters/setters when an instance variable name is changed, or some variable names when a class name is changed) and places where the name is used in comments and strings.
Let's get a better idea of what can be updated:
Click on the little down tab next to the "Enter new name, press Enter to refactor" prompt and choose "Open Rename Dialog...".
Check all of the boxes and click "Next>".
The next dialog box shows all the similarly named variables and methods that will be updated. You can review the choices and uncheck any that you want to leave alone.
You've decided to leave parameter and variable names alone and just change usages of the Type type — uncheck places where a variable will be renamed.
Click "Next>".
The next dialog box shows all the changes that will be made. You can review the choices and uncheck any that you want to leave alone.
Click "Finish".
Observe the results in the now-renamed GuitarType class - even the reference to Type in the constructor's comments has been updated. Also note that all other references to Type have been updated e.g. in Guitar.
"Refactoring" refers to changing a program's implementation without changing its functionality. Renaming elements is one type of refactoring; Eclipse can help in other situations as well.
Guitar and Mandolin are awfully similar — a better design might be to have an Instrument class with all of the properties common to both, and have Guitar and Mandolin extend Instrument.
Open Guitar in the editor.
"Refactor"->"Extract Superclass..."
Fill in the dialog box:
"Superclass name" — Instrument
Check "Use the extracted class where possible" — this will change references from Guitar (and Mandolin) to Instrument where possible
In "Types to extract a superclass from", click "Add..." and add Mandolin — we want Instrument to be the superclass for both Guitar and Mandolin.
In "Specify actions for members", select all of the instance variables and methods that you want to move to Instrument. (This should be everything except the variable and getter for the number of strings.) The action for the selected things should be "extract".
Click "Next>".
Select all of the methods to remove from the subclasses (because they'll be inherited from the new superclass). This should be everything.
Click "Next>".
The last screen allows you to review the changes that will be made. You can unselect things you don't want. Click "Finish" to actually complete the refactoring.
Review what happened — look over Guitar and Mandolin and the new Instrument class. Eclipse did a pretty good job, but there's one other change that should be made — Instrument should have (only) a constructor which initializes its instance variables.
Delete Instrument's default constructor and have Eclipse create one which initializes all the instance variables.
A couple of errors have now appeared, because the Guitar and Mandolin constructors made use of the default constructor in Instrument.
Open Guitar in the editor, and use Quick Fix to correct the problem (add parameters to the call of the superclass constructor).
Delete the now-unnecessary assignment statements from Guitar's constructor. (Leave only the one for numStrings_.)
Save the file. It should now be error-free.
You can fix Mandolin in the same way, or try another approach:
Open Mandolin in the editor.
Delete the constructor.
Have Eclipse generate a new constructor.
There should be no more errors, and running the program should produce the same results as before.
Finding where a variable, method, or class is defined is not usually all that difficult — but it still can get tricky in a large project with lots of packages, and hunting down a method can involve first hunting down the type of the variable it is invoked on. Fortunately Eclipse can do it for you!
So, imagine that you are reading through the main program for this inventory software, and you come across something that you want to know more about...
Open FindGuitarTester.java.
Highlight the name that you want to find the declaration for — for this example, highlight getBackWood part of the guitar.getBackWood() call in main.
Right-click on the highlighted name and choose "Declarations->Project" from the menu.
The results are displayed in the "Search" tab below the editor showing your code. (It's probably no great surprise that this method is in the Instrument class since it was part of what was common to both Guitar and Mandolin.)
Double-click on the desired entry in the "Search" tab (below the editor showing your code) to go to the declaration itself.
It is much harder to locate all the places in your code where a particular class, method, or even variable is used. Once again, Eclipse comes to the rescue.
This time you're reading through the main program and you want to know where else getBackWood is used.
Open FindGuitarTester.java.
Highlight the name for which you want to find usages — for this example, highlight getBackWood part of the guitar.getBackWood() call in main.
Right-click on the highlighted name and choose "References->Project" from the menu.
Once again, the results are displayed in the "Search" tab below the editor showing your code. You can double-click on the desired entry in the "Search" tab to go to the location of a particular reference.
Eclipse is a powerful tool, and does much more than has been described so far or that will be covered in this course. Feel free to explore and to experiment. A few things of particular interest:
The "Basic tutorial", found under "Getting Started" in the "Workbench User Guide" (accessible from "Help"->"Help Contents"), takes you through many of Eclipse's features.
The environment is highly configurable. Check out the other preferences available in the Preferences window, but you should avoid changing the Code Templates or Formatter settings (at least for this course).
The formatting, code generation, and refactoring tools described above are only some of what Eclipse can do. Explore the options on the "Source" and "Refactor" menus to see what other possibilities there are.
Eclipse also tries very hard to be useful, though it doesn't always succeed. You can find out about a lot of these "assistance" features by checking out "Tips and Tricks" under the "Help" menu (select "Eclipse Java Development Tools" when asked).