2015-07-17 8 views
9

Luminus in questo momento è la creazione di un profiles.clj con questo contenuto:Cosa significa: fornito media in profiles.clj?

{:provided {:env {;;when set the application start the nREPL server on load 
        :nrepl-port "7001" 
        :database-url "jdbc:mysql://localhost:3306/mysqlkorma_dev?user=db_user_name_here&password=db_user_password_here"}}} 

Che cosa significa: evitare di fornire qui? Nella documentazione di environ sembra indicare due voci, una per dev e una per il test https://github.com/weavejester/environ.

risposta

7

TL; DR: Il profilo disponibile viene utilizzato in profiles.clj come alternativa al profilo dev, perché se dev sia utilizzata sarebbe sovrascrivere l'intero dev profilo specificato project.clj.


L'uso più comune di :provided è quello di specificare dipendenze che devono essere disponibili durante la creazione vaso, ma sarà fornito dall'ambiente runtime. Ma penso che qui viene utilizzato come un modo per evitare che il :env configurato in profiles.clj (che è destinato a non essere impegnati nel codice repository di origine) per sovrascrivere il :env configurato in project.clj.

Luminus avrebbe usato il profilo, invece di :provided:dev in profiles.clj, se non fosse per il fatto che hanno già messo roba in un :env voce nel profilo :dev in project.clj che avrebbe essere sovrascritto da ciò che è in profiles.clj.

Vedi this example repo. Se si esegue subito, senza alcuna modifica (con :provided in profiles.clj) l'uscita sarà:

› lein run 
Hello, world 
Db config: some:db://localhost 

Se si cambia :provided-:dev in profiles.clj, i cambiamenti di uscita verso:

› lein run 
Hello, nil 
Db config: some:db://localhost 

Essi non vengono fuse, ma il :env in profiles.clj sovrascritto la :env in profilo.CLJ


EDIT: Ho appena scoperto che non solo la voce :env sarebbe sovrascritto se :dev è stato utilizzato in profiles.clj. L'intero profilo :dev verrebbe sovrascritto. Questo è spiegato nel profiles documentation:

Ricordate che se un profilo con lo stesso nome è specificato in più località, solo il profilo con il più alto "priorità" viene raccolto - senza fusione è fatto. La "priorità" è, dal più alto al più basso, profiles.clj, project.clj, profili a livello di utente e infine i profili a livello di sistema.

Quindi, utilizzando :provided in profiles.clj è un po 'hack attorno alla strategia di fusione di profili Leiningen.

Ha almeno un rovescio della medaglia: se avete bisogno di definire un profilo :provided in project.clj per specificare le dipendenze che saranno disponibili in ambiente di runtime che sarebbe stato sovrascritto da quello definito nel profiles.clj .

+0

Grazie per la risposta dettagliata!In Luminus abbiamo finito per usare un hack diverso, così da poter modificare hashmaps sia per dev e test in entrambi, project.clj e profiles.clj. – Pablo

+0

Fantastico! Sì, finisci per fare diversi hack per essere in grado di ottenere la promessa di lein-environ di envs configurabile in profiles.clj. Alla fine non ho usato lein-environ (ma continuo a usare environ). Il README di environ suggerisce di usare: dev e: test in profiles.clj senza spiegare che sovrascriverà gli stessi profili in project.clj. Qualcuno dovrebbe modificare questo README spiegando questo piccolo dettaglio :) – nberger

+0

A proposito, c'è già un problema a riguardo in ambiente con un po 'di informazioni utili: https://github.com/weavejester/environ/issues/15. La soluzione che mi piace di più è ridefinire il profilo dev come ': dev [: project/dev: profiles/dev]' – nberger

3

Il profilo :provided viene utilizzato per specificare le dipendenze che dovrebbero essere disponibili durante la creazione vaso, ma non propagato a altro codice che dipende dal vostro progetto. Si tratta di dipendenze che il progetto presuppone saranno fornite da qualsiasi ambiente in cui viene utilizzato il jar, ma sono necessarie durante lo sviluppo del progetto. Questo è spesso usato per framework come Hadoop che forniscono le proprie copie di alcune librerie.

- Reference

+0

': provided' non viene utilizzato qui per le dipendenze, ma per evitare che il': env' configurato in _profiles.clj_ per sovrascrivere ': env' configurato in _project.clj_ e farsele unire invece – nberger

+0

Contiene fondamentalmente una mappa delle proprietà del progetto specifiche del profilo. È un caso d'uso comune specificare un valore in ': dipendenze' per, bene, aggiungere dipendenze specifiche di' jar'. Ma anche l'inclusione di altre chiavi è possibile. –

+0

Sicuro. Ma la sottigliezza qui è che il luminus avrebbe usato il profilo ': dev' in _profiles.clj_ ma sta usando': provided 'invece. Se crei un nuovo progetto luminus con mysql, ad esempio, otterrai '{: dev: env {: dev true: nrepl-port 7001}}' in _project.clj_ e '{: provided {: env {: database-url "jdbc: mysql: // localhost: 3306/trylum_dev? user = db_user_name_here & password = db_user_password_here"}}} 'in _profiles.clj_. La cosa strana qui è perché non sta usando ': dev' in _profiles.clj_ e penso che la mia risposta sia rivolta a questo. – nberger

0

Come @nberger ha affermato che provided viene utilizzato per specificare le dipendenze che dovrebbero essere disponibili nel percorso di classe, ma verranno fornite dal runtime.

Un caso particolare sono le librerie che se incluse nel progetto otterrebbero la loro firma incasinata durante la creazione di Uberjar.

Tale è la situazione di BouncyCastle.

Così il vostro project.clj possono apparire come:

:profiles {:dev {:dependencies [[org.bouncycastle/bcprov-jdk15on "1.50"]]} 
      :provided {:dependencies [[org.bouncycastle/bcprov-jdk15on "1.50"]]}} 

In questa situazione si dice che per lo sviluppo è possibile utilizzare la libreria dal repository Maven, ma il tempo di esecuzione va fornito dall'ambiente.

Così il file jar originale così com'è, deve essere presente nel percorso di classe:

java -cp bcprov-jdk15on-151.jar:your-standalone.jar clojure.main