7

Mam aplikację na Androida, która jest zbudowana z Maven. Korzystając z buildnumber-maven-plugin i maven-resources-plugin wstawiam wersję projektu maven i mieszanie commit git do AndroidManifest. Celem create celem buildnumber-maven-plugin jest faza validate, a cel resources maven-resources-plugin działa w fazie initialize.Dlaczego mój pom nie jest poprawnie wykonany podczas używania Androida Studio/IntelliJ?

Po zbudowaniu za pomocą wiersza polecenia (z mvn install) wszystko działa poprawnie, a numer kompilacji pojawia się poprawnie w wygenerowanym manifeście.

Jednak podczas budowania przez Android Studio lub IntelliJ nie ma wartości mieszania git commit (właściwość Maven nie jest zastępowana rzeczywistą wartością) w manifeście, ale wersja projektu maven.

Dlaczego?



FYI: Android Studio przebiega faza Maven środki procesowe przed make, więc powinien działać.

W linii poleceń używam Maven 3.0.3, więc może to być problem z wersją (chociaż nie mogę się dowiedzieć, jakiej wersji używa IntelliJ).

Oto moja POM Build elementem:

<build> 
    <sourceDirectory>src</sourceDirectory> 
    <testSourceDirectory>test</testSourceDirectory> 

    <resources> 
     <resource> 
      <directory>${project.basedir}</directory> 
      <filtering>true</filtering> 
      <targetPath>${project.build.directory}/filtered-manifest</targetPath> 
      <includes> 
       <include>AndroidManifest.xml</include> 
      </includes> 
     </resource> 
    </resources> 

    <plugins> 
     <plugin> 
      <groupId>org.codehaus.mojo</groupId> 
      <artifactId>buildnumber-maven-plugin</artifactId> 
      <version>${maven.buildnumber.version}</version> 
      <configuration> 
       <doCheck>false</doCheck> 
       <doUpdate>false</doUpdate> 
       <shortRevisionLength>6</shortRevisionLength> 
       <revisionOnScmFailure>000000</revisionOnScmFailure> 
      </configuration> 
      <executions> 
       <execution> 
        <phase>validate</phase> 
        <goals> 
         <goal>create</goal> 
        </goals> 
       </execution> 
      </executions> 
     </plugin> 

     <plugin> 
      <artifactId>maven-resources-plugin</artifactId> 
      <version>${maven.resources.version}</version> 
      <executions> 
       <execution> 
        <phase>initialize</phase> 
        <goals> 
         <goal>resources</goal> 
        </goals> 
       </execution> 
      </executions> 
     </plugin> 

     <plugin> 
      <groupId>com.jayway.maven.plugins.android.generation2</groupId> 
      <artifactId>android-maven-plugin</artifactId> 
      <extensions>true</extensions> 
      <configuration> 
       <androidManifestFile>${project.build.directory}/filtered-manifest/AndroidManifest.xml</androidManifestFile> 
      </configuration> 
     </plugin> 
    </plugins> 
</build> 

A versionName w moim AndroidManifest pliku to:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" 
    package="com.somecompany" 
    android:versionCode="1" 
    android:versionName="${project.version}-${buildNumber}" > 

Od poleceń zarówno $ {project.version} oraz $ {} są wypełnione buildNumber poprawnie z ich wartościami, z IntelliJ $ {buildNumber} nie jest i po prostu pojawia się jako "$ {buildNumber}": oznaczałoby to (odkąd ustawiłem revisionOnScmFailure), że wtyczka w ogóle nie działa.

Próbowałem zmienić cel create, aby uruchomić w fazie initialize (w przypadku, gdy IntelliJ pomijał validate), ale to nie miało znaczenia.

+0

Czy osiągnięto postęp w tej kwestii? –

+0

Niestety, jeszcze nie; jako obejście możesz użyć zadania "zainstaluj" z IntelliJ zamiast "make" –

Odpowiedz

7

IntelliJ ma własny wewnętrzny system kompilacji, podobnie jak każdy inny IDE i jest w stanie budować projekty bez pomocy zewnętrznych narzędzi. Intellij integruje się również z Maven, interpretując pom.xml z twojego projektu i wprowadzając go do kompilacji w oparciu o zdefiniowaną konfigurację. Działa to całkiem dobrze w przypadku większości zadań kompilacji, ale zaczyna się przewracać, gdy wprowadzasz bardziej złożone wtyczki, takie jak buildnumber-maven-plugin. Niestety IntelliJ nie ma wewnętrznego odpowiednika do obsługi tej wtyczki, więc właściwość $ {buildNumber} nie jest nigdy zapełniona.

Możliwe obejścia są:

  1. Nie budować swój projekt z IntelliJ wbudowanego w systemie, użyj panelu „Maven Projects”, który można pokazać, przechodząc do „Widok”> „narzędzie Windows” > "Projekty Maven". Daje to dostęp do wszystkich standardowych faz Mavena i innych funkcji.

  2. W konfiguracji uruchamiania IntelliJ dodaj zmienną środowiskową o nazwie "numer_budowy" i nadaj jej dowolną wartość, na przykład: buildNumber = DEV. To sprawi, że właściwość buildNumber będzie dostępna podczas procesu budowania i zapełni właściwość, ale nie zostanie zaktualizowana z twojego SCM.

Stosujemy pierwsze obejście tego wielomodułowego projektu, ponieważ my również dotknęliśmy podobnych ograniczeń przy użyciu dodatku buildnumber-maven. Używamy także rozwiązania 2, gdy musimy uruchomić test integracji w IntelliJ, ponieważ właściwość buildNumber jest wymagana przez nasz kod do wyświetlania informacji o wersji, o ile zapewniamy jakąkolwiek wartość, która jest szczęśliwa.

Mam nadzieję, że jest to dla ciebie przydatne, jedynym rozwiązaniem dla wewnętrznego systemu budowania IntelliJ jest zrozumienie wtyczki buildnumber-maven i ujawnienie odpowiednich właściwości dla środowiska podczas procesu budowania.

+0

Ale to nie ** po prostu zaimportuj POM, to też * przypuszczasz *, aby uruchomić zasoby procesu Maven, co powinno skutkować w uruchamianej wtyczce buildnumber. Dzięki za odpowiedzi. O ile mi chodzi o nasz przypadek 1. jest nie do przyjęcia, ponieważ niewielu deweloperów wytrzyma wzrost czasu budowy, ale 2. prawdopodobnie to zrobi. Będę trzymać to oznaczenie jako poprawne, aby dać trochę czasu na inne odpowiedzi. –

+0

Trudno mi było się dowiedzieć, co faktycznie robi kompilator IntelliJ, kiedy interpretuje pom.xml w przeszłości, ale nie ma tam zbyt wielu informacji. Rozumiem, że IntelliJ nie angażuje maven w fazie "process-resources" (ani w żadnej fazie), ale ma własną implementację "zasobów procesowych", która jest konfigurowana przez czytanie pom.xml –