Maven 3: XML, dziękuję postoję
Wielkimi krokami zbliża się do nas Maven 3. Jedną z nowości jest możliwość skorzystania z plików pom.xml w postaci skryptów Groovy/Ruby/Scala/Cokolwiek co zportujesz.
Nie wiem jak wy, ale ja jakimś wybitnym fanem XMLa nie jestem. Doceniam jego zalety w zakresie składowania i przesyłania danych, ale jako narzędzie do trzymania konfiguracji to on średnio się nadaje. Pliki pom.xml z biegiem czasu mają przykry zwyczaj rozrastania i komplikowania. Jeżeli dołożymy do tego możliwość korzystania z profili, różnych konfiguracji zależności w zależności od środowiska (inaczej lokalnie, inaczej na CI, a jeszcze inaczej na produkcji) to ogarnięcie tego galimatiasu znaczników zaczyna być czasochłonne. Nie jest trudne, ale zazwyczaj tracimy dużo czasu.
Dobra do rzeczy na podstawie tego wpisu wnioskuję, że nowy plik pom.xml będzie wyglądał na przykład tak:
Listing 1. Nowy pom.xml
project {
modelVersion '4.0.0'
parent {
artifactId 'babble'
groupId 'com.sonatype.training'
version '1.0.6-SNAPSHOT'
}
artifactId 'babble-core'
version '1.0.6-SNAPSHOT'
name 'babble-core'
url 'http://maven.apache.org'
build {
testResources {
testResource {
filtering 'true'
directory 'src/test/resources'
}
}
}
dependencies {
dependency {
groupId 'junit'
artifactId 'junit'
version '4.7'
scope 'test'
}
}
profiles {
profile {
id 'development'
properties {
'log4j.level' 'DEBUG'
}
}
profile {
id 'production'
properties {
'log4j.level' 'WARN'
}
}
}
properties {
'log4j.level' 'info'
}
}
No i git.











November 14th, 2009 at 08:58
Problem w tym, że jeśli zrobisz literówkę i zamiast profile wpiszesz porfile to nic Ci nie zasugeruje że to jest błąd, ponieważ zarówno Scala, Groovy i tak dalej są językami nieformalnymi i dla nich ta literówka to nic znaczącego, podczas gdy dla XML Schema jest to zaburzenie struktury, które zgłosi nam IDE.
Innymi słowy błąd w XML wykryjesz wcześniej niż przed uruchomieniem Mavena. Myślę, że głównie dlatego konfiguracja w XML tak mocno się trzyma – nie trzeba wiele by w IDE można było ją sprawnie edytować.
November 14th, 2009 at 22:02
Jest to argument. Nie przeczę, całkiem niezły. Wadą tego rozwiązania może być właśnie “weryfikacja i rozpoznanie bojem”. Z mojego doświadczenia z Eclipse wynika jednak, że najwięcej literówek w Scali nawsadzam zawsze gdy używam vim. Najlepszą weryfikacją kodu pod kątem literówek w językach o słabej kontroli typów i pozwalającym na dużą swobodę w rozszerzaniu istniejącego kodu jest moim zdaniem słownik ortograficzny z opcją pozwalającą na rozumienie camelCase. Wtedy jeżeli piszemy kod samodokumentujący się to wszelkie byki zostaną wyłapane tak jak w XML czy w Javie.