Apache Ivy i lokalne repozytorium Maven - jak radzić sobie z migawkami zbudowanymi przy użyciu Mavena 3

Question

Obecnie mamy konfigurację projektu, która wykorzystuje Ivy do zarządzania zależnościami, a Ant jako ogólne narzędzie do budowania (chociaż prawdopodobnie nie ma to znaczenia tutaj). Dodatkowo mamy garść bibliotek, które są zbudowane z Maven i na których projekty (mamy ich wiele) zależą. Wiemy, że ta sytuacja jest daleka od ideału i oceniamy, jak to poprawić, ale nie możemy tego zmienić tak szybko, jak byśmy chcieli. Dlatego musimy pracować z tym, co mamy w tej chwili.

W każdym razie, tu jest problem: działało z Maven 2 i Ivy, ale ostatnio zaczęliśmy przestawiać się na Mavena 3 z kilku powodów (jeden z nich jest lepszym rozwiązaniem konfliktu) i ten rodzaj kombinacji przełamał nasze kompilacje.

Najpierw postaram się opisać, w jaki sposób nasze konstrukcje działały z Maven 2 i Ivy. Po tym dodam, że gdzie wybuchł podczas przełączania do Maven 3.

Ivy + Maven 2

Przy opracowywaniu nowych wersji naszych bibliotek, używamy zrzutów, które są zainstalowane na lokalnym Maven repo (.m2). Dodatkowo rozmieszczamy te migawki w naszym Artifactory, aby móc udostępniać pośrednie kompilacje, aby umożliwić równoległy rozwój.

Nasze projekty następnie deklarują zależności od tych migawek. Odpowiadająca ivysettings.xml wygląda następująco:

<ivysettings> 
    <settings defaultResolver="default" /> 
    <include url="${ivy.default.settings.dir}/ivysettings-local.xml" /> 
    <resolvers> 
    <ibiblio name="public" root="path.to.our.artifactory" m2compatible="true" /> 

    <filesystem name="local-maven2" m2compatible="true" checkmodified="true" changingPattern=".*SNAPSHOT">  
     <ivy pattern="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[module]-[revision].pom" /> 
     <artifact pattern="${user.home}/.m2/repository/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]" /> 
    </filesystem> 
    <filesystem name="local" checkmodified="true" changingPattern=".*SNAPSHOT"> 
     <ivy pattern="${ivy.local.default.root}/${ivy.local.default.ivy.pattern}" /> 
     <artifact pattern="${ivy.local.default.root}/${ivy.local.default.artifact.pattern}" /> 
    </filesystem> 
    <filesystem name="local2" checkmodified="true" changingPattern=".*SNAPSHOT"> 
     <ivy pattern="${user.home}/.ivy2/cache/[organisation]/[module]/ivy-[revision].xml" /> 
     <artifact pattern="${user.home}/.ivy2/cache/[organisation]/[module]/[artifact]-[revision].[ext]" /> 
    </filesystem> 

    <chain name="default" checkmodified="true" changingPattern=".*SNAPSHOT"> 
     <resolver ref="local" /> 
     <resolver ref="local-maven2" /> 
     <resolver ref="public" /> 
    </chain> 
    </resolvers> 
    <include url="${ivy.default.settings.dir}/ivysettings-shared.xml" /> 
</ivysettings> 

Dzięki tej konfiguracji Ivy należy szukać nowszych wersjach migawka i rozwiązania, które poprawnie. Nowsze wersje są identyfikowane przez porównanie daty pliku odpowiedniego pliku .pom.

Kiedy budujemy migawkę z Maven 2, odpowiedni plik .pom otrzyma datę aktualnej kompilacji, a zatem sprawdzanie się powiedzie i Ivy rozwiąże poprawne wersje migawek.

Ivy + Maven 3

Uchwała opisane powyżej przerw podczas tworzenia migawek z Maven 3. Powodem wydaje się, że zainstalowany plik .pom nie uzyskać aktualny timestamp za dniem, ale plik zachowuje datę pliku oryginalnego pom.xml, który jest kopiowany. W związku z tym Ivy nie może wykryć, czy migawka jest już nowsza.

Wygląda na to, że Maven 3 przechowuje sygnatury czasowe aktualizacji w maven-metadata-local.xml, ale Ivy nie czyta tych. Wiemy, że istnieje program ibiblio resolver (którego używamy), ale zgodnie z tym, co znamy (np. Z pytań takich jak this), ma on działać z prawdziwym usuwaniem repozytoriów i może powodować problemy podczas stosowania do lokalnego repozytorium .m2.

Pomyśleliśmy również o śledzeniu dat plików innych plików, np. maven-metadata-local.xml lub faktyczne artefakty, ale nie jesteśmy pewni, czy to jest mądre, czy może przerwać kompilację w innych sytuacjach.

Jak zatem/moglibyśmy to rozwiązać?

TL; DR

Jaka jest średnia/zasugerował sposobem obsługi Ivy współzależności z migawek, które są zbudowane z Maven 3, rozmieszczonych w lokalnym repo .m2?

UPDATE 2016-07-26

Oto 2 rzeczy próbowałem rozwiązać ten problem, ale nie jestem pewien, czy nie będzie żadnych skutków ubocznych nie myśleć. Byłbym wdzięczny, gdyby ktoś mógłby rzucić trochę światła na to:

