Jak utworzyć i opublikować przydatną bibliotekę Java

9

Niedawno pracowałem nad klasą Java, która generuje permutacje na listę obiektów. W każdym razie chciałbym udostępnić tę bibliotekę publiczności, więc mam kilka pytań:

Większość bibliotek, które widzę, ma skomplikowane nazewnictwo pakietów, w szczególności com/ org. Czy istnieje dla nich konwencja lub czy permutationspakiet jest wystarczający?
Czy istnieje określony format ich publikowania? Czy powinienem dołączyć osobne WAR dla kodu źródłowego / javadoc?
Mam pliki w repozytorium GitHub. Wydaje mi się, że mogę tam podać pliki, ale jak zachęcić ludzi do znalezienia mojego repo?

java open-source libraries

— Amir Rachum
źródło

Konwencja pakietu nazewnictwa jest odwróconą domena internetowa

— Daniel Moura

2

A jeśli nie mam domeny?

— Amir Rachum

1

@Amir: Więc myślę, że może coś takiego amirrachum.util.permutationsmoże być dobre.

— FrustratedWithFormsDesigner

Coś jeszcze, o czym pewnie chcesz pomyśleć - jak chcesz licencjonować ten kod? Czy ktoś może zrobić z tym, co chce? Czy chcesz, aby był używany tylko w projektach FOSS, czy jest w porządku, jeśli jest używany w oprogramowaniu prawnie zastrzeżonym (pod warunkiem, że Ci się to podoba)? Przejrzyj różne dostępne licencje typu open source (GPL, LGPL, Mozilla, Apache, MIT, BSD) i zdecyduj, której chcesz użyć.

— MatrixFrog,

9

Standardowym sposobem publikowania (oprócz kodu źródłowego na GitHub) jest posiadanie oficjalnych wydań JAR / WAR w Maven Central, których wiele (Maven, Gradle, Ant / Ivy) używa do budowania bibliotek jako zależności. Aby to zrobić, najlepiej przejść przez proces Nexus .
Uważa się również za przyjazne hostowanie tych samych plików JAR / WAR na repozytorium hostującym kod, takim jak Sourceforge lub GitHub.
Pod względem Twojej domeny. Polecam kupić firstnamelastname.net/org/com i użyć go jako schematu nazewnictwa (np. Dla mnie to net.martijnverburg.foobar). W przeciwnym razie użycie domeny github, jak sugeruje @Daniel Moura, jest dobre.
Aby go opublikować, bloguj o nim, twitteruj o nim, przesyłaj go do wiadomości hakerów, reddit, digg, slashdot, dzone, TSS, javaworld itp.

HTH!

— Martijn Verburg
źródło

+1 za proces Nexusa - bardzo przydatny w zachęcaniu innych programistów do korzystania, a zatem sprawdzania twojej biblioteki

— Gary Rowe

3

Jeśli przekazałeś kod do GitHub, udostępnianie biblioteki (słoika) jest łatwe dzięki JitPack .

Użytkownicy będą musieli jedynie dodać repozytorium do swojego build.gradle:

repositories {
    mavenCentral()
    maven { url "https://jitpack.io" }
}

a następnie Twoje repozytorium GitHub jako zależność:

dependencies {
    // ...
    compile 'com.github.YourUsername:Repo:Release'
}

JitPack działa jak repozytorium maven podobne do Maven Central. Zaletą jest to, że nie musisz przesyłać biblioteki. Za kulisami JitPack sprawdzi kod z GitHub i go skompiluje. Gdy publikujesz nowe wydanie na GitHub, staje się ono dostępne dla innych.

Jest też przewodnik na temat przygotowania projektu i przykłady dodawania słoika źródeł.

Nie jest wymagana nazwa domeny, więc groupId staje się com.github.Username. Możesz również użyć tego do nazewnictwa pakietów.

— Andrejs
źródło

2

Większość bibliotek, które widzę, ma skomplikowane nazewnictwo pakietów, szczególnie com / org. Czy istnieje dla nich konwencja lub czy wystarczający jest pakiet permutacji?

Istnieją zalecenia firmy Oracle dotyczące nazewnictwa pakietów . Powodem tej konwencji nazewnictwa jest minimalizacja duplikatów. Jeśli wszyscy po prostu użyją krótkich, prostych nazw, bardziej prawdopodobne jest, że projekt będzie zawierał dwa permutationpakiety. Jeśli nazwa jednej klasy byłaby taka sama, wystąpiłyby konflikty nazw. Sprawa może być myląca dla programisty, jeśli nie występują konflikty nazw uniemożliwiające rozwiązywanie klas.

Jeśli masz nazwę domeny, sugeruję jej użycie. Jeśli prowadzisz hosting w usłudze, takiej jak GitHub lub Sourceforge, wystarczy użyć ścieżki do swojego projektu. Niezależnie od tego, bądź wyraźny, aby uniknąć konfliktów lub zamieszania.

Czy istnieje określony format ich publikowania? Czy powinienem dołączyć osobne WAR dla kodu źródłowego / javadoc?

Nie ma określonego formatu. Przynajmniej skrypt źródłowy i konwencyjny (Make, Ant, Maven). Fajnie jest mieć wstępnie skompilowane pliki JAR lub WAR, ale nie jest to konieczne. Niektóre projekty zawierają Javadoc w bibliotece, inne mogą wygenerować dwa pliki JAR (jeden z Javadoc, a drugi bez). Dobrym pomysłem może być również opublikowanie Javadoc w Internecie, jeśli pozwala na to rozwiązanie do hostingu projektów.

Mam pliki w repozytorium GitHub. Wydaje mi się, że mogę tam podać pliki, ale jak zachęcić ludzi do znalezienia mojego repo?

Zareklamuj to. Zacznij od pokazania go kilku znajomym. Bloguj o tym. Udostępnij link w Internecie. Znajdź kogoś, kto ma problem, który może rozwiązać za pomocą tej biblioteki (ale upewnij się, że ujawniłeś, że utworzyłeś bibliotekę).

— Thomas Owens
źródło