Artefatto di Maven e denominazione groupId

291

Attualmente sto trasferendo alcuni progetti da Ant a Maven. Conformista come sono, voglio usare convenzioni consolidate per trovare groupIde artifactId, ma non riesco a trovare convenzioni dettagliate (ce ne sono alcune, ma non coprono i punti che mi chiedo).

Prendi questo progetto per esempio, prima il pacchetto Java: com.mycompany.teatimer

Tea timer in realtà è di due parole, ma le convenzioni di denominazione dei pacchetti Java vietano l'inserimento di trattini bassi o trattini, quindi sto scrivendo tutto insieme.

Ho scelto l' groupIdidentico al pacchetto ID perché penso che sia una buona idea. È?

Infine, devo scegliere un artifactId, che attualmente ho scelto teatimer. Ma quando guardo in altri progetti Maven, usano trattini per separare le parole in artifactIds, in questo modo: tea-timer. Ma sembra strano quando concatenati al groupId: com.mycompany.teatimer.tea-timer.

come lo faresti?

Un altro esempio:

Nome del pacchetto: com.mycompany.awesomeinhouseframework

groupId: com.mycompany.awesomeinhouseframework(?)

artifactId: awesome-inhouse-framework(?)

maven-2 naming-conventions

— Noarth
fonte

1

Dove vedi il groupId concatenato con l'artefattoId? Penso che le convenzioni che dichiari siano quelle giuste.

— Abhinav Sarkar,

2

In realtà, i caratteri di sottolineatura sono consentiti nei nomi dei pacchetti java, vedere: docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

— Adriaan Koster,

146

La tua convenzione sembra essere ragionevole. Se stavo cercando il tuo framework nel repository Maven, avrei cercato awesome-inhouse-framework-x.y.jarnella com.mycompany.awesomeinhouseframeworkdirectory di gruppo. E lo troverei lì secondo la tua convenzione.

Due semplici regole funzionano per me:

reverse-domain-pacchetti per groupId (poiché tali sono piuttosto unici) con tutti i vincoli relativi ai nomi dei pacchetti Java
nome del progetto come artefattoId (tenendo presente che dovrebbe essere amichevole con il nome del vaso, cioè non contenere caratteri che potrebbero non essere validi per un nome di file o semplicemente apparire strani)

— Henryk Konsek
fonte

Ok, se tu e abhin4v pensate che sia normale, allora lo farò proprio così, grazie!

— Noarth,

Trovo un po 'strano il miscuglio di non-trattino (stupendo quadro di casa) e trattino (fantastico-quadro interno). Dal momento che il groupid non consente trattini, resterei fedele all'ortografia senza trattino anche per l'artefatto.

— Michael Küller,

3

Per favore, chiarisci cosa intendi con "jar-name friendly"?

— vikramvi,

1

Chiarito nella risposta :).

— Henryk Konsek il

241

La stranezza è altamente soggettiva, suggerisco solo di seguire la raccomandazione ufficiale:

Guida alle convenzioni di denominazione su groupId, artefactId e versione

groupIdidentificherà il tuo progetto in modo univoco in tutti i progetti, quindi dobbiamo applicare uno schema di denominazione. Deve seguire le regole del nome del pacchetto, il che significa che deve essere almeno un nome di dominio che controlli e puoi creare tutti i sottogruppi che desideri. Guarda Ulteriori informazioni sui nomi dei pacchetti .

per esempio. org.apache.maven,org.apache.commons

Un buon modo per determinare la granularità di groupId è utilizzare la struttura del progetto. Cioè, se il progetto corrente è un progetto a più moduli, dovrebbe aggiungere un nuovo identificatore al groupId del genitore.

per esempio. org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting

artifactIdè il nome del vaso senza versione. Se lo hai creato, puoi scegliere il nome che desideri con lettere minuscole e senza simboli strani. Se è un vaso di terze parti devi prendere il nome del vaso quando viene distribuito.

