Ivy, qual è la configurazione principale e perché non sta tirando jvyaml?

Ho il seguente file di edera:

         

e ho un compito di recupero delle formiche che assomiglia a questo:

    

La cosa strana è che tutte le dipendenze di solr vengono scaricate in lib / runtime come mi aspetterei, ma il modulo jvyaml no! Si “risolve”, ma non verrà scaricato nella directory lib / runtime a meno che non venga modificata la dichiarazione di dipendenza in:

 master" /> 

Cos’è questa configurazione principale e perché è necessario estrarre il jar jvyaml, ma non solr?

Grazie

    Suggerirei di ristrutturare le configurazioni come segue:

                 

    Importanti modifiche introdotte:

    1. Usa la configurazione di “compilazione” più standard
    2. Ereditarietà della configurazione usando l’attributo “estende”. Le dipendenze di compilazione possono quindi essere incluse automaticamente sia nel runtime che nelle configurazioni di test.
    3. Utilizzare i mapping di configurazione , ad esempio: conf = “runtime-> default”. Ciò rende evidente quale configurazione locale è associata a quale configurazione remota.

    Mappature di configurazione spiegate

    Le configurazioni sono una potente funzione di edera. Quando l’edera scarica i moduli Maven, esegue una traduzione interna e assegna una serie standard di configurazioni, elencate in questa risposta:

    • Come sono mappati gli scope maven alle configurazioni di edera di edera

    Quando si dichiara una dipendenza, è una buona idea fare sempre uso di una mapping di configurazione, in modo tale che non ci siano dubbi su dove sono assegnati gli artefatti delle dipendenze.

    Per esempio:

      

    Qui stiamo dicendo che vogliamo le dipendenze predefinite del modulo remoto associate alla nostra configurazione di runtime locale.

    In pratica, ci sono solo due mappature di configurazione remote di cui avrai effettivamente bisogno:

    • default : l’artefatto del modulo remoto e tutte le sue dipendenze transitive di runtime
    • master : solo l’artefatto del modulo remoto (nessuna dipendenza transitiva)

    In conclusione, penso che il tuo problema sia stato causato dal fatto che l’ambito “runtime” del modulo Maven remoto non include l’artefatto del modulo Maven, invece stavi ottenendo le dipendenze transitive inesistenti del modulo jvyaml 🙁

    Qualche consiglio in più

    Suggerirei anche di generare un rapporto di gestione delle dipendenze dell’edera, come segue:

          

    Il rapporto aiuterà a spiegare come ogni dipendenza finisce su diverse configurazioni. È anche molto utile per determinare come vengono gestite le dipendenze transitive.

    E infine, ecco dove l’ereditarietà della configurazione si ripaga, creando classpath ANT gestiti da edera:

            

    Si noti che il solr-core originale non viene recuperato neanche. Dopo la risoluzione, vai alla cache e controlla i file ivy.xml per entrambi i moduli.

    Vedrai che pubblicano i loro artefatti solo in conf = master

       

    Il che significa che devi fare esplicita mapping della configurazione per indicare che la tua configurazione builtime dovrebbe evocare la configurazione ‘master’ delle tue dipendenze. (controllare la mapping della configurazione).

    TUTTAVIA, le dipendenze di solr-core hanno il mapping della configurazione come si può vedere nel file ivy.xml:

      

    Penso che sia il maestro (*) thingy.

    Quello che faccio di solito è nel mio file ivy.xml quando dichiaro dipendenze, faccio la mapping:

       

    Questo dice che il runtime sta evocando la configurazione master nella dipendenza designata.

    Potresti farlo

     conf="runtime,test->master" 

    anche