Użycie Mavena i SVN

Witam
Zaczynam mały desktopowy projekt w Javie i chcę go budować Mavenem zamiast Antem.

moje pytanie:
Jak złożyć (skonfigurować) warsztat pracy, żeby móc korzystać w grupie programistów z Mavena?

uwarunkowania:

• Chciałbym użyć NetBeans IDE.
• Będzie dwóch programistów, więc musi być SVN.
• Sprawdziłem, że stworzenie pustego projektu zajmuje Mavenowi około 3 minuty, zbudowanie go (pustego) ok. półtora minuty, bo za każdym razem zaciąga z netu artefakty. To niedopuszczalnie spowalnia pracę. Stąd zastanawiam się nad użyciem Artifactory, który ponoć działa jak proxy i ściąga wszystko tylko raz, a potem pamięta lokalnie.

Maven i Artifactory są mi kompletnie nie znane, stąd mój główny problem: zrozumieć, jak się ma do siebie Artifactory i SVN , tj. czy mogą współpracować i jak???
Jakie jest nazewnictwo? Co jest wtedy czym? W jakiej kolejności instalować? Jakie muszą być ścieżki...

No i jak budować program? Ponoć dla Mavena lepiej budować w centralnym punkcie (repozytorium), bo wtedy się to odbywa za każdym razem tak samo. Ale bez sensu jest pisać soft w repo lokalnym, a budować i debugować - w centralnym... bo musiałbym robić commit przy każdej zmianie, w tym commitować kod niesprawdzony, wręcz ewidentnie błędny, żeby móc go uruchomić i zbadać...

Nie widzę w ogóle, w jaki sposób twórcy Mavena przewidzieli możliwość pracy zespołowej i praca taka nie jest wspominana w dokumentacji, ale przycież takiego softu bez obsługi pracy grupowej nikt by nie używał na poważnie.

Uparłem się, żeby użyć Mavena w tym małym projekcie, by sprawdzić go w działaniu a dopiero potem ewentualnie zaangażować do dużego projektu.

Czy ktoś używał Mavena w grupie kilku programistów i może mi powiedzieć, jak się tego używa?

pozdrawiam

p.s.1 Żeby dopełnić ironii, kod źródłowy programu Artifactory jest przechowywany w SVN, więc co? Nie używają własnego produktu?

p.2.2 Zmieniłem gruntownie układ postu i temat, żeby łatwiej można było zrozumieć, o co mi w ogóle chodzi :)

Maven dociaga pluginy i zaleznosci tylko raz na danym kompie, gdy ich jeszcze nie ma. Nastepne uruchomienia beda szybkie, szczegolnie z maven 3.
Rezty nie czytalem.

nie rozumiem Twoich wątpliwości w kontekście maven-praca zespołowa. W konfiguracyjnym pliku masz zapisane zależności od konkretnych bibliotek (ok, to jest najprostsza wersja poma ;) ) które ściągają Ci się do repo przy pierwszym uruchomieniu, więc nie musisz ich trzymać na svnie i ręcznie ściągać/dodawać do projektu.

Co do budowania projektu - wydaje mi się, że gdzieś natknąłeś się na pojęcie Continous-integration - poczytaj o Hudsonie.

Ja nie rozumiem co znaczy np tworzenie projektu w centralnym punkcie. Mi sie wydaje ze autor pomylil repozytorium mavena z repozytorium kodu.

@qdoj, mylicie pojęcia i sami sobie wprowadzacie zamęt.

1. Maven służy do zarządzania zależnościami i procesem budowy aplikacji. To tak w uproszczeniu.
   Składa się z dwóch głównych części:

