Rólunk
Az 1C-nél nem csak platformot fejlesztünk on и , hanem a Java alkalmazások is – különösen az új fejlesztői környezet az Eclipse-en és a platformmal mélyen integrált messenger szerveren alapul - .
Belépés
A mavent leggyakrabban Java alkalmazások build rendszereként használjuk, és ebben a rövid cikkben az egyik problémáról szeretnénk beszélni, amellyel a fejlesztés megszervezése során szembesülnünk kellett, illetve arról, hogy milyen megközelítéssel sikerült ezt legyőznünk. probléma.
Előfeltételek és munkafolyamat
Maven projektjeink fejlesztési sajátosságai miatt elég sok modult, függőséget és gyermekprojektet használunk. Az egy fán lévő pom-fájlok száma több tíz vagy akár száz is lehet.
Úgy tűnik: nem nagy ügy, egyszer létrehozták, és megfeledkeztek róla. Ha az összes fájlban egyszerre kell módosítania vagy hozzáadnia valamit, számos kényelmes eszköz található a szerkesztőkben és az IDE-kben. Mi a leggyakoribb rendszeres módosítás a pom.xml-ben? Úgy gondoljuk, hogy a projekt verziói és a függőségek megváltoznak. Lehet, hogy valaki vitatkozni akar majd ezzel, de nálunk pontosan ez a helyzet. Az ok abban rejlik, hogy a kernellel párhuzamosan számos saját könyvtárat fejlesztünk, és a készítési és tesztelési eredmények állandó reprodukálhatósága érdekében a pillanatképek használata nem tűnik kényelmes megközelítésnek. Emiatt minden buildnél meg kell emelni a verziószámot a projektekben.
Ezenkívül a fejlesztőnek időnként létre kell hoznia egy könyvtár saját ágát, és ellenőriznie kell annak működését az összes függőséggel szemben, amihez manuálisan kell módosítania az összes verzióját.
Kezdeti megoldás
Az ilyen gyakori és többszöri verzióváltásokkal szeretném egyszerűsíteni és automatizálni a folyamatot a CI-n belül. Itt egy kényelmes, jól ismert beépülő modul segít. versions-maven-plugin - csatlakoztassa és indítsa el
mvn -N versions:set -DnewVersion=2.0.1
és a Maven mindent megtesz, ahogy kell: végigfut a hierarchián felülről lefelé, minden verziót felváltva – szépség! Most már csak egy lehívási kérelmet kell feltenni, a kollégák áttekintik a változtatásokat, és gyorsan csatlakozhat a törzshöz. Gyorsan? Nem számít, milyen. Pár száz pom.xml felülvizsgálatra, és ez nem számít bele a kódba. Ezen túlmenően, senki sincs biztonságban az összevonási konfliktusoktól ilyen nagy számú módosított fájl esetén. Itt meg kell jegyezni, hogy a CI folyamatban a verzióváltások automatikusan, a funkcionalitás változásaival együtt történnek, nem pedig külön-külön.
Új funkciók
Egy darabig megnyugodtunk, és lemondva éltünk így, amíg a srácok nem A 3.5.0-beta-1 verziótól kezdve a Maven nem támogatta az úgynevezett „helyőrzőket”. Ezeknek a helyettesítőknek az a lényege pom.xml a projekt verziójának konkrét megjelölése helyett változókat használnak ${revision}, ${sha1} и ${changelist}. Ezeknek a tulajdonságoknak az értékei vagy az elemben vannak beállítvaingatlanait>, vagy egy rendszertulajdonságon keresztül definiálhatók
mvn -Drevision=2.0.0 tiszta csomag
A rendszertulajdonságok értékei elsőbbséget élveznek a ben meghatározott értékekkel szembeningatlanait>.
Szülő
4.0.0
org.apache
apache
18
org.apache.maven.ci
ci-szülő
Első CI-barát
${revision}${sha1}${changelist}
...
1.3.1
-PILLANATKÉP
Leszármazott
4.0.0
org.apache.maven.ci
ci-szülő
${revision}${sha1}${changelist}
org.apache.maven.ci
ci-gyerek
...
Ha a 2.0.0-SNAPSHOT verziót szeretné elkészíteni, akkor csak használja
mvn -Drevision=2.0.0 tiszta csomag
Ha kiadást szeretne készíteni, csak állítsa vissza a SNAPSHOT-ot
mvn -Dchangelist= tiszta csomag
*A fenti példák innen származnak a Maven Apache Project honlapján
Durva valóság
Minden jó és egészséges, itt az ideje, hogy elégedettséget érezzünk, de nem. Kiderült, hogy ez a módszer nem fog működni a telepítéshez és a telepítéshez, mivel nem lesz lecserélve a lerakatban közzétett műtermékek leírásában ${revision} jelentésére, és a maven többé nem fogja megérteni, miről van szó.
org.apache
apache
${revision}
Fény az alagút végén
Megoldást kell keresnünk a problémára. Megmenthette volna a helyzetet . Ez a beépülő modul feloldja a pom összes változóját, ugyanakkor kivág sok egyéb információt, amelyre csak az összeállítás során van szükség, és nincs szükség közzétett műtermékek más projektekbe történő importálásakor. A bővítmény emellett „kiegyenesíti” az összes szülő-gyerek függőséget, és ennek eredményeként egy lapos pomot kapunk, amiben minden szükséges. A kellemetlenség az volt, hogy túl sok „extrát” vág ki, ami nekünk egyáltalán nem jött be. A bővítmény fejlesztésével kapcsolatos információk tanulmányozása után kiderült, hogy nem mi vagyunk az egyetlenek az univerzumban, és még 2018 augusztusában a Githubon a plugin tárolójában egy pull-request hoztak létre azzal a szándékkal, hogy lehetővé tegyük ezt. hogy magunk határozzuk meg, hogyan kell „elrontani” a pom.xml-t. A fejlesztők meghallgatták a szenvedők hangját, és már decemberben, az új 1.1.0-s verzió megjelenésével a flatten-maven-pluginben megjelent egy új mód, a solveCiFriendliesOnly, amely minden eddiginél alkalmasabb volt - elhagyja pom.xml, ahogy van, kivéve az elemet és megengedi ${revision}, ${sha1} и ${changelist}.
Beépülő modul hozzáadása a projekthez
org.codehaus.mojo
flatten-maven-plugin
1.1.0
igaz
megoldaniCiFriendliesOnly
lelapul
folyamat-erőforrások
lelapul
lelapít.tiszta
tiszta
tiszta
Kész!
Boldog vég
Ezentúl ahhoz, hogy a teljes projekt verzióját módosítsuk, és minden függőséget tudjunk róla, csak az elemet kell szerkesztenünkfelülvizsgálata> csak a gyökérben pom.xml. Nem száz-két ilyen fájl ugyanazzal a változtatással érkezik a felülvizsgálathoz, hanem egy. Nos, nem kell használni versions-maven-plugin.
Forrás: will.com