Dobrą praktyką jest ekstrahowanie funkcjonalności do osobnych bibliotek. Zapobiegnie to tworzeniu się zbędnych zależności, oraz pozwoli używać kody w innych projektach. Fani copyAndPasta nadal się z tym kłócą, ale to fanatycy nie słuchaj ich :). Taką bibliotekę lepiej się testuje i utrzymuje kosztem niewielkiego nakładu pracy wymaganego na stworzenie osobnego projektu. Nie chce się skupiać na samym tworzeniu biblioteki, to już trywialne zagadnienie i jest opisane w wielu miejscach. Zamiast tego pragnę udzielić drobnych wskazówek jak taką biblioteką zarządzać. Docelowo chcemy móc korzystać z naszej biblioteki w taki sam sposób jak z każdej innej
`
libraryDependencies += „org.scalway” % „java-lib” % „0.1”
`
Jakie zatem mamy możliwości? No możemy postąpić podobnie jak z innymi naszymi zależnościami, czyli pobrać naszą biblioteke z repozytorium mavena. No dobrze, ale skoro chcemy ją stamtąd pobrać to znaczy, że najpierw musimy je w jakimś repozytorium umieścić. Mamy kilka opcji.
lokalna maszyna
————————
Gdy mamy już naszą bibliotekę możemy wypchnąć ją do naszego lokalnego repozytorium za pomocą `sbt publishLocal`. Dzięki temu będziemy mogli w dowolnym innym projekcie użyć jej tak jak każdej innej `libraryDependencies += „org.scalway” % „java-lib” % „0.1”`. Po każdej zmianie wersji biblioteki (lub każdej zmianie w snapshocie) ty i twoi współpracownicy będziecie zobligowani do wywołania `sbt publishLocal`. Jeśli jesteś samotnym deweloperem może Ci to wystarczyć, lecz jeśli musisz z kimś swój kod współdzielić to szybko okaże się, że jest to strasznie niewygodne rozwiązanie.
nasze repozytorium mavena na serwerze
————————
jeśli dysponujemy serwerem możemy postawić na nim własne repozytorium które będzie nam służyć. Najpierw musimy dostosować build skrypt naszej biblioteki w taki sposób, abyśmy podczas publikowania naszej biblioteki wysyłali ją od razu na serwer. Najprostsza możliwa konfiguracja zakłada, że wyślesz pliki bezpośrednio do zasobów dostępnych przez internet np:.
`
publishMavenStyle := true
publishTo := Some(Resolver.sftp(„My Maven Repo”, „your-serwer-domain.com”, „/var/www/maven2/”))
`
oczywiście katalog musi wcześniej istnieć. po wykonaniu `sbt publish` środowisko zapyta nas o login i hasło aby wykonać owe operacje na serwerze. Oczywiście nie powinieneś robienie tego z konta roota bo jest to proszenie się o kłopoty. Po wykonaniu tej komendy każdy współpracownik ma dostęp do aktualnej wersji kodu bez potrzeby wykonywania dodatkowych kroków. Pozostaje jeszcze użycie tego repo w naszym nowym projekcie.
`
resolvers += „your-dev-machine” at „http://your-serwer-domain.com/maven2”
`
Od ustawień twojego serwera będzie zależeć czy jest repo publiczne i widoczne dla wszystkich czy prywatne i wewnątrz-firmowe. Jest to zdecydowanie wygodniejsze rozwiązanie, ale… co jeśli chcemy uczynić nasze repo publicznie dostępnym? Możemy zawsze skorzystać z trzeciej opcji.
Opublikowanie w głównym repozytorium mavena
—————————————————–
W świecie mavena jest wiele open-sourcowych projektów których użycie jest jeszcze prostsze. Nie wymagają dodawania dodatkowych resolverów i działają niemal z automatu. Jest to możliwe gdyż opublikowane są w głównym repozytorium które zawsze jest włączone i za każdym razem gdy maven szuka jakiejś biblioteki zaczyna właśnie tam. Biblioteka tak opublikowana musi spełniać dość restrykcyjne wymagania (o które nie musimy się troszczyć przy naszym prywatnym repo). To już nie jest tak trywialne jak porzednie rozwiązania więc opisze to dopiero w przyszłości.
Mam nadzieję że lektura się podobała i pomogła.
wspomogłem się blogiem na stronie: http://brizzled.clapper.org/blog/2010/05/07/sbt-and-your-own-maven-repository/