per esempio. maven,commons-math

versionse lo distribuisci, puoi scegliere qualsiasi versione tipica con numeri e punti (1.0, 1.1, 1.0.1, ...). Non utilizzare le date in quanto sono generalmente associate alle build SNAPSHOT (notturne). Se si tratta di un artefatto di terze parti, devi usare il loro numero di versione qualunque esso sia e per quanto strano possa sembrare.

per esempio. 2.0, 2.0.1,1.3.1

— Pascal Thivent
fonte

4

Conosco queste convenzioni, ma in realtà non dicono come dovrebbe essere inventato il nome del manufatto (non ci sono convenzioni di denominazione JAR) e cosa fare se sarebbe lo stesso del groupId - Non ho visto un singolo POM dove questo è il caso.

— Noarth,

@Noarth 1. Il nome del manufatto è a tua discrezione (ma usare trattini nel nome è una pratica comune). 2. Stai cercando una "regola" assoluta che non esiste (e se il tuo fantastico framework interno fosse composto da più moduli?). Vedi ad esempio i manufatti Spring, Maven, Hibernate, ecc.

— Pascal Thivent,

No, no non ho moduli, solo semplici progetti. In effetti, non abbiamo un progetto chiamato "fantastico quadro interno" :)

— Noarth,

11

Che dire package? Qual è la differenza con groupId?

— KonstantinK,

1

È stato permesso all'artefatto di contenere dei numeri?

— theonlygusti

100

Considerare quanto segue per la creazione della prima applicazione Maven di base :

groupId

com.companyname.project

artifactId

progetto

version

0.0.1

— Manwal
fonte

Come lavoro da assumere dovrei usare com.my.company.projectcome groupIdo com.client.company.project?

— Giacomo Alzetta,

@GiacomoAlzetta puoi usare meglio qualsiasi vestito formiato. Alcuni esempi "com.companyName.hirePortal" o "org.compnayName.hirePortal".

— Manwal,

3

groupId dovrebbe essere com.companyname non com.companyname.project

— Kamil Nekanowicz,

1

Tuttavia, non sono d'accordo con la definizione ufficiale di Guida alle convenzioni di denominazione su groupId, artefactId e versione che propone che groupId debba iniziare con un nome di dominio invertito che controlli.

comindica che questo progetto appartiene a un'azienda e che orgquesto progetto appartiene a un'organizzazione sociale. Questi vanno bene, ma per quegli strani domini come xxx.tv, xxx.uk, xxx.cn, non ha senso nominare il gruppoId iniziato con "tv", "cn.", Il gruppoId dovrebbe fornire le informazioni di base del progetto anziché del dominio.

— Tommy.Tang
fonte

2

Questa convenzione impedisce agli sviluppatori di utilizzare Maven per il fatto che è necessario possedere un dominio prima di distribuire gli artefatti nel repository Maven centrale. È ridicolo. Possedere un dominio potrebbe essere un costo abbastanza anno per anno.

— Tommy.Tang

1

Non v'è alcun obbligo di possedere in realtà una registrazione per quel nome a dominio. L'unico requisito è che l'ID del tuo gruppo, che sarà il nome del tuo pacchetto Java, non sia in conflitto con altri nomi simili quando viene distribuito. Questa convenzione certamente non impedisce agli sviluppatori di utilizzare Maven.

— Basil Bourque,

Una buona pratica è derivare i nomi dei pacchetti dall'URL del repository. Se stai usando GitHub, il tuo account viene chiamato myusere il tuo repository viene chiamato myrepo, quindi usa semplicemente il nome del pacchetto com.github.myuser.myrepo. È gratuito e ancora unico.

— fxnn

-14

Considera questo per ottenere un file jar completamente unico:

GroupID - com.companyname.project
ArtefattoId - com-companyname-project
Pacchetto - com.companyname.project

— programmatore
fonte