Update README.md

README.md

@@ -8,9 +8,11 @@ Javan osalta käsitellään **maven**, mutta tämän ohjeen lopussa on listattun
 
 Ohjelmointikielen mukana tulee *standardikirjasto* joka sisältää kaikki peruskäytössä tarvittavat metodit ja funktiot, kuten `print()` yms. sekä lukuisia oleellisia tyyppejä, kuten luvut, listat, sanakirjat ym. tietorakenteet. Vaikka oletuskirjastot ovatkin erittäin laajoja kokonaisuuksia, ne eivät silti sisällä kaikkea, eikä näin ole tarkoituskaan. Tämän takia eri ohjelmointikieliä varten on satoja ja tuhansia *kirjastoja* joiden avulla toiminnallisuutta saadaan laajennettua. Kirjasto on käytännössä siis vain jonkun muun tekemää koodia, joka ratkaisee jonkin tietyn ongelman. Esimerkkejä kirjastoista ovat esimerkiksi:
 
-* foo
-* bar
-* baz
+* Json-parsintakirjastot
+* Tietokannanhallinta
+* Grafiikkakirjastot
+* Pelimoottorit ja kehykset
+
 
 
 ### Dependency management
@@ -31,7 +33,9 @@ Tässä ohjeessa esitellään mavenin perusominaisuudet. Mavenia käsitellään
 
 ## POM
 
-Mavenin asetukset laaditaan XML-muodossa. POM eli *Project Object Model* määrittelee projektin tiedot, sekä riippuvuuksien ja koontiasetusten yksityiskohdat. Tämä määritellään tiedostossa `pom.xml`. Tämä tiedosto tallennetaan projektin juurihakemistoon, josta maven löytää sen käytettäessä.
+Siinä missä `git` on ohjelma, ja kaikki repositorion tiedon säilytetään hakemistossa `.git`, mavenin käyttö kohdistuu pääasiassa komentorivityökaluun `mvn` joka käsittelee projetkin hakemistossa majailevaa `pom.xml` -tiedostoa.
+
+Mavenin asetukset laaditaan XML-muodossa. POM eli *Project Object Model* määrittelee projektin tiedot, sekä riippuvuuksien ja koontiasetusten yksityiskohdat. Kaikki tämä määritellään tiedostossa `pom.xml`. Tämä tiedosto tallennetaan projektin juurihakemistoon, josta maven löytää sen käytettäessä.
 
 Esimerkki tyhjästä konfiguraatiosta:
 ```xml
@@ -47,9 +51,9 @@ Esimerkki tyhjästä konfiguraatiosta:
 Lyhyt selostus XML-formaatista niille, jotka eivät sitä tunne: Kyseessä on tagipohjainen tapa järjestellä tietoja. Kuten esimerkissä näkyy, tagi alkaa aina `<näin>` ja loppuu `</näin>`. Niiden välissä voi olla muitakin tietoja. Tietojenkäsittelytieteellisesti tietorakenne on [puun (tree)](https://en.wikipedia.org/wiki/Tree_(data_structure)) muotoinen. Huomaa, että tagien sisällä voi olla myös muita tageja. Esimerkiksi koko määrittely on yhden `<project>` -tagin sisällä ja kaikki muu on sen sisällä.
 
 * `<modelVersion>` on tämän konfiguraatiomallin versio ja se kuuluu olla näin.
-* `<groupId>` määrittää paketin ryhmän. Tämä voi olla esimerkiksi ihan vain paketin tarkoitus tai vaikka firman/organisaation nimi. Tähän tulee perinteisesti `ylätasonverkkotunnus.firma.ohjelma`. Esimerkiksi Googlen julkaisema json-parseri *gson* on ´com.google.gson`
+* `<groupId>` määrittää paketin ryhmän. Tämä voi olla esimerkiksi ihan vain paketin tarkoitus tai vaikka firman/organisaation nimi. Tähän tulee perinteisesti `ylätasonverkkotunnus.firma.ohjelma`. Esimerkiksi Googlen julkaisema json-parseri *gson* on `com.google.gson`
 * `<artifactId>` on tämän varsinaisen ohjelman/kirjaston nimi.
-* `<version>` on tämän ohjelman/kirjaston versio. Jos teet muutoksia tai parannuksia, muuta versionumeroa yhdellä isommaksi ja julkaise päivitys sitten. Tyypillisesti versionumerot ovat muotoa `major.minor.bugfix`. Suuret, mahdollisesti yhteensopivuuden rikkovat päivityksen määritellään uudella `major`-versiolla. Pienemmät uudet ominaisuudet ja parannukset `minor`-versiolla ja usein julkaistavat bugikorjaukset merkataan kasvattamalla viimeistä numeroa. Tähän ei oikeastaan ole mitään standardeja, mutta em. tulkita on varsin yleisessä käytössä.
+* `<version>` on tämän ohjelman/kirjaston versio. Jos teet muutoksia tai parannuksia, muuta versionumeroa yhdellä isommaksi ja julkaise päivitys sitten. Tyypillisesti versionumerot ovat esimerkiksi muotoa `major.minor.bugfix`. Suuret, mahdollisesti yhteensopivuuden rikkovat päivitykset tai muuten valtavat muutokset määritellään uudella `major`-versiolla. Pienemmät uudet ominaisuudet ja parannukset `minor`-versiolla ja usein julkaistavat bugikorjaukset merkataan kasvattamalla viimeistä numeroa. Tähän ei oikeastaan ole mitään standardeja, mutta em. tulkinta on varsin yleisessä käytössä.
 
 ### Esimerkkiprojektin ajaminen