Perché gli artefatti scala maven hanno un artefatto per ogni versione scala invece di un classificatore per scala versione?

Question

Poiché si dispone solo della compatibilità di origine tra Scala -versioni, è purtroppo necessario compilare librerie come scalatest o scalamock per ogni versione di scala che supportano. Ciò che mi lascia perplesso è che le librerie sono dotate di un sacco di risorse (scalatest_2.9.0, scalatest_2.9.1, scalatest_2.10 e così via) - una per ogni versione di scala, in modo tale che il repository di Maven sia disseminato di molti artefatti creati da la stessa fonte. Il mio istinto mi dice piuttosto di usare un artefatto con un classificatore per ogni versione di scala. (In effetti, lo maven pom reference menziona che questo a volte è stato fatto con i classificatori jdk14 e jdk15 per gli artefatti, che mi sembrano simili.) Quindi, perché il popolo di Scala ha optato per il sovradimensionamento di molti artefatti :-)?

Answer 1

Posso sbagliarmi, ma se lo scopo di un classificatore è quello di "distinguere i reperti che sono stati costruiti dalla stessa POM, ma si differenziano per il loro contenuto", poi vedo una buona ragione non per utilizzarli per il versioning scala: le versioni scala non sono solo incompatibili in formato binario, ma possono anche essere la sorgente non compatibile. Ad esempio, quando si aggiorna scala da 2.7 a 2.8, ho dovuto apportare alcune modifiche significative al codice base. Se volessi mantenere contemporaneamente una versione di scala 2.7 e 2.8, avrei dovuto creare un ramo parallelo, ed entrambi i rami non avrebbero sicuramente lo stesso codice sorgente.

Quando ho letto "dallo stesso POM", capisco che ciò significa anche dallo stesso codice sorgente, che chiaramente non sarebbe il caso di quei due rami di codice.

Un altro motivo più importante è che un classificatore è essenzialmente una singola stringa, che è già utilizzata per molte cose. Classificatori più o meno standard includono "fonti", "javadoc" o "risorse". I significati di questi classificatori sono gli stessi in scala progetto, e sono totalmente ortogonali alla versione scala, come cercherò di mostrare.

La documentazione di Maven suggerisce l'uso di classificatori come "jdk15" o "jdk14" per indicare quale versione di jvm è stata compilata con l'artefatto binario. Dato che il codice java è compatibile con le versioni precedenti, in linea di principio gli artefatti con entrambi i classificatori ("jdk15" o "jdk14") sono compilati dallo stesso codice sorgente. Questo è il motivo per cui non è necessario duplicare i classificatori per gli artefatti "fonti", ovvero in altre parole che lo non ha necessario avere un classificatore denominato "sources-jdk14" e "sources-jdk15". Ma non è possibile applicare la stessa logica alla versione scala: dato che potresti aver bisogno di un codice sorgente diverso se compili con scala 2.7 o scala 2.8, avresti davvero bisogno di due differenti artefatti con classificatori come "sources-scala2.7" o "fonte-scala2.8". Quindi abbiamo già delle classificazioni composite. Come per gli artefatti binari, non dovresti solo distinguere tra la versione jvm di destinazione (ricorda, puoi compilare il tuo codice scala per scegliere come target diverse versioni di jvm) ma anche la versione di scala con cui è stata compilata. Quindi si finirebbe con qualcosa come "jdk14-scala2.7" o "jdk14-scala2.8" o "jdk15-scala2.7" o "jdk15-scala2.8". Ancora un altro insieme di classificatori compositi. Quindi il messaggio da portare a casa è che la versione scala è in realtà un modo separato di classificare gli artefatti, che è totalmente ortognale a tutti i classificatori esistenti. Sì, potremmo davvero usare le classificazioni composite come sopra (come "sources-scala2.7") ma non useremmo classificatori standard, il che è abbastanza confuso di per sé, ma richiederebbe anche di modificare tutti gli strumenti attorno ai classificatori : cosa succede se uso uno strumento di costruzione che non ha conoscenza di scala (solo java) ma sa come pubblicare automaticamente un artefatto "sorgente"? Dovrò modificare questo strumento di costruzione in modo che sappia pubblicare invece un artefatto "sources-scala2.7"? D'altra parte, se codifico la versione scala nel nome di artefatto (base) e la do allo strumento di costruzione, tutto funziona come al solito e ottengo un artefatto con il classificatore "origine".

Tutto sommato, e contrariamente all'intuizione immediata, codificare la versione scala nel nome consente l'integrazione migliore nell'ecosistema di sviluppo java esistente.

Answer 2

Scala fornisce compatibilità inter-versione del suo output bytecode (file .class) solo attraverso patch release (terzo componente delle specifiche di versione Major.Minor.Patch).

Maven non ha spazio per codificarlo correttamente come una proprietà di prima classe dell'oggetto, quindi deve essere codificato per convenzione nel nome.

Purtroppo ...