2013-07-08 14 views
9

Pracuję nad projektem Java w Eclipse, używając Mavena do budowania i zarządzania zależnościami. Projekt jest podzielony na 5 projektów Eclipse, z których jeden jest macierzystym POM. Pracuję nad implementacją serwera opartą na znacznie bardziej skomplikowanym serwerze, zaimplementowanym przez inny zespół. Więc oparłem swoją pracę na wcześniejszych kodach i plikach POM, a teraz mam wiele niepotrzebnych zależności w POM w tych projektach Eclipse.Jak (bezpiecznie) usunąć niepotrzebne zależności Mavena w Eclipse?

Relatywnie rzecz biorąc, jestem początkującym Maven, ale jestem zaznajomiony z tym poleceniem:

mvn dependency:analyze 

Kiedy uruchomić tego polecenia za pomocą wtyczki Eclipse Maven, będę się długą listę „Niewykorzystane zadeklarowaną zależności, "ale kiedy spróbuję usunąć kilka z nich, mój program się zepsuje, czasami w tajemniczy sposób.

Czy istnieje ogólnie przyjęty i sprawdzony sposób radzenia sobie z tym problemem? Czy zrezygnowałem z usuwania tych (prawdopodobnie) nieużywanych zależności jeden po drugim, upewniając się, że nic nie jest zepsute po usunięciu każdego z nich?

+0

Czy zaćmienie powoduje, że błędy kodu są szybko usuwane z powodu brakujących zależności po ich usunięciu? – vikingsteve

+0

Nie, po usunięciu tych zależności nie występują błędy czasu kompilacji. To jest zagadkowa rzecz w tej sytuacji. –

+0

Możesz mieć zależności środowiska wykonawczego, które nie wymagają błędów kompilacji. Na przykład implementacja rejestrowania, która ma być używana w środowisku wykonawczym, z uwzględnieniem pliku konfiguracyjnego. – YMomb

Odpowiedz

1

Możesz spróbować uruchomić swój kod z włączoną opcją java -verbose:class. Spowoduje to wygenerowanie wyniku pokazującego, gdzie (z którego pliku JAR) każda klasa zostanie załadowana. (Uwaga: na Sun JRE ten zostanie napisany na standardowe wyjście, myślę, że w IBM JRE robi pisanych do błędu standardowego.) Oto przykład wyjście:

[Loaded junit.framework.AssertionFailedError from file:/D:/Documents%20and%20Settings/mike/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar] 
[Loaded junit.framework.ComparisonFailure from file:/D:/Documents%20and%20Settings/mike/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar] 
[Loaded org.jmock.core.SelfDescribing from file:/D:/Documents%20and%20Settings/mike/.m2/repository/jmock/jmock/1.2.0/jmock-1.2.0.jar] 
[Loaded org.apache.log4j.spi.Configurator from file:/D:/Documents%20and%20Settings/mike/.m2/repository/log4j/log4j/1.2.9/log4j-1.2.9.jar] 
[Loaded org.apache.log4j.xml.DOMConfigurator from file:/D:/Documents%20and%20Settings/mike/.m2/repository/log4j/log4j/1.2.9/log4j-1.2.9.jar] 

Dopóki prowadzony przez większość logiki Twojego programu (aby załadować wymagane klasy), można bezpiecznie założyć, że wszystkie słoiki, które nie są wymienione w szczegółowym: wynik klasy, mogą zostać usunięte jako zależność maven.

Można również wykonać wyszukiwanie w postaci polecenia & zamień na verbose: wynik klasy, zamień go na csv na przykład, a następnie przenieś do arkusza kalkulacyjnego, aby posortować/zgrupować według plików jar.

Nadal sporo wysiłku ręcznego, ale przynajmniej dałoby to od czego zacząć!

+0

Brzmi jak najmniej bolesne rozwiązanie. Spróbuję, dzięki! –

0

Nie wiem, czy ogólnie przyjęte są najlepsze praktyki, ponieważ wszystko, od introspekcji do usług, może przerwać w czasie wykonywania. Testy jednostkowe mogą ci pomóc, ale jeśli nie masz dobrego zasięgu, mogą dać ci fałszywe poczucie bezpieczeństwa. Nadal musisz sprawdzić za pomocą testów funkcji (miejmy nadzieję zautomatyzowane) po usunięciu każdej paczki.

Powiązane problemy