გამოცდილება flatten-maven-plug-ის გამოყენებით maven პროექტებში ვერსიების გამარტივებისთვის

ჩვენს შესახებ

1C-ზე ჩვენ ვავითარებთ არა მხოლოდ პლატფორმას 1C: საწარმო on C ++ и JavaScript, არამედ Java აპლიკაციები - განსაკუთრებით ახალი განვითარების გარემო საწარმოს განვითარების ინსტრუმენტები Eclipse-ზე და პლატფორმასთან ღრმად ინტეგრირებული მესინჯერ სერვერზე დაფუძნებული - ურთიერთქმედების სისტემები.

Entry

ჩვენ ყველაზე ხშირად ვიყენებთ maven-ს, როგორც build სისტემას Java აპლიკაციებისთვის და ამ მოკლე სტატიაში გვსურს ვისაუბროთ ერთ-ერთ პრობლემაზე, რომელიც გვქონდა შეგვექმნა განვითარების ორგანიზების პროცესში და მიდგომაზე, რომელმაც ამის დაძლევის საშუალება მოგვცა. პრობლემა.

წინაპირობები და სამუშაო პროცესი

ჩვენი maven პროექტების განვითარების სპეციფიკიდან გამომდინარე, ჩვენ ვიყენებთ საკმაოდ ბევრ მოდულს, დამოკიდებულებებს და ბავშვთა პროექტებს. პომ ფაილების რაოდენობა ერთ ხეში შეიძლება იყოს ათობით ან თუნდაც ასობით.

როგორც ჩანს: დიდი არაფერია, ერთხელ შექმნეს და დაივიწყეს. თუ თქვენ გჭირდებათ რაღაცის შეცვლა ან დამატება ყველა ფაილში ერთდროულად, არსებობს უამრავი მოსახერხებელი ინსტრუმენტი რედაქტორებსა და IDE-ებში. რა არის ყველაზე გავრცელებული რეგულარული ცვლილება pom.xml-ზე? ჩვენ გვჯერა, რომ ცვლილებები პროექტის ვერსიებსა და დამოკიდებულებებში. შეიძლება ვინმეს მოუნდეს ამაზე კამათი, მაგრამ ჩვენთანაც ზუსტად ასეთი სიტუაციაა. მიზეზი მდგომარეობს იმაში, რომ ბირთვთან ერთად, ჩვენ ერთდროულად ვავითარებთ ჩვენს მრავალ ბიბლიოთეკას და კონსტრუქციისა და ტესტირების შედეგების მუდმივი რეპროდუქციისთვის, სნეპშოტების გამოყენება არ გვეჩვენება მოსახერხებელი მიდგომა. ამ მიზეზით, აუცილებელია პროექტებში ვერსიის ნომრის ამაღლება ყოველი აშენებით.

ასევე, დროდადრო დეველოპერს სჭირდება ბიბლიოთეკის საკუთარი ფილიალის აშენება და მისი ფუნქციონირების შემოწმება ყველა დამოკიდებულებისგან, რისთვისაც მან ხელით უნდა შეცვალოს ყველა მათგანის ვერსია.

საწყისი გადაწყვეტა

ასეთი ხშირი და მრავალჯერადი ვერსიის ცვლილებებით, მსურს გავამარტივოთ და ავტომატიზირება მოვახდინოთ პროცესის CI-ში. სწორედ აქ მოდის მოსახერხებელი, კარგად ცნობილი მოდული სამაშველოში. versions-maven-plugin - დააკავშირეთ და გაუშვით

mvn -N ვერსიები:set -DnewVersion=2.0.1

და Maven ყველაფერს გააკეთებს ისე, როგორც უნდა: ის გაივლის იერარქიაში ზემოდან ქვემოდან, ჩაანაცვლებს ყველა ვერსიას - სილამაზის! ახლა რჩება მხოლოდ გაყვანის მოთხოვნის წამოყენება, კოლეგები განიხილავენ ცვლილებებს და თქვენ შეგიძლიათ სწრაფად შეუერთდეთ საბარგულს. სწრაფად? როგორიც არ უნდა იყოს. რამდენიმე ასეული pom.xml განსახილველად და ეს არ ითვლის კოდს. გარდა ამისა, არავინ არის დაცული შერწყმის კონფლიქტებისგან შეცვლილი ფაილების ამხელა რაოდენობასთან. აქვე უნდა აღინიშნოს, რომ CI პროცესში ვერსიის ცვლილებები ავტომატურად ხდება ფუნქციონალურ ცვლილებებთან ერთად და არა ცალკე.

