Perché la convenzione cross-building aggiunge la versione scala all'artefatto?

Question

Il meccanismo sottostante utilizzato per indicare a quale versione di Scala è stata compilata una libreria è quello di aggiungere _ < scala-versione > al nome della libreria. Questo approccio abbastanza semplice consente l'interoperabilità con gli utenti di Maven, Ant e altri strumenti di costruzione. - sbt Documentation: Cross-Build Publishing Conventions

Mentre questo è un approccio semplice, l'interoperabilità con Maven e altri strumenti di generazione lascia a desiderare. Poiché lo artifactId è diverso (ad esempio scalatest_2.9.0 e scalatest_2.10.0), Maven li tratta come artefatti diversi. Il meccanismo di risoluzione delle dipendenze di Maven è quindi compromesso e più versioni dello stesso artefatto (costruite su versioni di scala differenti) possono finire sul classpath.

Perché non inserire la versione scala nel classificatore? Questo sembra essere una delle principali cause di utilizzo di classificatore:

Il classificatore permette [Maven] distinguere manufatti che sono stati costruiti dal medesimo POM ma differiscono tra loro contenuto. Come motivazione per questo elemento, prendi in considerazione ad esempio un progetto che offre un artefatto che ha come target JRE 1.5, ma allo stesso tempo anche un artefatto che supporta ancora JRE 1.4. Il primo artefatto potrebbe essere equipaggiato con il classificatore jdk15 e il secondo con jdk14 in modo che i client possano scegliere quale utilizzare. - Maven Documentation: POM Reference

Answer 1

Aggiunta la versione per il nome è una decisione storica che è stato fatto molto tempo fa in modo che sarà probabilmente non cambierà in quanto molte librerie sono pubblicati con la convenzione già.

Detto questo, come ha osservato Seth, c'è stata una discussione per rivedere questo argomento alcuni anni fa quando sbt 0.12 ha accorciato il suffisso "_2.10.0" a "_2.10" per sfruttare la compatibilità binaria della libreria di Scala tra il versioni minori. Ecco Mark da [0.12] plan:

Con delle versioni croce, voglio dire la prassi di inserire una parte della versione Scala nel ID del modulo di distinguere un artefatto generato compilando lo stesso codice sorgente contro diverse versioni Scala. Non intendo la capacità di costruire contro più versioni di Scala usando +task, che rimarrà; Mi riferisco solo alla convenzione della versione trasversale.

[snip]

E 'sempre stato un hack per codificare questo nel formato pom.xml inflessibile e penso che può essere meglio per allontanarsi da questa per progetti realizzati contro Scala 2.10 e versioni successive. Tuttavia, forse questo è meglio di qualsiasi soluzione ad hoc che potrebbe prendere il suo posto. Non vedo gli utenti di altri strumenti di sviluppo fare questo, quindi mi aspetto che nulla lo sostituirà.

Da qualche parte lungo il filo Josh suggested:

(1) classificatori Scala. Queste possono essere stringhe personalizzate e possono essere specificate con dipendenze. Almeno, IIRC dovrebbe funzionare.

Ecco Marco response:

Che cosa significano da "può essere specificato con le dipendenze"? C'è solo un pom per tutti i classificatori, giusto? Come puoi dichiarare dipendenze diverse per ogni classificatore?

Ecco alcune osservazioni più interessanti su classificatori da Geoff Reedy

troppo ho pensato che classificatori sarebbe il modo migliore per affrontare questo problema soprattutto alla luce del suggerimento nella documentazione Maven che classificatori java-1.4 e java-1.5 essere utilizzati per la distinzione tra i vasi appropriati per la rispettiva piattaforma. Il difetto fatale sembra essere la gestione della dipendenza transitiva . Cioè, non c'è modo di scegliere il set di dipendenze transitive basato sul classificatore usato per richiedere il modulo . Avremmo bisogno di essere in grado di dire che quando si utilizza questo modulo con l'scala-2.10 classificatore che porta le proprie dipendenze utilizzando il scala-2.10 classificatore e quando viene utilizzato con il 2,9 classificatore porta in proprie dipendenze con il scala-2.9 classificatore.

penso che con le versioni di JVM è possibile fare questo lavoro perché JVM delle versioni ha un supporto speciale per l'attivazione del profilo che può in grado di controllare le dipendenze.