Hej Mirki od #java #spring mam zbudowany projekt reast api A działający jak ta lala. Mam za zadanie zbudować projekt rest api B, który kilka funkcjonalności/portów będzie miał tożsamych z serwisem A. Nie chcę kopiować źródeł z projektu do projektu tylko użyć źródeł z projektu A w projekcie B. Słyszałem, że się da ale jak?
@JacobTheLiar: wydziel to co wspólne jako osobny moduł. Jeśli to zupełnie osobne aplikacje to wrzuć ten moduł na repozytorium maven, ewentualnie ręcznie wrzucaj jara
@JacobTheLiar: Nada się, ale możesz zrobić też inaczej. Nie ma jednego idealnego podejścia, każde ma swe wady. W tym przypadku na + byłaby to lepsza separacja komponentów. Wspólny parent pom, IMHO jest dobry dla wspólnych elementów jednego projektu. Dla nie powiązanych ze sobą projektów, lepiej trzymać bibliotekę osobno. Ale to powoduje, że budujesz różne rzeczy by otrzymać swój projekt. Co nie zawsze jest złe, jak się biblioteka nie zmienia, to po
@draxgar: dzięki, właśnie się staram zdoktoryzować z tego im więcej czytam tym bardziej mi się rozjaśnia. Niestety widmo refaktoryzacji by wydzielić moduły zbliża się wielkimi krokami. Opcja z repozytorium mavena wydaje się fajna dostępna dla każdego ewentualnego nowego projketu.
To co mam obecnie do zbudowania to trzy niezależne projekty które w 1/3 maja wspólne porty, a nie chce swaggerm ujawiniać całej funkcjonalności...
Są 2 szkoły: 1. Wspólna biblioteka z kodem 2. Niezależne serwisy z rest, które mają część zduplikowanego kodu Dla każdego podejścia można zbudować argumenty za i przeciw. Finalnie zawsze wygrywa podejście zajmujące mniej czasu i mające mniejsze ryzyko na późniejsze kosztowne zmiany.
pozdrawiam
Opcja z repozytorium mavena wydaje się fajna dostępna dla każdego ewentualnego nowego projketu.
To co mam obecnie do zbudowania to trzy niezależne projekty które w 1/3 maja wspólne porty, a nie chce swaggerm ujawiniać całej funkcjonalności...
1. Wspólna biblioteka z kodem
2. Niezależne serwisy z rest, które mają część zduplikowanego kodu
Dla każdego podejścia można zbudować argumenty za i przeciw. Finalnie zawsze wygrywa podejście zajmujące mniej czasu i mające mniejsze ryzyko na późniejsze kosztowne zmiany.