• repozytorium zależności, czyli inaczej mówiąc ze specjalnego katalogu w którym przechowywane są pliki jar według określonego porządku. Repozytoria mogą być zdalne np. http://repo1.maven.org/maven2/ albo lokalne. W repozytorium lokalnym przechowywane są wszystkie zależności, które były używane na danym komputerze przez danego użytkownika (zazwyczaj znajduje się ono w $HOME/.m2/repo). W repozytorium zdalnym przechowywane są wszystkie zależności jakie istnieją (przynajmniej w teorii).
• z oprogramowania klienckiego, czyli tego co uruchamiasz na komputerze. Oprogramowanie to pobiera, zdefiniowane w pliku pom.xml, zależności z repozytorium - sprawdza repozytorium lokalne jeżeli tu nie ma to próbuje pobrać z repozytoriów zdalnych, a jak tam nie znajdzie to się wykłada. Następnie uruchamiane są kolejne fazy takie jak kompilacja, testy czy deploy na serwerze.

2. SVN jest repozytorium kodu źródłowego. Służy do zarządzania kodem źródłowym w danym projekcie. Tu programiści mogą wysyłać i stąd mogą pobierać kod źródłowy. Inne rozwiązania tego typu to CVS czy Git.
3. Artifactory jest to specjalne oprogramowanie do zarządzania zdalnym repozytorium zależności Mavena. Służy głównie do odciążenia łącza w przypadku gdy kilka osób pracujących w ramach danego LAN(LAN w tym przypadku oznacza każdą sieć wewnątrz firmy) będzie chciało pobrać daną zależność. Wtedy zostanie ona pobrana tylko raz, a następnie będzie propagowana wewnątrz organizacji "bez kosztowo", czyli bez obciążania łącza wychodzącego poza firmę. Artifactory nie jest rozwiązaniem do zarządzania kodem źródłowym! Podobne do Artifactory narzędzia to Plexus i Archivia.

Z tego co zrozumiałem potrzebujecie:

• SVN do zarządzania kodem źródłowym.
• PRAWIDŁOWO SKONFIGUROWANEGO Mavena do zarządzania zależnościami
• jakiegoś miejsca do składowania własnych już gotowych bibliotek i zarządzania zależnościami pomiędzy poszczególnymi elementami projektu.

To ostatnie można uzyskać bez konieczności instalowania rozwiązania typu Artifactory. Można wykorzystać zwykły serwer webowy z dostępem prze ftp: http://koziolekweb.pl/2008/11/17/wagonem-do-ftpa/ lub wydzielając w SVN odpowiedni katalog w celu składowania gotowych tagów w postaci plików jar: http://www.jakubiak.eu/2009/06/wagon-svn.html

Chyba wszystko...

Koziołek napisał(a)

wydzielając w SVN odpowiedni katalog w celu składowania gotowych tagów w postaci plików jar

Nie sadzilem ze w 2011 roku ktos poda jeszcze taka propozycje ;d

A niby dlaczego ma byc repozytorium mavena? Nie mozesz na google code wystawic po prostu jara do sciagniecia? Binarki w SVN to porazka.

Dobra, poddaje sie, masz racje, SVN jest odpowiednim miejscem aby trzymac binarki. I do tego wersjonowane.

@::., zaproponuj inne tanie rozwiązanie na trzymanie binarek w wygodny dla użytkowników mavena sposób. Proszę bardzo słucham lepszej odpowiedzi.
A i jeszcze jedno pamiętaj, że mówię tu o repo na Google Code :)

A dlaczego google code? Ty to zaproponowales, nie autor. Ale jak musisz to pamietam ze swojego czasu bylo repozytorium mavena dla projektor na google code, wiem ze jest repo mavena sonatype (tworcy i firma stojaca za mavenem) i mnostwo innych.
Poza tym repo mavena to raptem pare katalogow i plikow, jest mnostwo darmowych hostingow www ktore mozesz sobie zmienic na repo jesli chcesz. Plus wagon dav. Albo ftp. Albo jakies konto ssh - malo opcji? Naprawde nie wiem w czym problem.

