Perché il team di sviluppo di IntelliJ IDEA memorizza le sue dipendenze come jar (ad esempio JUnit) all'interno delle proprie cv?

Question

Perché il team di sviluppo di IntelliJ IDEA memorizza le sue dipendenze come jar (ad esempio JUnit) all'interno delle proprie cv?

#1 da (5 voti)
#2 da (1 voti)

2

La molto popolare IntelliJ IDEA ha attualmente salvato molte dipendenze come file jar reali nel loro repositorygit ad es. JUnit , che non capisco.

Costruisci strumenti come Maven che forniscono eccellenti capacità di gestione delle dipendenze. Ovviamente Maven detta molto come deve avvenire la build ( fonte ), ma questo è un argomento contro Maven e non contro la gestione delle dipendenze automatizzata generale.

Il repository Github di IntelliJ è molto confuso, ma penso che utilizzino Gant - che non include la gestione delle dipendenze, ma si integra molto bene con Ivy . Quindi posso capire perché potrebbero voler usare Gant - ma perché non usano Ivy?

La mia domanda reale è quindi: quale potrebbe essere una ragione per cui gli sviluppatori IDEA IntelliJ (o un'altra squadra in un'altra situazione) non hanno usato un sistema di gestione delle dipendenze e hanno invece salvato le loro dipendenze come normali file jar all'interno del loro repository? p>

java dependency-management build-system

posta toogley 29.06.2016 - 20:52

fonte

2 risposte

1

Disponibilità.

C'è già un commento che dice qualcosa di simile , ma ho anche risposto a una domanda simile su NuGet (gestore dei pacchetti di .NET) alcuni mesi fa:
Dovremmo includere la cartella Nuget PACKAGE nel controllo della versione?

Non sono un ragazzo Java e non conosco Maven, ma a me sembra che sia simile a NuGet: un repository centrale di pacchetti da cui le dipendenze vengono estratte durante la compilazione quando non esistono sul computer locale .

Il problema non è solo che Maven potrebbe chiudersi completamente in 10 anni.
Anche se "solo" hanno subito un'interruzione di breve durata, ogni progetto che dipende dal repository non verrà creato durante quel periodo.

Ecco perché stiamo salvando le nostre dipendenze all'interno dei repository al lavoro.
Inoltre, con i repository interni (come quelli che abbiamo al lavoro), c'è anche il problema che la nostra connessione internet potrebbe morire (l'abbiamo già avuta, e ha coinvolto un escavatore).
Sto scrivendo software per uso interno e, anche senza una connessione Internet, siamo stati in grado di creare e distribuire.

L'ultimo paragrafo probabilmente non è così preoccupante per IntelliJ, anche se ... perché lo stesso repository si trova su GitHub.

risposta data 30.06.2016 - 17:34

fonte

Leggi altre domande sui tag java dependency-management build-system

Perché modificare direttamente i file binari? Come gestire quando è necessario smaltire solo determinate classi derivate?

score 5 · Accepted Answer

La storia.

Molte delle migliori pratiche di informatica sono un obiettivo mobile. Così ogni volta che lavori con il vecchio codice stai lavorando con vecchie idee. Se riesci a scrivere codice che dura più di un decennio potresti scoprire di aver capito perché non hai usato foo testing, bar management o baz onniscience.

Se pensi di sapere meglio sentiti libero di caricarlo, correggilo e invia una richiesta di pull. Forse non l'hanno fatto perché ti stavano aspettando.

È bello essere all'altezza di tutte le ultime tecniche. Come sviluppatore professionista ci si aspetta che sia in grado di navigare anche con le vecchie tecniche. Non criticare ciò che non sei preparato a refactoring.