Usando un piccolo numero di classi da una grande libreria

Le opzioni sono:

1. interrompe la tua libreria di utilità più grande in librerie più piccole
2. usa una biblioteca più grande ovunque

Ci sono pro e contro per ogni approccio.

Con 1., alla fine avrai un componente installato più piccolo ma aumenterai il livello di coordinamento e avrai bisogno di più lavoro e cerimonie: per ogni libreria potresti avere bisogno di un nuovo repository, un nuovo descrittore di componenti (nel tuo caso un nuovo POM), un nuovo README o documentazione, una nuova configurazione per test e integrazione continua, un nuovo ciclo di versioning e release. Quindi si può finire per avere meno codice ridistribuito, ma a costo di più standard. Ma questo approccio è razionale da un punto di vista puramente ingegneristico.

Con 2., hai finalmente un componente installato efficace più grande ma non hai duplicato il boilerplate e non hai fatto un lavoro extra. Questo è un approccio pragmatico.

In molti casi, la burocrazia extra dell'opzione 1. non vale la pena e in alcune comunità raggiunge livelli assurdi: ci sono molti pacchetti node.js che finiscono per contenere più hotplat, doc, manifesti, ecc. Codice JavaScript.

Con 1., se disponi di un flusso di lavoro altamente automatizzato, i costi aggiuntivi potrebbero sembrare minimi per te e, se sei l'unico utente di questo codice, questo potrebbe funzionare correttamente. Ma quando lavori come una squadra e le utility vengono riutilizzate e mantenute da molti altri, aumenti i costi di coordinamento per ogni utente introducendo un nuovo componente.

Ci sono altri modi, però, in cui potresti avere il meglio di entrambi e limitare la duplicazione dello standard e degli sforzi:

1. Potresti conservare un singolo repository e limitare il boilerplate disponendo di più descrittori di componenti per ogni sotto-libreria da compilare: ad esempio potresti mantenere una singola struttura di codice ma avere più POM (ma dal momento che le POMs richiedono di essere nominate pom.xml potrebbe non essere pratico nel tuo caso particolare). Oppure potresti avere un singolo POM e costruire due Jars da esso.

2. Puoi regolare la build del tuo client 150 LOC per estrarre solo il sottoinsieme di classi che usi in modo efficace da questa libreria di utilità e dal fornitore / re-raggrupparle nel Jar costruito (possibilmente usando qualcosa come Maven Shade).

Personalmente, tendo a preferire mantenere le cose semplici e mantenere una singola libreria di utilità più ampia. Tuttavia, potrei iniziare a rompere le cose in componenti più piccoli quando c'è un sottoinsieme chiaro e ben definito che finisce per essere riutilizzato individualmente da almeno altri tre componenti. Non mi preoccuperei solo per un singolo utilizzo.

Per la distribuzione, puoi creare file di build che compili solo segmenti della tua libreria. Ho creato un file di form di formiche che lo realizza ricevendo un filtro di pacchetti e classi da includere nel risultato e una posizione in cui rilasciare il jar generato. Nel mio caso è specifico Java, ma questo dovrebbe essere possibile in molte lingue. È più o meno ciò che una compilazione statica di c o c ++ lo fa. Non tutti i codici vanno nell'eseguibile.