Zastanow sie nad czym innym niz SVN, tak na marginesie. Jestesmy w XXI wieku. Dla mnie fakt uzywana SVN jest jednym z kryteriow czy chce w danej firmie pracowac czy nie (nie rozstrzygajacej, ale swiadczy o paru faktach).

@ Koziołek : dzięki za rozjaśnienie. Czytałem wcześniej dużo, m.in. art. stąd o Mavenie, ale wątpliwości, które miałem nigdzie nie dawały się rozwiać.
Rozumiem, że Jeśli sam stworzę jakiegoś jara, to mam się potem postarać, by znalazł się w repozytorium lokalnym Mavena, tak?

@ ::., Freakman : tak, myliłem pojęcia. Wydaje mi się, że w końcu zajarzyłem, jak to działa i o co w tym chodzi.
Na Hudson zerknę.

@ ::. : SVN jest zintegrowany z IDE i dostępny w wielu miejscach. To wielki atut. Rozumiem, że jest inny soft, którego używasz i który ma atuty równoważące to. Pytam bardzo serio. Jakie polecasz - inne niż SVN - rozwiązanie do grupowego pisania kodu? W grę wchodzą różne języki programowania, nie tylko Java.
Bo jakoś się boję, że to będzie tak, że wybiorę sobie coś innego zamiast SVN i będzie mi z tym potem trudniej zamiast łatwiej.

::. : "Ja nie rozumiem co znaczy np tworzenie projektu w centralnym punkcie. Mi sie wydaje ze autor pomylil repozytorium mavena z repozytorium kodu."
odpowadam:
w dokumentacji Mavena napisali, że najlepiej jest, gdy proces budowy przebiega zawsze z tego samego komputera (wybranego już wcześniej do tego celu) a nie z lokalnych maszyn konkretnych programistów raz A, raz B czy innym razem C. Stałość procesu budowy ma gwarantować, że wydanie będzie niezależne od tego, kto akurat je budował bo zawsze zbuduje się tak samo.
Ale budowa to nie tylko release, lecz także codzienne wersje snapshotowe i ogólnie chleb powszedni uruchamiania, testowania, debugowania. O to mi chodziło... Taki kod, często wadliwy, też trzeba budować i uruchamiać - o tym pisałem, ale powiedzmy, że to wątek poboczny

qdoj napisał(a)

@ ::. : SVN jest zintegrowany z IDE np. z NetBeans (aczkolwiek sam pracuję raczej w Eclipse) i dostępny w wielu miejscach. To wielki atut. Rozumiem, że jest inny soft, którego używasz i który ma atuty równoważące to. Pytam bardzo serio. Jakie polecasz - inne niż SVN - rozwiązanie do grupowego pisania kodu? W grę wchodzą różne języki programowania, nie tylko Java.

