за нас
На 1C развиваме не само платформа на и , но и Java апликации - особено новата развојна околина базиран на Eclipse и сервер за гласници длабоко интегриран со платформата - .
Влегување
Најчесто го користиме maven како градежен систем за Java апликации, а во оваа кратка статија би сакале да зборуваме за еден од проблемите со кои моравме да се соочиме во процесот на организирање на развојот и за пристапот што ни овозможи да го надминеме ова. проблем.
Предуслови и работен тек
Поради спецификите на развојот во нашите мавен проекти, користиме доста модули, зависности и проекти за деца. Бројот на пом-датотеки во едно дрво може да биде десетици, па дури и стотици.
Се чини: не е голема работа, тие го создадоа еднаш и заборавија на тоа. Ако треба да промените или додадете нешто во сите датотеки одеднаш, има многу практични алатки во уредниците и IDE-овите. Која е најчестата редовна промена на pom.xml? Ние веруваме дека промените во верзиите и зависностите на проектот. Можеби некој ќе сака да се расправа со ова, но токму таква е ситуацијата кај нас. Причината лежи во фактот што, заедно со кернелот, истовремено развиваме многу наши библиотеки, а поради постојаната репродуктивност на резултатите од изградбата и тестирањето, употребата на снимки не ни се чини пригоден пристап. Поради оваа причина, неопходно е да се зголеми бројот на верзијата во проектите со секоја изработка.
Исто така, од време на време, развивачот треба да изгради своја сопствена филијала на библиотека и да ја провери нејзината функционалност во однос на сите зависности, за што треба рачно да ја промени верзијата на сите нив.
Почетно решение
Со такви чести и повеќекратни промени на верзијата, сакам да го поедноставам и автоматизирам процесот во рамките на CI. Ова е местото каде што пригоден, добро познат приклучок доаѓа до помош. верзии-maven-приклучок - поврзете го и стартувајте го
mvn -N верзии:сет -DnewVersion=2.0.1
и Maven ќе направи сè како што треба: ќе се провлекува низ хиерархијата од врвот до дното, заменувајќи ги сите верзии - убавина! Сега останува само да подигнете барање за повлекување, колегите ќе ги разгледаат промените и можете брзо да се приклучите на багажникот. Брзо? Без разлика како е. Неколку стотини pom.xml за преглед, и ова не го брои кодот. Покрај тоа, никој не е безбеден од конфликти за спојување со толку голем број променети датотеки. Овде треба да се забележи дека во процесот CI, промените на верзијата се случуваат автоматски заедно со промените во функционалноста, а не некако одделно.
Нови карактеристики
Едно време се смиривме и, дадовме отказ, така живеевме до момците од Почнувајќи од верзијата 3.5.0-бета-1, Maven не вклучи поддршка за таканаречените „местенка“. Суштината на овие замени е тоа pom.xml наместо специфична индикација за верзијата на проектот, се користат променливи ${ревизија}, ${sha1} и ${changelist}. Самите вредности на овие својства се поставени или во елементотсвојства>, или тие може да се дефинираат преку системско својство
mvn -Drevision=2.0.0 чист пакет
Вредностите на својствата на системот имаат приоритет над вредностите дефинирани восвојства>.
Родител
4.0.0
org.apache
апачи
18
org.apache.maven.ci
ци-родител
Прво CI Пријателски
${revision}${sha1}${changelist}
...
1.3.1
-СНИМКА
Потомок
4.0.0
org.apache.maven.ci
ци-родител
${revision}${sha1}${changelist}
org.apache.maven.ci
ци-дете
...
Ако сакате да ја изградите верзијата 2.0.0-SNAPSHOT, тогаш само користете
mvn -Drevision=2.0.0 чист пакет
Ако сакате да направите издание, тогаш само ресетирајте го SNAPSHOT
mvn -Dchangelist= чист пакет
*Примерите погоре се преземени од на веб-страницата на Maven Apache Project
Сурова реалност
Сè е добро и здраво, време е да почувствувате чувство на задоволство, но не. Излегува дека овој метод нема да работи за инсталирање и распоредување, бидејќи нема да биде заменет во описите на артефакти објавени во складиштето ${ревизија} за неговото значење и мавен веќе нема да разбере за што се работи.
org.apache
апачи
${ревизија}
Светло на крајот од тунелот
Треба да бараме решение за проблемот. Можеше да ја спаси ситуацијата . Овој приклучок ги решава сите променливи во пом, но во исто време отсекува многу други информации кои се потребни само за време на склопувањето и не се потребни при увоз на објавени артефакти во други проекти. Приклучокот, исто така, ги „исправа“ сите зависности од родител-дете, и како резултат на тоа, добивате рамна помка која вклучува сè што ви треба. Непријатноста беше што отсекува премногу „екстра“, што воопшто не ни одговараше. Откако ги проучувавме информациите за развојот на овој приклучок, се покажа дека не сме единствените во универзумот, а уште во август 2018 година, беше креирано барање за повлекување на Github во складиштето на приклучоци со желба да се овозможи тоа сами да одредиме како да го „расипете“ pom.xml. Програмерите ги слушаа гласовите на оние кои страдаат, а веќе во декември, со објавувањето на новата верзија 1.1.0, во додатокот flatten-maven се појави нов режим, solveCiFriendliesOnly, кој беше посоодветен од кога било - заминува pom.xml како што е, освен елементот и дозволува ${ревизија}, ${sha1} и ${changelist}.
Додавање приклучок во проектот
org.codehaus.mojo
израмните-мавен-приклучок
1.1.0
вистина
решавање на CiFriendliesOnly
сплескаат
процес-ресурси
сплескаат
израмни.чисти
чисти
чисти
Готово!
Среќен крај
Отсега натаму, за да ја смениме верзијата на целиот проект и да ги известиме сите зависности, само треба да го уредиме елементотревизија> само во коренот pom.xml. На преглед не пристигнуваат сто или две датотеки со иста промена, туку еден. Па, нема потреба да се користи верзии-maven-приклучок.
Извор: www.habr.com