Jaką wersję etykiety użyć do rozwidlonego projektu maven?

Question

Często potrzebuję rozwidlenia projektu Java, który używa Mavena (zwykle na github).

Po rozwidleniu projektu i wprowadzeniu zmian, ogólnie chcę zwolnić moje własne prywatne (ale w internecie) repozytorium maven.

Tak więc pytanie o to, jaka powinna być etykieta wersji dla mojego niestandardowego wydania. Nie mogę zrobić SNAPSHOT, ponieważ potrzebuję tego jako wydania. Czasami sufiksuję projekt z .ADAMGENT (bo jestem narcyzem). Powiedzmy, że rozwidlałem 1.0.4-SNAPSHOT. Mogę to zmienić na 1.0.4.ADAMGENT. Nie mam pojęcia, czy to dobry pomysł. W niektórych przypadkach nie mogę tego uzyskać nawet z .ADAMGENT, ponieważ narzędzia do budowania Springa Gradle tego nie lubią. Tak więc dla projektów wiosennych robię .ADAMGENT.RELEASE lub .ADAMGENT.M1, jeśli jest to kamień milowy.

Co robią inni?

Aktualizacja:chociaż ja powiedziałem widelec ment więcej o zmianie poziomu łata. Nagroda (przez innego użytkownika) z drugiej strony może być dla widelca i/lub łatki

Answer 1

Zwykle dodanie przyrostka (na przykład imię i nazwisko), a następnie uruchomiony numer, aby uniknąć wielu mylące komunikaty sprawiają, że na podstawie tej samej wersji upstream. W konfiguracji, to prawdopodobnie przełoży się na coś takiego:

1.0.4-ADAMGENT-1 

które następnie następuje 1.0.4-ADAMGENT-2 w przypadku trzeba dokonać kolejnej zmiany.

Zdecydowanie zachowaj identyfikator artifact i group ID z oryginalnego projektu, a także wersję, na której opierasz swoje zmiany, przyda Ci się to później, jeśli będziesz musiał kiedyś dowiedzieć się, nad którą wersją pracowałeś. Ułatwia to przejście do oficjalnej wersji, jeśli twoje zmiany zostaną uwzględnione w poprzedniej wersji.

Answer 2

Jeśli jest to migawka, sugeruję użycie oryginalnego numeru wersji (czy to możliwe z git?) Lub daty rozwidlaj go, z ADAMGENTEM (dodanie własnego sufiksu jest bardzo dobrym pomysłem)

np.

1.0.4-2011-09-12.ADAMGENT 

Answer 3

Ponieważ jesteś widełkiem, użyj innego identyfikatora grupy.

Rzeczywistość jest taka, że ​​po rozpoczęciu wprowadzania zmian w lokalnym widelcu, jest inny artefakt niż. Artefakt tworzony przez Twoją organizację, a nie przez ten, z którego go wziąłeś.

Jeśli chodzi o numer wersji, jeśli twoje zmiany będą zawsze niewielkie, użyłbym głównego i prawdopodobnie pomniejszego numeru drzewa źródłowego, kiedy się rozwidlałem, inaczej zacznę od początku 1.0.0 i zanotuj w projekcie POM, z jakiej wersji go rozwinąłem.

Na przykład:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 
    <modelVersion>4.0.0</modelVersion> 
    <groupId>org.adamgent</groupId> 
    <artifactId>project-xyz</artifactId> <!-- same artifact ID --> 
    <version>1.0.0-RELEASE</version> 
    <name>My Project XYZ</name> <!-- different display name --> 
    <description>My fork of project XYZ created from v5.42.0 of original sources.</description> 
    .... 

To nie jest jakaś trudniej przełączyć identyfikator grupy na uzależnienia niż przełączyć identyfikator wersji. Oba mechanizmy można wykorzystać do łatwego uzyskania pożądanego artefaktu.Jednakże, zmieniając identyfikator grupy, można uzyskać korzyści następująco:

1. można łatwiej śledzić swoje widły wewnątrz Nexusa
2. wyeliminować wszelkie nieporozumienia, które mogłyby wyniknąć z konieczności artefaktów z organizacji, które zrobili nie tworzyć
3. pobyt w standard guidelines dla Mavena identyfikatorów wersji

Answer 4

zrobiłem pochodzić z własnego rozwiązania. Nie oznaczę tego poprawnie, ponieważ myślę, że @DavidH ma pewne ważne punkty i jeśli Maven miał poziom konfiguracji, który Ivy ma zastąpić groupid (i/lub wymyśliłem w sonatype jak to zrobić) prawdopodobnie oznaczyłbym to poprawny. W przeciwnym razie mocno wierzę, że widelec powinien być innym obszarem nazw, a nazwy pakietów Java powinny być nieco zgodne z twoimi projektami groupid. Również w mojej sytuacji często muszę to zrobić dla poprawki błędu, więc nie jest to rozwidlenie.

To jest to, co robię i to jest w oparciu o jak Maven odczytuje numery wersji i co Sonatype nieco robi:

Najpierw setup mój własny publiczny, ale nie centralne repozytorium, gdzie będę publikować moją wersję do. Możesz użyć github i/lub googlecode do obsługi takiego repozytorium. W sieci są przewodniki po tym, jak to zrobić i jak je opublikować, więc nie będę w to wchodził.

numery wersji śledzę tego formatu z wyjątkiem wiosny, ponieważ system budowania sprężyny ma dziwne wymagania jak wskazano w moje pytanie:

1.0.4-ADAMGENT-1

trochę więcej zmian i zwolnić:

1.0.4-ADAMGENT-2

Widać, że Maven będzie w większości rozumiał ten format przez looking at the code. Problemem jest kwalifikator ADAMGENT. Maven poprawnie zrozumiał tylko kilka poprawek "alpha", "beta", "milestone", "rc", "snapshot", "", "sp"` and "ga", "final", "cr".

Ci to nie są uporządkowane leksykalny (ADAMGENT w tym przypadku), który jest w porządku, a przypuszczam, że mógł się przyrostową wersję (4), jeśli to jest problem.