Zerknij np. na Mercuriala - wtyczka do Netbeansa jest (chyba nawet domyslnie pakowana, latwo sie uzywa), do Ecliipse jest. Check.
Jest to rozproszone repozytorium. Ma to wiele plusow, chociazby to ze kazdy z Was bedzie mial kopie repozytorium kodu na kompie, nie potrzeba laczyc sie z serwerem zeby sprawdzac diffy, historie itp. SVN robi tak ze sciaga na dysk z serwera 2 kopie ostatniej rewizji, aby moc szybko robic diffy nie idac na serwer. Ale to jedyne co robia, historia zmian itp juz jest kosmicznie wolna.
Mercurial jest prosciutki i intuicyjny, i od ponad roku go uzywamy i po prostu dziala. Z SVN mialem zawsze duzo problemow (zaraz mi ktos zarzuci ze jestem zbyt glupi aby sie nayczyc albo cos - przyjmuje na klate). Branche i merge po prostu dzialaja, bardzo zadko mamy konflikty ktore trzeba recznie rozwiazywac.
Obejrzyj ten filmik: (dotyczy produktu Killn ktory jest komercyjnym rozszerzeniem Mercuriala, ale opisuje troszke jak dziala DVCS - disctributed version control system - przymknij oko na propagandowy charakter filmiku). Disclaimer - nie mam nic wspolnego z firma FogCreek (Killn) ani Selenic (Mercurial).
Tutaj masz pierwszy tutorial: http://hginit.com/, ktory pokaze jak sie z mercurialem pracuje (linia polecen, ale polecam aby zrozumiec co robia poszczegolne komendy, pozniej przeskoczysz na wtyczke do Eclipse / NB lub TortoiseHG - swietne narzedzie pod winde).
Dodatkowo my pracujemy tak, ze czasami siedze w pracy i costam kodze dla projektow domowych, czasami w domu kodze cos do pracy, no i w ten sposob powstaja rozbieznosci w repozytoriach jak przenosze kod napisany w domu do pracy lub vice versa - w SVN / CVS (brrr) jest to duzy problem, z hg (Mercurial) nie mamy zadnych problemow - hg merge i ewentualnie pare konfliktow do rozwiazania, ktore w SVN mialbys tak czy tak, a i taki model jest niemozliwy - do takiego stylu pracy gdzie uzywasz roznych kompow aby pisac kod sprawdza sie znakomicie.

Zamiast Mercurial mozesz wszedzie wstawic git - podobne dzialanie, dojrzaly produkt, uzywany przez programistow kernela Linuxa, napisany glownie przez Linusa Torvaldsa. Minus jest taki ze ma dosc kiepskie wsparcie dla Windowsa (przynajmniej w moim odczuciu, a naszych 2 kolegow pracuje tylko i wylacznie tam).

Jest kilka darmowych hostingow, jak wspomniany google code, bitbucket, github itp, gdzie mozesz umieszczac kod swojego projektu. Do repozytorium mavena mozesz poszukac jakiegos ftp czy hostingu www z webdav, albo jakiegos konta shell gdzie przez ssh bedziecie / Hudson bedziesie laczyc i deployowac pliki. Albo mozecie miec wlasnego kompa - to zdecydowanie najlatwiejszy model. Nie musi to byc nic poteznego - zwykly komputer ktory jest widziany przez innych, chociazby Twoj. Jak jest wylaczony, to koledzy i tak moga pracowac robic commity kody bo maja lokalnie pelne repozytorium, nie jakiegos kadlubka jakiego daje SVN. Gdy wlaczysz kompa moga sciagnac zmiany innych (jesli sa jakies), zrobic merge (jesli trzeba), i wrzucic kod aby wszyscy go dostali. Dodatkowo, jesli Twoj komp nie dziala, to koledzy moga sie wymieniac swoim kodem bez twojego udzialu, np robiac hg bundle / unbundle, hg export / import, lub jesli widza nawzajem swoje kompy, moga tymczasowo postawic serwer kodu (hg serve, kazde repo moze byc serwerem, domyslnie port 8000) i sciagac od siebie nazwajem bez 'centralnego repo' - tak dzialaja DVCS. Jak sie zbudzisz i wlaczysz kompa sciagasz od nich zmiany albo mowisz im ze maja wyslac na centralne repo (hg push), Ty sciagasz i jest spojnie.

qdoj napisał(a)

::. : "Ja nie rozumiem co znaczy np tworzenie projektu w centralnym punkcie. Mi sie wydaje ze autor pomylil repozytorium mavena z repozytorium kodu."
odpowadam:
w dokumentacji Mavena napisali, że najlepiej jest, gdy proces budowy przebiega zawsze z tego samego komputera (wybranego już wcześniej do tego celu) a nie z lokalnych maszyn konkretnych programistów raz A, raz B czy innym razem C. Stałość procesu budowy ma gwarantować, że wydanie będzie niezależne od tego, kto akurat je budował bo zawsze zbuduje się tak samo.
Ale budowa to nie tylko release, lecz także codzienne wersje snapshotowe i ogólnie chleb powszedni uruchamiania, testowania, debugowania. O to mi chodziło... Taki kod, często wadliwy, też trzeba budować i uruchamiać - o tym pisałem, ale powiedzmy, że to wątek poboczny

