dzlaczego nie lubię Mavena, cz. I

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.; 2 stycznia 2010 10:51
MZ pisze...: repozytoria w settings.xml mają niestety małą wadę - nie podlegają wersjonowaniu, dlatego wolałem zrobić zmiany w pom.xmlu; 2 stycznia 2010 14:38
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; 10 lutego 2010 11:37
Anonimowy pisze...: <exclusion>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
</exclusion>; 10 lutego 2010 11:39