Nel mio piccolo team scriviamo applicazioni che funzionano come un lavoro di Jenkins e utilizzando l'API SOAP del nostro Bug Tracker, il nostro software ALM. Vi si accede con Java tuttavia penso che gli sviluppatori che utilizzano altri linguaggi si trovino di fronte allo stesso problema come me che considero piuttosto comune.
Il mio problema
Diciamo che ho una classe java BugTrackerAccessMethodsImpl.java
di cui i metodi sono usati in diversi progetti Java che finiscono per essere un lavoro di Jenkins, quindi alcuni progetti necessitano della stessa base di codice.
Tuttavia, se ho migliorato BugTrackerAccessMethodsImpl.java nel Progetto A, devo aggiornarlo manualmente nel Progetto B e nel Progetto C perché anche loro hanno bisogno di quel file. Un processo noioso, suscettibile di errori e decisamente né pulito né intelligente.
Che cosa voglio fare?
Voglio fornire BugTrackerAccessMethodsImpl.java come una libreria alla quale tutti i progetti devono solo fare riferimento (penso che sia possibile in Eclipse). Se la libreria viene aggiornata, i progetti che utilizzano tale libreria ottengono automaticamente la libreria aggiornata.
(A proposito: attualmente sono l'unico che fa gli aggiornamenti su BugTrackerAccessMethodsImpl.java se questo è importante).
Le mie domande:
- Come posso fornire queste librerie internamente, in modo che ottengano legato? Penso che un disco condiviso possa essere un'opzione ma abbiamo anche SVN a nostra disposizione Con SVN potrei includere la libreria come esterna in altri progetti ma non sono riuscito a scoprire come si fa.
- Se lavori su librerie di cui hanno bisogno diversi progetti Java, è a buona pratica per mantenere un "Progetto Biblioteche" nel quale lavori le biblioteche stesse? (***) Se è così, è consigliabile creare un progetto per ogni libreria su cui lavori? Il vantaggio sarebbe che puoi mantenere anche l'ambiente di test per la libreria è piccolo.
(***) L'opposto di un "Progetto Biblioteche" sarebbe che tu avessi un progetto Java con uno scopo dedicato (es. un progetto BugTracker_Attachment_Extractor) dal quale estrai la libreria che anche altri progetti usano - a mio avviso, questo è piuttosto un approccio confuso perché poi hai la base di codice per le librerie dappertutto invece su un solo posto.