Skip to content
GitLab
Commit 29c1ff34 authored by mthoma48's avatar mthoma48
Browse files

Changed name using git config

parent 53fceabc
Pipeline #1484 failed with stages
in 0 seconds
Hide whitespace changes
Inline Side-by-side
.gitignore
View file @ 29c1ff34
# This file tells git what files to "ignore"
# Typically, these are all the generated files (as we only commit source code, not binary output)
.gradle/
.idea/
build/
# This file tells git what files to "ignore"
# Typically, these are all the generated files (as we only commit source code, not binary output)
.gradle/
.idea/
build/
README.md
View file @ 29c1ff34
## A Git, GitLab, and JUnit exercise
This assignment is intended to give you a relatively small exercise to give you a little familiarisation working with Git, Gradle,
JUnit, and JavaFX on a very small codebase - before you and your group do something much more exciting on the much larger
class-wide project.
The example code you have been given is a simple JavaFX "dots and boxes" game. It has a couple of known bugs in it
(already commented for you - the task is not really in finding the bugs). Please note: your task **is not simply to fix the bugs**.
Your task is a series of steps that show you can work with git, gitlab, gradle, and junit.
You will notice that this is a git repository, but it is provided to you just as a zip that you download.
If you run `git status`, you should see that you are on branch `main`.
Dots And Boxes is normally a two-player pencil-and-paper game. See https://en.wikipedia.org/wiki/Dots_and_Boxes
In our version, a player "draws" a line by clicking on it. If it completes a square, they automatically claim the
square and get another turn. There are two known bugs in our code-base:
1. The code for checking if a square is complete is wrong. It just returns `true` at the moment, whereas it should
test if the lines surrounding the square have been "drawn".
2. The grid doesn't complain if you "draw" a line that has already been drawn. It should throw an `IllegalStateException`.
Remember, your task *isn't* just to fix the bugs.
Your tasks:
1. Create a repository on gitlab.une.edu.au and push the main branch of this repository to it **entirely unmodified**.
**You will need to set the visibility on your repository so that the marker can read from it**.
Repositories we cannot access cannot be marked (and will receive 0 until you can fix it)
2. Set your name and email on the repository for your future commits, using `git config`
3. Update the "name" label in the application to show **your name**.
Commit this change and push it to your **main** branch.
3. Create an Issue in your GitLab project for fixing the errors in the assignment.
4. Create and check out a branch for your bugfix.
This should follow the convention of having the issue number, followed by a hyphenated description of the issue.
e.g. `1-fix-assignment-errors`.
Push this branch to your remote repository. (From here on, I'll refer to this as your "issue branch")
5. Create **unit tests** that will detect the errors in the code. Particularly:
* That the algorithm for testing whether a box is complete is wrong.
* That the DotsAndBoxesGrid currently permits you to "draw" a line that has already been drawn, whereas it should throw an exception.
6. Commit these unit tests with an appropriately descriptive commit message.
**Do not fix the bugs in this commit. The unit tests should *fail*.**
Push this commit to your remote repository (on your issue branch)
7. **Tag** this commit, with the label `testsfail`. Push this tag to your remote repository.
8. Fix the bugs in the code. Run your unit tests again. The tests should now pass.
9. Commit your bugfix. Push it to your issue branch.
10. Check out `main`. Merge your issue branch to main. The tests should still pass. Push this to your gitlab repository.
11. Close your issue with a reference to the commit hash in which you fixed the bugs.
12. Paste the link to your gitlab repository into the assignment and submit.
Marking.
1. You have submitted a link to your repository on gitlab.une.edu.au and it is visible to the marker (1 point)
2. The first few commits on the main branch on the repository contains the starter code, showing me as author.
The last of my commits has the *same commit hash* as in the original code I gave you.
(i.e. you successfully pushed the original code I gave you to your GitLab repository). (1 point)
3. The next commit on the main branch adds your name to the label and shows you as author
(i.e. you have successfully configured your name & email and you have successfully created and pushed a commit) (1 point)
4. You have at least one issue on your repository for the bugfixes. It is closed referencing the bugfix commit. (1 point)
5. There is a `testsfail` tag in your repository (1 point)
6. Checking out the `testsfail` tag, and running the `gradlew test`, produces two failed tests (one for each bug). (2 points)
7. Checking out the main branch, both tests are present and pass (2 points)
8. The most recent commit on the `main` branch is a merge commit, merging the commit in which you set your name on the label
and the commit in which you fixed the tests. (1 point)
## Features of this code base
As well as being an assignment repository, this codebase is also a sample codebase, showing you a few things:
* It uses a *gradle wrapper* (a script that will download the correct version of gradle for you.) This means you can
`gradlew build` and it'll go get gradle before it builds. Normally, that would fetch from a URL on the gradle site,
but so this works behind UNE's webproxy, we've got it fetching the gradle jar from a url on turing instead.
* It is a *modular* application. JavaFX is provided as a set of modules. At the moment, that might seem like an esoteric
distinction, but if we wanted to *distribute* our application, it would be helpful. If the app is written as a
modular app (it has a `module-info.java` file), then the `gradlew distZip` task can generate a distributable zip
for us, containing not only our code but also the modules our app depends on (including JavaFX).
* It contains Log4J, which is the logging library (basically, super-powered printlns) that we will use.
* We pass lambdas around, especially as listeners and event handlers.
Lambdas may be familiar to students who've studied Scala, but they are making
their way into Java too. For instance, notice that in `DotsAndBoxesUI` we register a number of listeners onto the dots
and boxes grid by registering lambda functions.
```java
grid.addConsumer((g) -> {
if (g.getHorizontal(x, y)) {
line.setStroke(Color.BLACK);
} else {
line.setStroke(Color.LIGHTGRAY);
}
});
```
In Java, functions aren't "first class citizens" in the way they are in Scala, however. Our code here is really
creating an *anonymous inner class*.
Instead, Java has the idea of "SAM types" (Single Abstract Method types). `addConsumer` asks for an *object* of type
`Consumer<DotsAndBoxesGrid>`. But `Consumer<>` has only one abstract method. So, Java gives us the shorthand
that if we just describe how we want to implement the abstract method (`(g) -> { ...`) then the Java compiler will
fill in the rest of the code about creating an anonymous inner class of type `Consumer<>` for us.
* JavaFX uses a lot of observable lists. So for instance notice the line for adding a line to the anchorpane:
```java
anchorPane.getChildren().add(line);
```
We get the pane's list of children *and we add the line to it*. That *get ... add* code is something that is fairly
common in JavaFX code. The list of children is a mutable list that has some triggers on it, so that if you add
## A Git, GitLab, and JUnit exercise
This assignment is intended to give you a relatively small exercise to give you a little familiarisation working with Git, Gradle,
JUnit, and JavaFX on a very small codebase - before you and your group do something much more exciting on the much larger
class-wide project.
The example code you have been given is a simple JavaFX "dots and boxes" game. It has a couple of known bugs in it
(already commented for you - the task is not really in finding the bugs). Please note: your task **is not simply to fix the bugs**.
Your task is a series of steps that show you can work with git, gitlab, gradle, and junit.
You will notice that this is a git repository, but it is provided to you just as a zip that you download.
If you run `git status`, you should see that you are on branch `main`.
Dots And Boxes is normally a two-player pencil-and-paper game. See https://en.wikipedia.org/wiki/Dots_and_Boxes
In our version, a player "draws" a line by clicking on it. If it completes a square, they automatically claim the
square and get another turn. There are two known bugs in our code-base:
1. The code for checking if a square is complete is wrong. It just returns `true` at the moment, whereas it should
test if the lines surrounding the square have been "drawn".
2. The grid doesn't complain if you "draw" a line that has already been drawn. It should throw an `IllegalStateException`.
Remember, your task *isn't* just to fix the bugs.
Your tasks:
1. Create a repository on gitlab.une.edu.au and push the main branch of this repository to it **entirely unmodified**.
**You will need to set the visibility on your repository so that the marker can read from it**.
Repositories we cannot access cannot be marked (and will receive 0 until you can fix it)
2. Set your name and email on the repository for your future commits, using `git config`
3. Update the "name" label in the application to show **your name**.
Commit this change and push it to your **main** branch.
3. Create an Issue in your GitLab project for fixing the errors in the assignment.
4. Create and check out a branch for your bugfix.
This should follow the convention of having the issue number, followed by a hyphenated description of the issue.
e.g. `1-fix-assignment-errors`.
Push this branch to your remote repository. (From here on, I'll refer to this as your "issue branch")
5. Create **unit tests** that will detect the errors in the code. Particularly:
* That the algorithm for testing whether a box is complete is wrong.
* That the DotsAndBoxesGrid currently permits you to "draw" a line that has already been drawn, whereas it should throw an exception.
6. Commit these unit tests with an appropriately descriptive commit message.
**Do not fix the bugs in this commit. The unit tests should *fail*.**
Push this commit to your remote repository (on your issue branch)
7. **Tag** this commit, with the label `testsfail`. Push this tag to your remote repository.
8. Fix the bugs in the code. Run your unit tests again. The tests should now pass.
9. Commit your bugfix. Push it to your issue branch.
10. Check out `main`. Merge your issue branch to main. The tests should still pass. Push this to your gitlab repository.
11. Close your issue with a reference to the commit hash in which you fixed the bugs.
12. Paste the link to your gitlab repository into the assignment and submit.
Marking.
1. You have submitted a link to your repository on gitlab.une.edu.au and it is visible to the marker (1 point)
2. The first few commits on the main branch on the repository contains the starter code, showing me as author.
The last of my commits has the *same commit hash* as in the original code I gave you.
(i.e. you successfully pushed the original code I gave you to your GitLab repository). (1 point)
3. The next commit on the main branch adds your name to the label and shows you as author
(i.e. you have successfully configured your name & email and you have successfully created and pushed a commit) (1 point)
4. You have at least one issue on your repository for the bugfixes. It is closed referencing the bugfix commit. (1 point)
5. There is a `testsfail` tag in your repository (1 point)
6. Checking out the `testsfail` tag, and running the `gradlew test`, produces two failed tests (one for each bug). (2 points)
7. Checking out the main branch, both tests are present and pass (2 points)
8. The most recent commit on the `main` branch is a merge commit, merging the commit in which you set your name on the label
and the commit in which you fixed the tests. (1 point)
## Features of this code base
As well as being an assignment repository, this codebase is also a sample codebase, showing you a few things:
* It uses a *gradle wrapper* (a script that will download the correct version of gradle for you.) This means you can
`gradlew build` and it'll go get gradle before it builds. Normally, that would fetch from a URL on the gradle site,
but so this works behind UNE's webproxy, we've got it fetching the gradle jar from a url on turing instead.
* It is a *modular* application. JavaFX is provided as a set of modules. At the moment, that might seem like an esoteric
distinction, but if we wanted to *distribute* our application, it would be helpful. If the app is written as a
modular app (it has a `module-info.java` file), then the `gradlew distZip` task can generate a distributable zip
for us, containing not only our code but also the modules our app depends on (including JavaFX).
* It contains Log4J, which is the logging library (basically, super-powered printlns) that we will use.
* We pass lambdas around, especially as listeners and event handlers.
Lambdas may be familiar to students who've studied Scala, but they are making
their way into Java too. For instance, notice that in `DotsAndBoxesUI` we register a number of listeners onto the dots
and boxes grid by registering lambda functions.
```java
grid.addConsumer((g) -> {
if (g.getHorizontal(x, y)) {
line.setStroke(Color.BLACK);
} else {
line.setStroke(Color.LIGHTGRAY);
}
});
```
In Java, functions aren't "first class citizens" in the way they are in Scala, however. Our code here is really
creating an *anonymous inner class*.
Instead, Java has the idea of "SAM types" (Single Abstract Method types). `addConsumer` asks for an *object* of type
`Consumer<DotsAndBoxesGrid>`. But `Consumer<>` has only one abstract method. So, Java gives us the shorthand
that if we just describe how we want to implement the abstract method (`(g) -> { ...`) then the Java compiler will
fill in the rest of the code about creating an anonymous inner class of type `Consumer<>` for us.
* JavaFX uses a lot of observable lists. So for instance notice the line for adding a line to the anchorpane:
```java
anchorPane.getChildren().add(line);
```
We get the pane's list of children *and we add the line to it*. That *get ... add* code is something that is fairly
common in JavaFX code. The list of children is a mutable list that has some triggers on it, so that if you add
an element, JavaFX knows it needs to go and repaint the parent component.
\ No newline at end of file
build.gradle
View file @ 29c1ff34
buildscript {
repositories {
maven { url 'https://hopper.une.edu.au/artifactory/libs-release/' }
mavenCentral()
}
}
plugins {
id 'application'
id 'org.openjfx.javafxplugin' version '0.0.10'
}
javafx {
version = "15.0.1"
modules = [ 'javafx.controls' ]
}
group 'org.example'
version '1.0-SNAPSHOT'
repositories {
maven { url 'https://hopper.une.edu.au/artifactory/libs-release/' }
mavenCentral()
}
dependencies {
// Log4J does logging. We'll meet it properly in a later week...
implementation 'org.apache.logging.log4j:log4j-api:2.12.0'
implementation 'org.apache.logging.log4j:log4j-core:2.12.0'
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.7.0'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.7.0'
}
test {
useJUnitPlatform()
}
application {
mainClass = 'dotsandboxes.Main'
buildscript {
repositories {
maven { url 'https://hopper.une.edu.au/artifactory/libs-release/' }
mavenCentral()
}
}
plugins {
id 'application'
id 'org.openjfx.javafxplugin' version '0.0.10'
}
javafx {
version = "15.0.1"
modules = [ 'javafx.controls' ]
}
group 'org.example'
version '1.0-SNAPSHOT'
repositories {
maven { url 'https://hopper.une.edu.au/artifactory/libs-release/' }
mavenCentral()
}
dependencies {
// Log4J does logging. We'll meet it properly in a later week...
implementation 'org.apache.logging.log4j:log4j-api:2.12.0'
implementation 'org.apache.logging.log4j:log4j-core:2.12.0'
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.7.0'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.7.0'
}
test {
useJUnitPlatform()
}
application {
mainClass = 'dotsandboxes.Main'
}
\ No newline at end of file
gradle/wrapper/gradle-wrapper.properties
View file @ 29c1ff34
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://turing.une.edu.au/~cosc220/distributions/gradle-7.1.1-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://turing.une.edu.au/~cosc220/distributions/gradle-7.1.1-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
gradlew
View file @ 29c1ff34
#!/usr/bin/env sh
#
# Copyright 2015 the original author or authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
##############################################################################
##
## Gradle start up script for UN*X
##
##############################################################################
# Attempt to set APP_HOME
# Resolve links: $0 may be a link
PRG="$0"
# Need this for relative symlinks.
while [ -h "$PRG" ] ; do
ls=`ls -ld "$PRG"`
link=`expr "$ls" : '.*-> \(.*\)$'`
if expr "$link" : '/.*' > /dev/null; then
PRG="$link"
else
PRG=`dirname "$PRG"`"/$link"
fi
done
SAVED="`pwd`"
cd "`dirname \"$PRG\"`/" >/dev/null
APP_HOME="`pwd -P`"
cd "$SAVED" >/dev/null
APP_NAME="Gradle"
APP_BASE_NAME=`basename "$0"`
# Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"'
# Use the maximum available, or set MAX_FD != -1 to use that value.
MAX_FD="maximum"
warn () {
echo "$*"
}
die () {
echo
echo "$*"
echo
exit 1
}
# OS specific support (must be 'true' or 'false').
cygwin=false
msys=false
darwin=false
nonstop=false
case "`uname`" in
CYGWIN* )
cygwin=true
;;
Darwin* )
darwin=true
;;
MINGW* )
msys=true
;;
NONSTOP* )
nonstop=true
;;
esac
CLASSPATH=$APP_HOME/gradle/wrapper/gradle-wrapper.jar
# Determine the Java command to use to start the JVM.
if [ -n "$JAVA_HOME" ] ; then
if [ -x "$JAVA_HOME/jre/sh/java" ] ; then
# IBM's JDK on AIX uses strange locations for the executables
JAVACMD="$JAVA_HOME/jre/sh/java"
else
JAVACMD="$JAVA_HOME/bin/java"
fi
if [ ! -x "$JAVACMD" ] ; then
die "ERROR: JAVA_HOME is set to an invalid directory: $JAVA_HOME
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation."
fi
else
JAVACMD="java"
which java >/dev/null 2>&1 || die "ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation."
fi
# Increase the maximum file descriptors if we can.
if [ "$cygwin" = "false" -a "$darwin" = "false" -a "$nonstop" = "false" ] ; then
MAX_FD_LIMIT=`ulimit -H -n`
if [ $? -eq 0 ] ; then
if [ "$MAX_FD" = "maximum" -o "$MAX_FD" = "max" ] ; then
MAX_FD="$MAX_FD_LIMIT"
fi
ulimit -n $MAX_FD
if [ $? -ne 0 ] ; then
warn "Could not set maximum file descriptor limit: $MAX_FD"
fi
else
warn "Could not query maximum file descriptor limit: $MAX_FD_LIMIT"
fi
fi
# For Darwin, add options to specify how the application appears in the dock
if $darwin; then
GRADLE_OPTS="$GRADLE_OPTS \"-Xdock:name=$APP_NAME\" \"-Xdock:icon=$APP_HOME/media/gradle.icns\""
fi
# For Cygwin or MSYS, switch paths to Windows format before running java
if [ "$cygwin" = "true" -o "$msys" = "true" ] ; then
APP_HOME=`cygpath --path --mixed "$APP_HOME"`
CLASSPATH=`cygpath --path --mixed "$CLASSPATH"`
JAVACMD=`cygpath --unix "$JAVACMD"`
# We build the pattern for arguments to be converted via cygpath
ROOTDIRSRAW=`find -L / -maxdepth 1 -mindepth 1 -type d 2>/dev/null`
SEP=""
for dir in $ROOTDIRSRAW ; do
ROOTDIRS="$ROOTDIRS$SEP$dir"
SEP="|"
done
OURCYGPATTERN="(^($ROOTDIRS))"
# Add a user-defined pattern to the cygpath arguments
if [ "$GRADLE_CYGPATTERN" != "" ] ; then
OURCYGPATTERN="$OURCYGPATTERN|($GRADLE_CYGPATTERN)"
fi
# Now convert the arguments - kludge to limit ourselves to /bin/sh
i=0
for arg in "$@" ; do
CHECK=`echo "$arg"|egrep -c "$OURCYGPATTERN" -`
CHECK2=`echo "$arg"|egrep -c "^-"` ### Determine if an option
if [ $CHECK -ne 0 ] && [ $CHECK2 -eq 0 ] ; then ### Added a condition
eval `echo args$i`=`cygpath --path --ignore --mixed "$arg"`
else
eval `echo args$i`="\"$arg\""
fi
i=`expr $i + 1`
done
case $i in
0) set -- ;;
1) set -- "$args0" ;;
2) set -- "$args0" "$args1" ;;
3) set -- "$args0" "$args1" "$args2" ;;
4) set -- "$args0" "$args1" "$args2" "$args3" ;;
5) set -- "$args0" "$args1" "$args2" "$args3" "$args4" ;;
6) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" ;;
7) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" ;;
8) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" "$args7" ;;
9) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" "$args7" "$args8" ;;
esac
fi
# Escape application args
save () {
for i do printf %s\\n "$i" | sed "s/'/'\\\\''/g;1s/^/'/;\$s/\$/' \\\\/" ; done
echo " "
}
APP_ARGS=`save "$@"`
# Collect all arguments for the java command, following the shell quoting and substitution rules
eval set -- $DEFAULT_JVM_OPTS $JAVA_OPTS $GRADLE_OPTS "\"-Dorg.gradle.appname=$APP_BASE_NAME\"" -classpath "\"$CLASSPATH\"" org.gradle.wrapper.GradleWrapperMain "$APP_ARGS"
exec "$JAVACMD" "$@"
#!/usr/bin/env sh
#
# Copyright 2015 the original author or authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
##############################################################################
##
## Gradle start up script for UN*X
##
##############################################################################
# Attempt to set APP_HOME
# Resolve links: $0 may be a link
PRG="$0"
# Need this for relative symlinks.
while [ -h "$PRG" ] ; do
ls=`ls -ld "$PRG"`
link=`expr "$ls" : '.*-> \(.*\)$'`
if expr "$link" : '/.*' > /dev/null; then
PRG="$link"
else
PRG=`dirname "$PRG"`"/$link"
fi
done
SAVED="`pwd`"
cd "`dirname \"$PRG\"`/" >/dev/null
APP_HOME="`pwd -P`"
cd "$SAVED" >/dev/null
APP_NAME="Gradle"
APP_BASE_NAME=`basename "$0"`
# Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
DEFAULT_JVM_OPTS='"-Xmx64m" "-Xms64m"'
# Use the maximum available, or set MAX_FD != -1 to use that value.
MAX_FD="maximum"
warn () {
echo "$*"
}
die () {
echo
echo "$*"
echo
exit 1
}
# OS specific support (must be 'true' or 'false').
cygwin=false
msys=false
darwin=false
nonstop=false
case "`uname`" in
CYGWIN* )
cygwin=true
;;
Darwin* )
darwin=true
;;
MINGW* )
msys=true
;;
NONSTOP* )
nonstop=true
;;
esac
CLASSPATH=$APP_HOME/gradle/wrapper/gradle-wrapper.jar
# Determine the Java command to use to start the JVM.
if [ -n "$JAVA_HOME" ] ; then
if [ -x "$JAVA_HOME/jre/sh/java" ] ; then