Masz 3 programistow, kazdy z Was uzywa SVN / Mercuriala, cokolwiek, oraz mavena 3.0.2 (chyba najnowszy stabilny). Kazdy z Was ma lokalne repozytorium mavena, najpewniej znajduje sie w ~/.m2/repository (Linux) lub %USERPROFILE%/.m2/repository (Windowsy) - tam sciagane sa pluginy, zaleznosci zewnetrzne (jakies biblioteki OS, jak hibernate, springi, jasperreports, rozne, prawie wszystk jest w centralnym repo mavena i tylko czeka na sciagniecie). Macie tez jakis wspolny serwer na ktorym macie: wspolne repozytorium kodu (server SVN lub np. repo mercuriala), mavena i lokalne repozytorium, Hudsona, oraz repozytorium mavena* do ktorego beda robione deploye. Hudson ma zainstalowany plugin do mavena i mercuriala, konfigurujecie projekt, mowicie zeby co noc o 12 (lub innej godzinie o ktorej bedziecie smacznie spac) sprawdzal czy sa zmiany w kodzie, jesli tak to ma sciagnac, zbudowac projekt, przeprowadzic testy, i zrobic deploya do repozytorium mavena. To jest ciagla integracja.
*To jest drugie repozytorium, np wystawione w sieci przez apacha / ftp, z ktorego bedziecie mogli sciagac binarki projektow ktore robia inni z Was. Hudson / maven kombo bedzie po kazdym udanym buildzie robil tam deploya.

Teraz tak: Ty sobie cos piszesz, i 2 kolegow rowniez, wprowadzacie zmiany, wczucacie do glownego repo, sciagacie zmiany innych osob z glownego repo. Po dniu pracy jesli cos sie zmienilo w glownym repo, Hudson to wykryje, sciagnie, zbuduje przetestuje i zrobi deploya do repozytorium mavena. Na drugi dzien przychodzisz do pracy, budujesz sobie projekt lokalnie, maven sprawdza czy sa nowsze wersje SNAPSHOTOW w repo (musi byc skonfigurowane), jesli tak to je sciaga (pamietaj, to moga byc moduly ktorych Ty nie tworzysz).

Nie jest to takie hop siup, przynajmniejnie dla mnie, ale jest to w miare rozsadny setup. Jelsi uzywasz DVCS to 'centralne repo kodu' jest tylko konwencja, bo nie rozni sie niczym od tego co kazdy z Was ma na dysku), ale Hudson musi wiedziec skad sciagac kod do budowania. Jak chcecie to mozecie dodac zupelnie inny setup: na serwerze macie 2 repo Mercuriala, jedno QA i jedno main. Wrzucacie wszystko do QA, Hudson sciaga z niego i buduje, dopiero jesli zbuduje i przetestuje i jest ok to Hudson dalej wrzuca do main repo. Mozliwosic jest tyle ile zaspolow programistycznych.

Poki co nie podzielilem glownego repo mavena na snapshoty i release - jak sie uporasz z tym co tutaj masz (oczywiscie jesli uznasz ze ma to sens), to bedziesz juz na tyle znal te narzedzia ze bedziesz wiedzial jak samemu to zrobic. Jak nie, to wracasz na forum.

Zdaje sobie sprawe ze jest to duzo informacji, do tego napisanej chaotycznie - coz, nie jestem bswierczynski (user tego forum, pieknie pisze, a przyjemnoscia sie czyta), ale mam nadzieje ze cos z tego wyniesiesz.

