2014-06-17 5 views
6

Mentre cercavo informazioni sullo stackoverflow, ho visto una domanda simile alla mia, ma senza una risposta reale here.Perché ho bisogno di aggiungere artefatto JSR305 per usare Guava 14+?

ho bisogno di migrare il mio progetto Maven da guava 11.0.2 a guava 14 o superiore (ho bisogno RangeSet). Ho aggiornato il mio esperto di pom con la dipendenza:

<dependency> 
    <groupId>com.google.guava</groupId> 
    <artifactId>guava</artifactId> 
    <version>14.0</version> 
</dependency> 

ho quindi eseguire la build Maven, e ottenuto questo errore:

[ERROR] xxx.java: cannot find symbol 
[ERROR] symbol : class Nonnull 
[ERROR] location: package javax.annotation 

ho preso uno sguardo più da vicino, e questo le annotazioni è dotato di JSR305 , da cui dipende guava 11.0.2, come mvn repository lo segnala.

Quello che trovo strano è che guava 14 dipende anche JSR305 come mvn repository rapporti.

Se aggiungo la dipendenza JSR al mio pom, poi la compilazione just funziona bene:

<dependency> 
    <groupId>com.google.code.findbugs</groupId> 
    <artifactId>jsr305</artifactId> 
    <version>1.3.9</version> 
    <scope>provided</scope> 
</dependency> 

Ma perché avrei dovuto aggiungere questa dipendenza al mio pom se guava dipende già su di esso? Questo sembra più una soluzione che una soluzione, e preferirei capire e rendere le cose pulite.

Grazie per aver partecipato.

+0

Mi sembra di ricordare che questo è necessario quando si utilizza il compilatore Scala - è che la configurazione? –

+0

In particolare, http://stackoverflow.com/questions/10007994/why-do-i-need-jsr305-to-use-guava-in-scala –

+0

Questa non è la mia configurazione, dal momento che costruisco un progetto java. Ma il problema è molto vicino al mio ... –

risposta

11

La ragione per cui è necessario aggiungerlo come una dipendenza è perché Guava 14 definisce la dipendenza nella loro pom come segue:

<dependency> 
    <groupId>com.google.code.findbugs</groupId> 
    <artifactId>jsr305</artifactId> 
    <version>1.3.9</version> 
    <scope>provided</scope> 
</dependency> 

La parte importante per il vostro problema è la linea <scope>provided</scope>.

Dal Maven website affermano quanto segue per quanto riguarda provided dipendenze:

provided: This is much like compile , but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.

Quindi, fondamentalmente perché Guava hanno fissato questo come dipendenza provided si aspettano chi sta consumando Guava per fornire questa dipendenza, che è esattamente ciò che hai dovuto fare.

In Guava 11.0.2 era una normale dipendenza compile, quindi non era necessario fornirla nel proprio progetto.

Il cambiamento è stato fatto in Guava 13. Dal release notes:

Made findbugs a provided dependency to avert dep conflicts when using findbugs 2.0. The side-effect of this change is that projects which relied upon Guava to grant access to the JSR-305 annotations "for free" will break unless they provide their own direct dependency on that jar (or an equivalent). Projects should always have been directly depending on JSR-305 (per maven best-practice), but this change makes that should into a must.

+2

Sì e no. Puoi provarlo tu stesso - crea un progetto pulito solo con Guava e senza JSR-305. Tutto funzionerà bene in Java (almeno in Java 7, non sono sicuro di Java 8). Questo perché non hai bisogno delle classi per le annotazioni in fase di esecuzione. Vedi ad esempio http: // StackOverflow.com/domande/3567413/why-doesnt-a-manca-annotation-causa-di-ClassNotFoundException-at-runtime. Con Scala, però, questa è una canzone diversa e hai ragione. –

+0

Nel mio caso, ne ho bisogno in fase di runtime, quindi la risposta DB5 è adatta a me. –

+1

Tutto in Guava dovrebbe funzionare bene senza il vaso JSR-305 in fase di esecuzione. Se si utilizzavano annotazioni JSR-305 nel proprio codice, allora sì, è necessario dipendere direttamente da questo momento per compilare. (Non dovresti comunque averne bisogno in fase di runtime a meno che tu non stia riflettendo sulle annotazioni per qualche motivo.) – ColinD

Problemi correlati