niedziela, 27 grudnia 2009

dzlaczego nie lubię Mavena, cz. I

W świecie sposobów budowania aplikacji javowych królują 2 rozwiązania: Apache Ant i Maven2. Od jakiegoś czasu uczestniczę w sporym projekcie opartym o to drugie rozwiązanie. O ile Maven (1) miał opinie rozwiązania nie do końca dopracowanego, o tyle głosy na temat Mavena2 są w większości pochlebne: bo lepszy, bo nowszy, bo deklaratywny, bo sam martwi się o zależności.
Teoretycznie wszystko wygląda ładnie, a w praktyce...
... a w praktyce potrzebuję skorzystać z biblioteki XML-RPC Server. Co robię w takim przypadku?
Wchodzę na stronę http://mvnrepository.com/
i wpisuję nazwę szukanej biblioteki.
Coś znalazłem, więc dodaję zależność do pliku pom.xml

<dependencies>
<dependency>
<groupId>org.apache.xmlrpc</groupId>
<artifactId>xmlrpc-server</artifactId>
<version>3.1.2</version>
</dependency>
</dependencies>

i kompiluję projekt, a tu niespodzianka:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
error: error reading /home/mateusz/.m2/repository/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar; error in opening zip file


Hm... chwila refleksji... i nie wiadomo o co chodzi. Z pomocą przychodzi cat

cat ~/.m2/repository/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://download.java.net/maven/1/javax.servlet/jars/servlet-api-2.3.jar">here</a>.</p>
<hr>
<address>Apache Server at maven-repository.dev.java.net Port 443</address>
</body></html>


No tak... jar to to nie jest.
Aby skompilować projekt, trzeba usunąć ten tekstowy "jar":

rm ~/.m2/repository/javax/servlet/servlet-api/2.3/servlet-api-2.3.jar


i dodać w pliku pom.xml repozytorium


<repositories>
<repository>
<id>java.net</id>
<name>java.net</name>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</repository>
</repositories>


Cóż, nowe możliwości, nowe problemy... ale przy servlet API? A może to z moim podejściem do mavena jest coś nie tak? Przyznam się, że w głównej mierze polega ono na rozpoznaniu walką.

4 komentarze:

Koziołek pisze...

No generalnie jest tak, że Maven musi być dobrze skonfigurowany. Warto do settings.xml dodać kilka repozytorów i w miarę na bieżąco aktualizować tą listę. Względnie warto sobie postawić takie małe lokalne proxy w postaci artifactory/archiva i tam dodawać repozytoria.
Maven bez dobrej konfiguracji jest strasznie toporny niestety.

MZ pisze...

repozytoria w settings.xml mają niestety małą wadę - nie podlegają wersjonowaniu, dlatego wolałem zrobić zmiany w pom.xmlu

Anonimowy pisze...

Cześć Panowie,

Trochę mnie zdziwił ten post bo opisany problem to z pewnością nie problem Maven-a, tylko śmietnika w lokalnym repozytorium, które domyślnie Maven tworzy w katalogu [~/.m2].
Z tego co widać to pozostałość po nie istniejącym już repozytorium z którego musiałeś kiedyś korzystać podczas jakiegoś researchu. Normalnie nic się nie usuwa ani nie cuduje. Pamiętajmy o tym, że "problematyczne" zależności przechodnie zawsze możemy wykluczyć:



org.apache.xmlrpc
xmlrpc-server
3.1.2


javax.servlet
servlet-api

Anonimowy pisze...

<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>