Come creare e pubblicare un'utile libreria Java

9

Di recente ho lavorato su una classe Java che genera permutazioni per elenco di oggetti. In ogni caso, vorrei che questa biblioteca fosse offerta al pubblico, quindi ho diverse domande:

La maggior parte delle librerie che vedo hanno questa complessa denominazione dei pacchetti, incluso in particolare com/ org. Esiste una convenzione per questi o è permutationssufficiente un pacchetto?
Esiste un formato specifico per pubblicarli? Dovrei includere WAR separati per codice sorgente / javadoc?
Ho i file su un repository GitHub. Immagino di poter servire i file lì, ma come posso convincere le persone a trovare il mio repository?

java open-source libraries

— Amir Rachum
fonte

La convenzione per la denominazione dei pacchetti è il dominio Internet invertito

— Daniel Moura,

2

E se non ho un dominio?

— Amir Rachum,

1

@Amir: Quindi penso che forse qualcosa del genere amirrachum.util.permutationspotrebbe essere buono.

— FrustratedWithFormsDesigner,

Qualcos'altro a cui probabilmente vorresti pensare: come vuoi concedere in licenza questo codice? Qualcuno può fare quello che vuole con esso? Vuoi che venga utilizzato solo nei progetti FOSS o ti va bene se viene utilizzato in software proprietario (a condizione che ti accreditino)? Esamina le varie licenze open source disponibili (GPL, LGPL, Mozilla, Apache, MIT, BSD) e decidi quale vuoi usare.

— MatrixFrog,

9

Un modo standard per pubblicare (a parte il codice sorgente su GitHub) è di avere versioni JAR / WAR formali su Maven Central che molti strumenti di costruzione (Maven, Gradle, Ant / Ivy) usano per portare le librerie come dipendenza. Per fare ciò, il modo migliore è passare attraverso il processo Nexus .
È anche considerato amichevole ospitare quegli stessi JAR / WAR su un repository di hosting di codice come Sourceforge o GitHub.
In termini di dominio. Ti consiglio di acquistare firstnamelastname.net/org/com e utilizzarlo come schema di denominazione (ad esempio per me è net.martijnverburg.foobar). Altrimenti usare il dominio github come suggerito da @Daniel Moura è buono.
Per pubblicizzarlo, blog su di esso, twitter su di esso, inviarlo a notizie di hacker, reddit, digg, slashdot, dzone, TSS, javaworld ecc

HTH!

— Martijn Verburg
fonte

+1 per il processo Nexus - molto utile per far sì che altri sviluppatori utilizzino e quindi riesaminino la tua libreria

— Gary Rowe,

3

Se hai inviato il tuo codice a GitHub, condividere la tua libreria (jar) è facile con JitPack .

I tuoi utenti dovranno solo aggiungere il repository al loro build.gradle:

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

e quindi il tuo repository GitHub come dipendenza:

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

JitPack funge da repository maven simile a Maven Central. La cosa bella è che non devi caricare la tua libreria. Dietro le quinte, JitPack verificherà il codice da GitHub e lo compilerà. Man mano che pubblichi una nuova versione su GitHub, diventa disponibile per altri utenti.

C'è anche una guida su come preparare un progetto ed esempi per l'aggiunta di un vaso di fonti.

Non è necessario avere un nome di dominio, quindi il tuo groupId diventa com.github.Username. Puoi anche usarlo per la denominazione dei pacchetti.

— Andrejs
fonte

2

La maggior parte delle librerie che vedo hanno questa complessa denominazione dei pacchetti, in particolare com / org. Esiste una convenzione per questi o è sufficiente un pacchetto di permutazioni?

Ci sono consigli di Oracle su come nominare i pacchetti . Il motivo di questa convenzione di denominazione è ridurre al minimo i duplicati. Se tutti hanno semplicemente usato nomi brevi e semplici, è più probabile che un progetto includa due permutationpacchetti. Se il nome di una classe fosse lo stesso, ci sarebbero conflitti di denominazione. Le cose possono diventare confuse per lo sviluppatore, se non ci sono conflitti di denominazione che impediscono la risoluzione delle classi.

Se hai un nome di dominio, suggerirei di usarlo. Se stai ospitando su un servizio come GitHub o Sourceforge, anche utilizzare il percorso del tuo progetto sarebbe sufficiente. Indipendentemente da ciò, sii esplicito per prevenire conflitti o confusione.

Esiste un formato specifico per pubblicarli? Dovrei includere WAR separati per codice sorgente / javadoc?

Non esiste un formato specifico. Per lo meno, fonte e uno script di costruzione della convenzione (Make, Ant, Maven). È bello avere JAR o WAR precompilati, ma non essenziale. Alcuni progetti includono Javadoc nella libreria, altri potrebbero produrre due JAR (uno con Javadoc e uno senza). Potrebbe anche essere una buona idea pubblicare semplicemente il tuo Javadoc su Internet se la tua soluzione di hosting del progetto lo consente.

Ho i file su un repository GitHub. Immagino di poter servire i file lì, ma come posso convincere le persone a trovare il mio repository?

Pubblicizzalo. Inizia mostrandolo ad alcuni amici. Blog a riguardo. Condividi un collegamento su Internet. Trova qualcuno che ha un problema che può risolvere usando questa libreria (ma assicurati di rivelare che hai creato la libreria).

— Thomas Owens
fonte