1. Użyj rozpoznawania nazw systemu plików dla lokalnego repozytorium .m2 ale w conjection z pamięci podręcznej, która ma useOrigin="true" (i ewentualnie małą DefaultTTL). W ten sposób wydaje się, że tylko pliki xml są przechowywane w pamięci podręcznej .ivy2, a artefakty są przywoływane w repozytorium .m2, tzn. Nie są kopiowane.
   
   To wydaje się działać, ale nie jestem pewien, czy to by było, gdyby pierwsze wyszukiwanie pobrał migawkę z udostępnionego repozytorium migawek (Artifactory), a te byłyby później aktualizowane przez lokalny build. W takim przypadku prawdopodobnie uzyskalibyśmy wersję zdalną artefaktu zapisywaną w pamięci podręcznej w .ivy2 i nowszą wersję instalowaną w .m2 z datami pliku .pom będącymi tymi samymi w obu przypadkach.
2. Użyj resolwera ibiblio z root="file://${user.home}/.m2/repository/", który wydaje się być w stanie rozwiązać większość artefaktów (wyjątek patrz poniżej), ale nadal wydaje się nie działać podczas odczytu metadanych, tzn. Nie aktualizuje pamięci podręcznej nowszą wersją, którą można znaleźć w repozytorium .m2.
   
   będąc w stanie rozwiązać większość artefaktów w .m2 repo, wydaje mi się dostać błędy rozdzielczości dla kilku „adresów URL”, jak file://{user.home}/.m2/repository/javax/enterprise/cdi-api/1.0/cdi-api-1.0.jar natomiast istnieją artefakty, to znaczy ja kopiowane ścieżki bezpośrednio z Eksploratora Windows i jest "${user.home}\.m2\repository\javax\enterprise\cdi-api\1.0\cdi-api-1.0.jar".

Answer 1

... Wiemy, że ta sytuacja jest daleka od ideału, a my oceny sposobów poprawy tego, ale możemy ...

zupełnie normalne w moim doświadczeniu. Wiele dużych firm ma wiele projektów zbudowanych z mieszanki ANT, Maven i coraz bardziej Gradle.

Poniżej kilka zaleceń chciałbym zrobić

Użyj repozytorium menedżerowi

Najlepszym sposobem, aby zintegrować te różne technologie jest uruchomienie pośrednią repozytorium do przechowywania wszystkich budować wyjść. To skutecznie oddzieli twój krok budowania od tego, jak binarne artefakty zostaną później zużyte.

Zalecana repozytorium technologia repozytorium Maven (standard Java w tym momencie) i masz wybór technologii open source dostępne gościć repozytorium:

• Nexus
• Artifactory
• Archiva

Podczas uruchamiania dodatkowego serwera może wydawać się, że jest narzutem, który zwraca się w pikach jako liczba r zależnych projektów rośnie (o pojedynczym dużym współdzielonym systemie plików nie skaluje się).

W każdym razie musisz mieć kopię referencyjną plików binarnych dotyczących wydania.Te menedżery repozytorium Maven umożliwiają kontrolowanie zależności zewnętrznych, z których korzystają twoje projekty, oraz pomocnych plików pamięci podręcznej, które faktycznie skracają czas budowy i upraszczają współdzielone zarządzanie zależnościami.

Wreszcie, jak skonfigurować kompilację bluszcza, która używa repozytorium Maven? Jak wynika z wykorzystaniem ibiblio rozpoznawania nazw (a dowiesz się, że wszystkie nowoczesne narzędzia budowania Java mają podobną wsparcie dla lokalnego repozytorium Maven)

<ivysettings> 
    <settings defaultResolver="myrepo"/> 
    <resolvers> 
     <ibiblio name="myrepo" m2compatible="true" root="http://myrepo.com/path/to/repo"/> 
    </resolvers> 
</ivysettings> 

Strzeż wydaniach migawka

uwalnia snaphot to pojęcie wprowadzone przez Maven , która jest opiniotwórczą strukturą kompilacji. Moim zdaniem trzeba być bardzo celowe podczas korzystania z nich:

• Snapshots are for Dev, Release Candidates are for QA

Jak odkryliśmy Migawki są stale się zmienia i nie można powoływać się podczas dzielenia się z grupą, która spodziewa się niezmienną arefect dla testowanie (jak kontrola jakości).

Moje myślenie na ten temat została ukształtowana przez następujący delegowania który omawia podejście Maven, aby zwolnić zarządzanie:

• http://www.slideshare.net/wakaleo/continuous-deliverywithmaven

Wreszcie, podczas gdy ja polecam ograniczenie stosowania do migawek zespoły ściśle współpracujące, bluszcz wspiera je, są tylko niektóre znane ograniczenia ich użycia. Ponieważ są konstrukcją Mavena, nie są w 100% obsługiwane przez inne technologie kompilacji. To gdzie repozytorium menedżer naprawdę pomaga, jak są one zdolne do regeneracji prawidłowej metadane wspieranie wydawnictw migawki:

• What's wrong with this Ivy changingPattern/SNAPSHOT configuration?
• Publishing Ivy SNAPSHOTS with Maven metadata

Nadzieja to pomaga.