sobre nosaltres
A 1C desenvolupem no només una plataforma en и , però també aplicacions Java, en particular el nou entorn de desenvolupament basat en Eclipse i un servidor de missatgeria profundament integrat amb la plataforma - .
Entrada
Sovint fem servir maven com a sistema de compilació d'aplicacions Java, i en aquest breu article ens agradaria parlar d'un dels problemes que hem hagut d'afrontar en el procés d'organització del desenvolupament i de l'enfocament que ens ha permès superar-ho. problema.
Requisits previs i flux de treball
A causa de les especificitats del desenvolupament dels nostres projectes maven, fem servir una gran quantitat de mòduls, dependències i projectes secundaris. El nombre de fitxers pom en un arbre pot ser de desenes o fins i tot centenars.
Sembla: no és gran cosa, el van crear una vegada i se'n van oblidar. Si necessiteu canviar o afegir alguna cosa a tots els fitxers alhora, hi ha moltes eines convenients als editors i IDE. Quin és el canvi habitual més comú a pom.xml? Creiem que els canvis en les versions i dependències del projecte. Potser algú voldrà discutir amb això, però aquesta és exactament la situació amb nosaltres. La raó rau en el fet que, juntament amb el nucli, estem desenvolupant simultàniament moltes de les nostres pròpies biblioteques, i per a la reproductibilitat constant dels resultats de la compilació i de les proves, l'ús de les instantànies no ens sembla un enfocament convenient. Per aquest motiu, és necessari augmentar el número de versió en els projectes amb cada compilació.
A més, de tant en tant, un desenvolupador necessita construir la seva pròpia branca d'una biblioteca i comprovar-ne la funcionalitat amb totes les dependències, per la qual cosa ha de canviar manualment la versió de totes.
Solució inicial
Amb canvis de versió tan freqüents i múltiples, vull simplificar i automatitzar el procés dins de CI. Aquí és on un connector còmode i conegut ve al rescat. versions-maven-plugin - connectar-lo i llançar-lo
mvn -N versions:set -DnewVersion=2.0.1
i Maven ho farà tot com cal: passarà per la jerarquia de dalt a baix, substituint totes les versions: bellesa! Ara només queda fer una sol·licitud d'extracció, els companys revisaran els canvis i us podreu unir ràpidament al tronc. Ràpidament? No importa com sigui. Un parell de centenars pom.xml per revisar-lo, i això sense comptar el codi. A més, ningú no està segur de conflictes de combinació amb un nombre tan gran de fitxers modificats. Cal assenyalar aquí que en el procés CI, els canvis de versió es produeixen automàticament juntament amb els canvis en la funcionalitat, i no d'alguna manera per separat.
Noves característiques
Durant una estona ens vam calmar i, havent-nos resignat, vam viure així fins que els nois de A partir de la versió 3.5.0-beta-1, Maven no va incloure suport per als anomenats "marcadors de posició". L'essència d'aquests substituts és això pom.xml en comptes d'una indicació específica de la versió del projecte, s'utilitzen variables ${revisió}, ${sha1} и ${changelist}. Els valors d'aquestes propietats es defineixen a l'elementpropietats>, o bé es poden definir mitjançant una propietat del sistema
mvn -Drevision=2.0.0 paquet net
Els valors de la propietat del sistema tenen prioritat sobre els valors definits apropietats>.
Els pares
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-parent
Primer CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
- INSTANTÀNIA
Descendent
4.0.0
org.apache.maven.ci
ci-parent
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-infant
...
Si voleu crear la versió 2.0.0-SNAPSHOT, només cal que feu servir
mvn -Drevision=2.0.0 paquet net
Si voleu fer un llançament, només heu de restablir SNAPSHOT
mvn -Dchangelist= paquet net
*Els exemples anteriors estan extrets de al lloc web del projecte Maven Apache
La crua realitat
Tot és bo i saludable, és hora de sentir una sensació de satisfacció, però no. Resulta que aquest mètode no funcionarà per instal·lar i desplegar, ja que no es substituirà a les descripcions d'artefactes publicades al repositori. ${revisió} sobre el seu significat i l'expert ja no entendrà de què es tracta.
org.apache
apache
${revisió}
Una llum al final d'un túnel
Hem de buscar una solució al problema. Podria haver salvat la situació . Aquest connector resol totes les variables del pom, però al mateix temps elimina molta altra informació que només es necessita durant el muntatge i que no és necessària quan s'importen artefactes publicats a altres projectes. El connector també "redresa" totes les dependències entre pares i fills i, com a resultat, obteniu un pom pla que inclou tot el que necessiteu. L'inconvenient va ser que ens retalla massa “extra”, que no ens agradava gens. Després d'estudiar la informació sobre el desenvolupament d'aquest complement, va resultar que no som els únics a l'univers, i l'agost de 2018 es va crear una petició d'extracció a Github al repositori de complements amb la voluntat de fer-ho possible. per determinar pel nostre compte com "esborrar" pom.xml. Els desenvolupadors van escoltar les veus dels que pateixen i ja al desembre, amb el llançament de la nova versió 1.1.0, va aparèixer un nou mode, resolveCiFriendliesOnly, al connector flatten-maven, que era més adequat que mai; pom.xml tal com és, excepte l'element i permet ${revisió}, ${sha1} и ${changelist}.
Afegir un complement al projecte
org.codehaus.mojo
aplanar-maven-plugin
1.1.0
veritat
resoldreCiFriendliesOnly
aplanar
recursos-procés
aplanar
aplanar.netar
net
net
Fet!
Final feliç
A partir d'ara, per canviar la versió de tot el projecte i fer-ne saber a totes les dependències, només hem d'editar l'elementrevisió> només a l'arrel pom.xml. No arriben cent o dos d'aquests fitxers amb el mateix canvi a la revisió, sinó un. Bé, no cal fer servir versions-maven-plugin.
Font: www.habr.com