Come dipendere dalle dipendenze esterne bifronte?

Question

Come dipendere dalle dipendenze esterne bifronte?

#1 da (1 voti)

2

Il nostro progetto utilizza Gradle (il cui sistema di dipendenze è compatibile con Maven IIUC). Quando dipendiamo da progetti esterni, proviamo a dipendere da versioni stabili. A volte dobbiamo dipendere da una versione di sviluppo. E a volte dobbiamo bifare il repository di una dipendenza e dipendere da quello (in generale cerchiamo di aggiornare le nostre modifiche il prima possibile).

Come possiamo garantire che tutti i nostri sviluppatori ottengano un ambiente di sviluppo coerente?

Potremmo usare i sottoregisti Mercurial (che sono simili ai sottomoduli Git e permettono di "incorporare" revisioni specifiche di repository esterni nel nostro repository). Lo svantaggio è che ogni sviluppatore deve compilare tutte le versioni non rilasciate delle dipendenze.
Potremmo configurare un server di artefatto interno e creare centralmente tutte le dipendenze forked.
- Potremmo lasciare invariata la versione della dipendenza nel repository biforcato. Quindi dobbiamo in qualche modo garantire che le modifiche nel repository vengano rilevate da tutti gli sviluppatori per avere un ambiente coerente su tutte le macchine.
- Potremmo dare a ogni revisione "significativa" del repository biforcuta una versione speciale e cambiare il nostro progetto per dipendere da queste versioni. Questo ha lo svantaggio che non possiamo semplicemente usare il ramo che usiamo per aggiornare le nostre modifiche (poiché la versione dovrebbe essere invariata quando si crea una richiesta di pull).

Pensieri? Ci sono modi migliori per risolvere questo problema?

maven gradle

posta Manuel Jacob 08.12.2017 - 20:00

fonte

1 risposta

Leggi altre domande sui tag maven gradle

Gestire relazioni molte a molte con molti tipi diversi composizione della classe php: come implementare la relazione "ha una" nel caso di un DAL

score 1 · Answer 1

We could use Mercurial subrepositories

Questo ha anche il rischio di diventare una dipendenza "nascosta": tutte le build passano così nessuno pensa di rimuovere il sottoreparto una volta che il progetto originale è stato rilasciato. È più probabile che accada se hai un numero elevato di progetti dipendenti.

We could set up an internal artifact server

Questo è ciò che ha fatto ogni squadra con cui ho lavorato, ed è solo uno dei motivi per usare un server artefatto. IMO , qualsiasi team che abbia più di uno sviluppatore e più di uno il progetto trarrà vantaggio da un repository locale, specialmente se abbinato a un build server.

La questione di come dovresti creare le risorse forate della versione è più complicata, e si tratta di stabilire se si tratta di una situazione temporanea o se hai intenzione di mantenere un fork a lungo termine.

Se stai solo cercando di ottenere build di sviluppo e il progetto utilizza il controllo delle versioni "istantanee", dovresti quasi certamente mantenere la versione del progetto (e gli ID di gruppo / artefatto). Alla fine ci sarà una versione di rilascio e puoi interrompere l'archiviazione dell'istantanea nel repository locale.

Se, d'altra parte, stai realizzando un fork a lungo termine in cui dovrai selezionare gli aggiornamenti dal progetto di origine, non dovresti solo dargli una versione, ma anche un proprio ID di gruppo e un artefatto. Pertanto, anziché com.example:someartifact:1.2.3 , utilizza com.mycompany:example-someartifact:1.2.3 . Attenzione, tuttavia, che questo introduce la possibilità di conflitti di classpath.

Are there better ways to solve this problem?

Non è un modo migliore, ma se il progetto upstream mantiene il proprio repository pubblico di build, è possibile estrarre i propri artefatti da esso. Anche in questo caso, penso che un server di repository locale che trasmette il proxy al proxy sia un'idea migliore che inserire molti riferimenti di repository espliciti nel file delle impostazioni.