Napisalem o nieczestych konfliktach, a przynajminej taki mialem zamiar.
Dziala to tak: kolega i ja bierzemy repo, wiec mamy na starcie wspolny stan. Ja pisze klase A, on klase B, obaj robimy lokalnego commita, testujemy. Teraz on robi szybciej pusha do 'centalnego repo', ja sie spoznilem - robie po nim push, dostaje komunikat ze moj push stworzylby tzw nowy head, wiec najpierw robie pulla, i mam 2 heady lokalnie, robie merge, jesli nie ma konfliktow (naprawde zadkie jesli w zespole jest dobry podzial obowiazkow), testuje, robie commita lokalnie, robie pusha. hg wie ze ten merge nie powoduje problemow i pozwala. Wszystko trwa minute. W tym samym czasie kolega robi dalej zmiany, i testuje, robi commita lokalnie, probuje zrobic pusha, ale nie moze bo ja zrobilem wczesniej pusha z mergem - wiec robi pulla, merge, push. I tak w kolko. Nie rozni sie to znacznie w stosunku do SVN, gdzie ciagle musisz robic update czy jak sie to nazywa.
Na poczatku rowniez sie zastanawialismy czy takie ciagle branczowanie i mergowanie nie jest wkurzajace, i nie jest, nie ma z nim problemu. Aby zwizualizowac sobie co i jak sa rozne narzedzia, a najprosciej jest dac hg serve i wejsc przegladarka na localhost:8000, zakladka graph log i zobaczyc co i jak.
Konflikty u nas sa naprawde rzadkie. Przeczytaj tego tutka co podalem (hg init), nie jest dlugi, i sprobuj jak to dziala. Ja najpierw w domu robilem duzo testow zanim zaproponowalem w pracy zmiane. Jeden kolega ochoczo przystal bo ma male dziecko i czesto pracuje z domu i z SVN dostawal kur**** z mergami. Szef zespolu byl dosc zaniepokojony, wiec przez jakis czas uzywalismy hg a mielismy hooka zeby wysylal do SVN zmiany, w razie jakbysmy chcieli wrocic. Po 2 miesiacach zebralismy sie pogadac co i jak, i wniosek jest jeden - zaden z nas nie wroci nigdy do SVN jak nie bedzie musial. Komfort pracy jest po prostu niesamowity, przynajmniej dla nas.

Na poczatku uzywalismy SVN, i jest narzedzie w hg zeby importowac repo SVN, zajalem sie tym i jest w porzadku. Dodatkowo z jednego wielgasnego repo SVN zrobilismy kilka mniejszych dla osobnych projektow - to jest tendencja w hg, po niewaz nie da sie klonowac (w SVN to sie nazywa checkout) fragmentu repo jak w SVN. Nam to odpowiada. Rozparcelowanie repo wymaga pliku ktory mowi co ma byc odfiltrowane.

Polecam sciagnac i poprobowac, pobawic sie, jak Ci nie bedzie pasowac to w porzadku, wcale nie musi. Ja sobie nie wyobrazam wrocic, ale inni moze nie wyobrazaja sobie rozproszonego systemu.

bardzo dziękuję za pomoc. Zwłaszcza podziękowania dla ::.

p.s. jeśli moderator uzna ten post za zbyteczny lub obciążający bazę lub niechciany, proszę o jego usunięcie.

edit:
p.s.2 Miałem na myśli usuwanie wyłącznie wpisu z podziękowaniem. Na niektórych forach pisanie osobnych postów z podziękowaniem jest piętnowane jako obciążanie bazy danych zbędnym balastem...
Cieszy mnie, że tu tak nie jest.

Swoją drogą skrzyżowanie tego wątku z artykułem o Mavenie (Koziołka) stanowi moim zdaniem dużo pełniejszy wstęp do tego oprogramowania, z tego względu, że nic tak nie pomaga w przyswojeniu nowej technologii, jak dobre wyobrażenie sposobu i celu jej użycia.
Pozdrawiam :)