2014-12-24 21 views
5

Ho una dipendenza proprietaria che utilizzo nel mio progetto e che non posso rifiutare. E 'stato costruito in un grosso barattolo di grasso con tutti i pacchetti dipendenti raccolti all'interno. Con tutti intendo anche quelli comuni come slf4j-api, apache-commons, javax packages, ecc.Come gestire la dipendenza da jar grassi

Usarlo insieme alla mia lista di dependecie dichiarate è rischioso perché c'è sempre una corsa in classloader su quale classe verrà caricata prima - classe mia o obsoleta all'interno del barattolo di grasso.

Mi chiedevo un modo per aggirare questo problema? Come trattare questi vasi grassi? Sto usando Maven per la gestione delle dipendenze.

+1

Blame quelle persone provocano un barattolo di grasso con tali contenuti fa non ha davvero senso (comuni ecc.). Ciò causerà sempre problemi di caricamento di classe. Quindi devi mantenere un vaso costruito da te ... altrimenti sei perso ... – khmarbaise

+1

@khmarbaise Oh, li biasimo tutti i giorni, ma non mi aiuta. Non faranno nulla per la loro distribuzione dei pacchetti. Certamente non nel prossimo futuro. – SimY4

risposta

1

Penso che ci sia un altro modo. Posso avvolgere questo barattolo libreria nel proprio classloader personalizzato

URLClassLoader c1 = new URLClassLoader(new Url[] { new URL("file:lib/fatJarDep.jar"}); 

e creare una fabbrica che istanziare le classi di questa libreria utilizzando questo isolato classloader

Class.forName("className", true, c1); 
1

Se il jar ha tutta la classe di dipendenza estratta all'interno non è possibile escluderli dal caricamento in classe, quindi la stessa dipendenza nel progetto potrebbe essere in conflitto.

Dovresti modificare il barattolo di grasso e rimuovere manualmente le classi per fare una versione leggera, quindi installarlo nel repository e fare riferimento ad esso nel tuo pom.

+1

Non voglio assumermi la responsabilità di supportare un progetto di terze parti. Creare una build personalizzata di questa libreria mi costerà del tempo per eseguire il backport delle patch e delle nuove versioni dalla fonte principale. – SimY4

+1

È possibile scrivere una semplice procedura che rende il jar sottile eseguito all'aggiornamento della versione. Suppongo che tu aggiorni manualmente il pom sulla nuova versione di jar, la procedura può prendere in input la nuova versione, rendere il jar sottile e aggiornare il tuo pom – fantarama

+0

Puoi guidarmi su una procedura così semplice? Mostra alcuni esempi o articoli sulla sua creazione? – SimY4

2

In Maven, l'ordine in cui si definiscono le dipendenze nel POM è significativo. Se li elenchi nell'ordine corretto, dovrebbero essere aggiunti al contenitore in quell'ordine, e qualsiasi classe sia più alta nel file, quella sarà caricata per prima.

Se si comporterà il percorso di classe di runtime su più vasi, , di nuovo, si tratta di inserire i vasi nell'ordine corretto.

+0

Questo non risolverà un problema: a seconda di quale classe verrà caricata per prima, otterrete ethier il codice errato o il codice di questa libreria. A causa di incompatibilità di classe prossimale. (Le versioni delle librerie all'interno del vaso di grasso sono sconosciute) – SimY4

1

Se si sa che alcune funzionalità del vaso grasso funzioneranno quando si esclude qualche fo loro dipendenze o se si vuole includere da soli, si può provare questo:

  1. Fai un progetto di Maven che dipende dalla solo vaso grasso
  2. Utilizzare maven-shade-plugin, in particolare la funzione di riposizionamento per escludere i pacchetti che non si desidera, o solo per riposizionare tutte le classi del jar in un altro pacchetto, quindi spostarle di mezzo.
  3. Utilizzare l'artefatto del progetto anziché il vaso propietario grasso nell'altro progetto.
+0

Grazie per il suggerimento. Non sapevo del plugin di ombre di Maven, ci proverò. – SimY4

Problemi correlati