diff --git a/simpleexample/.classpath b/simpleexample/.classpath
index 10d994043387f57590a3a567df89e601500658ba..1b083eab54f1c489da772f34489bf2f17149e176 100644
--- a/simpleexample/.classpath
+++ b/simpleexample/.classpath
@@ -24,7 +24,7 @@
 			<attribute name="gradle_used_by_scope" value="test"/>
 		</attributes>
 	</classpathentry>
-	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-12/"/>
+	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-10/"/>
 	<classpathentry kind="con" path="org.eclipse.buildship.core.gradleclasspathcontainer"/>
 	<classpathentry kind="output" path="bin/default"/>
 </classpath>
diff --git a/simpleexample/README.md b/simpleexample/README.md
index ee1f95d1436f69965461df3d91b63fe99e7384d6..3972680f89bf9d9c3ddc81fea3fe5c979fcbbfd6 100644
--- a/simpleexample/README.md
+++ b/simpleexample/README.md
@@ -32,3 +32,17 @@ Persistenslaget inneholder alle klasser og logikk for lagring (skriving og lesin
 Persistenslaget finnes i **[simpleex.json](src/main/java/simpleex/json/README.md)**-pakken.
 
 ## Bygging med gradle
+
+For litt mer komplekse prosjekter, er det lurt å bruke et såkalt byggeverktøy, f.eks. gradle eller maven, for å automatisere oppgaver som kjøring av tester, sjekk av ulike typer kvalitet osv. Vårt prosjekt er konfigurert til å bruke [gradle](https://gradle.org), og følgelig har prosjektet en del filer og mapper spesifikt for det:
+
+- gradle, gradlew og gradlew.bat - mappe og filer for kjøring av gradle, som regel rigget opp en gang for alle ved opprettelse av prosjektet 
+- settings.gradle - inneholder navnet på prosjektet og evt. navnet på mapper for delprosjekter (ikke brukt her)
+- build.gradle - konfigurasjon av gradle-tillegg basert på typen prosjekt
+
+Av disse er det build.gradle som krever mest forklaring, settings.gradle trenger bare å inneholde én linje, som navngir prosjektet: `rootProject.name = 'simpleexample'`. For litt bakgrunn om bygging generelt og gradle spesielt, se [her](ci-gradle.md).
+
+VÃ¥rt gradle-bygg er satt opp med tillegg for java-applikasjoner generelt (**application**) og med JavaFX spesielt (**org.openjfx.javafxplugin**). Vi trenger (minst) java-versjon 10 og javafx-version 11.
+
+I tillegg bruker vi diverse kodekvalitetsanalyseverktøy ([jacoco](https://github.com/jacoco/jacoco) med **[jacoco](https://docs.gradle.org/current/userguide/jacoco_plugin.html)**, [PMD](https://pmd.github.io) med **[pmd](https://docs.gradle.org/current/userguide/pmd_plugin.html)**, [spotbugs](https://spotbugs.github.io) med **[com.github.spotbugs](https://spotbugs.readthedocs.io/en/latest/gradle.html)** og [checkstyle](https://checkstyle.sourceforge.io) med **[checkstyle](https://docs.gradle.org/current/userguide/checkstyle_plugin.html)**). Disse er satt opp slik at de ikke stopper bygget om ikke alt er på stell. spotbugs er satt opp til å lage rapport med html i stedet for xml.
+
+De fleste avhengighetene hentes fra de vanlige sentrale repo-ene, med unntak av FxMapControl som er lagt ved som jar-fil i **libs**-mappa.
diff --git a/simpleexample/build.gradle b/simpleexample/build.gradle
index 7ef91a799bdab2401d876fb755e46a885391d05c..24b0821522be6ec138112520162331780b0d2096 100644
--- a/simpleexample/build.gradle
+++ b/simpleexample/build.gradle
@@ -25,11 +25,13 @@ repositories {
     }
 }
 
+sourceCompatibility = JavaVersion.VERSION_1_10
+targetCompatibility = JavaVersion.VERSION_1_10
 mainClassName = 'simpleex.ui.FxApp' // application plugin
 
 // javafx specific way of specifying dependencies
 javafx {
-	version = '12'
+	version = '11'
     modules = [ 'javafx.controls', 'javafx.fxml' ]
     // run with --debug-jvm flag and
     // launch debugger using Remote Java Application debug launch configuration
@@ -68,10 +70,14 @@ checkstyle {
 }
 
 dependencies {
+	// persistens
     compile "com.fasterxml.jackson.core:jackson-databind:2.9.8"
-    // compile 'fischer.clemens:FxMapControl:1.0'
+    // brukergrensesnitt
     compile name: 'fx-map-control-1.0'
+    
     testImplementation 'junit:junit:4.12'
+
+    // brukergrensesnitt
     testImplementation "org.testfx:testfx-core:4.0.16-alpha"
     testImplementation "org.testfx:testfx-junit:4.0.16-alpha"
 	testImplementation "org.mockito:mockito-core:2.28.2"
diff --git a/simpleexample/ci-gradle.md b/simpleexample/ci-gradle.md
new file mode 100644
index 0000000000000000000000000000000000000000..430397df9a9fa88bd84e089127b8fb6cf09e9f75
--- /dev/null
+++ b/simpleexample/ci-gradle.md
@@ -0,0 +1,33 @@
+# Bygging med gradle
+
+## Hva er bygging?
+
+Moderne IDE-er gjør det nokså greit å sett opp et prosjekt slik at kompilering gjøres automatisk og kontinuerlig og kjøring gjøres med et tastetrykk eller klikk. I det skjulte håndteres riktig oppsett og bruk av biblioteker, tilsvarende å kalle java-kompilatoren med riktig classpath (og med de siste versjonenen av java, også modulepath osv). Så mens man i gamle dager måtte skrive inn kompileringskommandoer på kommandolinja, så gjøres det automatisk, i tillegg til at editoren kan komme med alskens automatiske forslag til koden basert på full oversikt over tilgjengelige API-er.
+
+Dette er vel og bra, men utvikling av applikasjoner handler ikke bare om å skrive kode, det er mange relaterte aktiviteter som er med og sikrer kvaliteten. Hvis en f.eks. skriver tester, så må disse forholde seg til egne testbibliotek (som [junit](https://junit.org/) og [mockito](https://site.mockito.org)) kjøres jevnlig. Testkjøring av systemer som består av mange moduler, kanskje én av dem er en web-server som skal startes som en del av en test, gjør det mye mer komplisert.
+
+Det er lurt å måle hvor stor del av koden som faktisk kjøres av tester, f.eks. med [jacoco](https://github.com/jacoco/jacoco). Noen prosjekter består av mange deler som både testes hver for seg og sammen. Det finnes andre kvaliteter enn korrekthet som også kan analyseres av diverse verktøy, f.eks. ryddighet, om man har fulgt konvensjoner for koding og unngått typiske kodingsfeil.
+
+Hvis alt dette skal gjøres/kjøres manuelt, så gidder man ikke å gjøre det (ofte nok). IDE-er kan riktignok være til hjelp, men da blir det til gjengjeld opp til hver utvikler å sette det opp og det kan kreve nokså mye konfigurasjon. I stedet konfigurerer man prosjektet til å bruke et såkalt byggeverktøy, som lar deg kjøre utvalgte byggeoppgaver i riktig sekvens, basert på instruksjoner om hva slags prosjekt en har, hvilke byggetrinn som skal være med og detaljer ved disse. Innstillingene er uavhengig av hvilken IDE du bruker, skrevet i et (mer eller mindre) leselig format og kan sjekkes inn i kode-repo og deles med alle.
+
+## Gradle
+
+[Gradle](https://docs.gradle.org/current/userguide/userguide.html) er et slikt byggesystem, som automatiserer oppgaver knyttet til utvikling og kvalitetssikring av programvare, f.eks.
+kompilering, kjørings av enhetstester og integrasjonstester, konvertering av dokumentasjon til HTML, pakking som kjørbart program, osv. Det finnes teknisk sett ikke grenser for hva byggesystem som gradle kan gjøre, generelt handler det om å automatisere bort alt praktisk fikkel, som ellers hindrer en å jobbe effektivt.
+
+Det finnes flere byggesystem, de viktigste i Java-verdenen er https://maven.apache.org[Maven] og Gradle, mens Javascript-verdenen har sine, bl.a. [npm](https://docs.npmjs.com). Når vi velger å bruke gradle, så er det fordi det er enklere å skrive og lese oppsettet og trigge kjøring, mer fleksiblet og
+det vi ønsker å automatisere i akkurat dette prosjektet er innafor det Gradle håndterer godt. For andre Java-prosjekter [kan Maven være et bedre alternativ](https://phauer.com/2018/moving-back-from-gradle-to-maven/). 
+
+Gradle er bygget rundt tre sentrale elementer:
+
+- oppgaver (tasks) - det som automatiseres, f.eks. kompilering, kjøring av tester, osv.
+- prosjekter - enhetene som oppgaver utføres innenfor
+- tillegg (plugins) - angir hvilke oppgaver som hører til et visst type prosjekt.
+
+Oppsettet for bygging består bl.a. i å angi hvilke (del)-prosjekter som inngår i hovedprosjektet,
+hvilke avhengigheter det er til eksterne moduler og mellom prosjektene, hvilke tillegg som bør aktiveres for disse prosjektene (basert på hva slags type prosjekt det er) og hvordan hver type oppgave skal konfigureres.
+
+Det litt spesielle med Gradle er at filene for å sette opp et Gradle-bygg egentlig er [kode skrevet i det Java-lignende språket Groovy](https://docs.gradle.org/current/userguide/groovy_build_script_primer.html). Koden brukes primært til konfigurasjon, altså bygge opp beskrivelsen av oppgavene,  prosjektene og tilleggene og. API-et er utformet slik at koden skal se deklarativ ut.
+En kan flette inn vanlig kode også, hvis en skjønner litt om hvordan API-et virker. Dette gir enorm fleksibilitet, men kan også gjøre filene vanskelige å forstå.
+
+De to viktigste filene for å sette opp et Gradle-bygg er **settings.gradle** og **build.gradle**.