ახალი თვისებები

ცოტა ხანი დავმშვიდდით და, თავი რომ დავანებეთ, ასე ვიცხოვრეთ, სანამ ბიჭები არ წავიდნენ Maven Apache პროექტი 3.5.0-beta-1 ვერსიიდან დაწყებული, Maven არ მოიცავდა ე.წ. "placeholders" მხარდაჭერას. ამ შემცვლელების არსი ის არის pom.xml პროექტის ვერსიის კონკრეტული მითითების ნაცვლად, გამოიყენება ცვლადები ${რევიზია}, ${sha1} и ${changelist}. თავად ამ თვისებების მნიშვნელობები მითითებულია ან ელემენტშითვისებები>, ან მათი განსაზღვრა შესაძლებელია სისტემის თვისების მეშვეობით

mvn -Drevision=2.0.0 სუფთა პაკეტი

სისტემის თვისებების მნიშვნელობებს უპირატესობა ენიჭება განსაზღვრულ მნიშვნელობებზეთვისებები>.

მშობელი

  4.0.0
  
    org.apache
    აპაჩი
    18
  
  org.apache.maven.ci
  ცი-მშობელი
  პირველი CI Friendly
  ${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
    აპაჩი
    ${რევიზია}

შუქი გვირაბის ბოლოს

ჩვენ უნდა ვეძიოთ პრობლემის გადაწყვეტა. შეიძლებოდა სიტუაციის გადარჩენა flatten-maven-plugin. ეს დანამატი წყვეტს პომში არსებულ ყველა ცვლადს, მაგრამ ამავე დროს წყვეტს უამრავ სხვა ინფორმაციას, რომელიც საჭიროა მხოლოდ შეკრების დროს და არ არის საჭირო გამოქვეყნებული არტეფაქტების სხვა პროექტებში იმპორტის დროს. მოდული ასევე „ასწორებს“ მშობლისა და ბავშვის ყველა დამოკიდებულებას და შედეგად, თქვენ მიიღებთ ბრტყელ პომს, რომელიც მოიცავს ყველაფერს, რაც გჭირდებათ. უხერხულობა ის იყო, რომ ის წყვეტს ძალიან ბევრ „ზედმეტს“, რაც საერთოდ არ გვიწყობდა. ამ მოდულის შემუშავების შესახებ ინფორმაციის შესწავლის შემდეგ, აღმოჩნდა, რომ ჩვენ არ ვართ ერთადერთი სამყაროში და ჯერ კიდევ 2018 წლის აგვისტოში, Github-ზე შეიქმნა pull-მოთხოვნა დანამატის საცავში, სურვილით, რომ ეს შესაძლებელი ყოფილიყო. რომ დამოუკიდებლად განვსაზღვროთ როგორ „გავაფუჭოთ“ pom.xml. დეველოპერებმა მოუსმინეს დაზარალებულთა ხმებს და უკვე დეკემბერში, ახალი ვერსიის 1.1.0 გამოშვებით, flatten-maven-პლაგინში გამოჩნდა ახალი რეჟიმი, solveCiFriendliesOnly, რომელიც უფრო შესაფერისი იყო, ვიდრე ოდესმე - ის ტოვებს. pom.xml როგორც არის, გარდა ელემენტისა და საშუალებას აძლევს ${რევიზია}, ${sha1} и ${changelist}.

პროექტში მოდულის დამატება

  
    org.codehaus.mojo
    flatten-maven-plugin
    1.1.0
    
      მართალია
      zgjidhjeCiFriendliesOnly
    
    
      
        გააბრტყელებენ
        პროცესი-რესურსები
        
          გაბრტყელება
        
      
      
        გაბრტყელება.სუფთა
        სუფთა
        
          სუფთა
        
      
    
  

შესრულებულია!

Ბედნიერი დასასრული

ამიერიდან, იმისათვის, რომ შევცვალოთ მთელი პროექტის ვერსია და ყველა დამოკიდებულებამ იცოდეს ამის შესახებ, ჩვენ უბრალოდ უნდა შევცვალოთ ელემენტირევიზია> მხოლოდ ძირში pom.xml. ამ ფაილებიდან არა ასი ან ორი ერთი და იგივე ცვლილებით მოდის განხილვაზე, არამედ ერთი. ისე, არ არის საჭირო გამოყენება versions-maven-plugin.

წყარო: www.habr.com