Przekazywanie argumentów wiersza poleceń z Mavena jako właściwości w pom.xml


100

Czy można przekazać argumenty z wiersza poleceń do właściwości w pom.xmlpliku? na przykład biegammvn ... argument

i w pom.xml

<properties>
   <myproperty> here should add argument from command line</myproperty>
</properties>

Dziękuję za pomoc.


Nie jest to bezpośrednio to, o co prosisz, ale profile maven mogą być do tego przydatne
Sig

tak, wiem o profilach. Używam wtyczki maven-soapui-plugin, gdzie w <projectFile> ... </projectFile> jest zdefiniowana nazwa projektu. Mam około 10 projektów i nie chcę dla każdego projektu nowego profilu. Chcę użyć argumentu, aby uruchomić mvn ... project1, aby uruchomić project1 i mvn ... project2, aby uruchomić project2
hudi

Odpowiedzi:


134

Na przykład dla swojej nieruchomości:

mvn install "-Dmyproperty=my property from command line"

Zwróć uwagę na cudzysłowy wokół całej definicji właściwości. Będziesz ich potrzebować, jeśli twoja nieruchomość zawiera spacje.


19
Zauważ również, że jeśli masz zarówno właściwość w pom, jak iw wierszu poleceń, wiersz poleceń ma pierwszeństwo. Może to być przydatne przy zapewnianiu możliwych do zastąpienia wartości domyślnych.
dan carter

2
Możemy również przekazać wiele takich argumentów, na przykład:mvn clean install "-Dprop1=value1" "-Dprop2=value2"
Sumit

15

Użyłem wtyczki właściwości, aby rozwiązać ten problem.

Właściwości są definiowane w pom i zapisywane w pliku my.properties, skąd można uzyskać do nich dostęp z kodu Java.

W moim przypadku jest to kod testowy, który musi uzyskać dostęp do tego pliku właściwości, więc w pom plik właściwości jest zapisywany do testOutputDirectory mavena:

<configuration>
    <outputFile>${project.build.testOutputDirectory}/my.properties</outputFile>
</configuration>

Użyj outputDirectory, jeśli chcesz, aby właściwości były dostępne przez kod aplikacji:

<configuration>
    <outputFile>${project.build.outputDirectory}/my.properties</outputFile>
</configuration>

Dla tych, którzy szukają pełniejszego przykładu (zajęło mi trochę majstrowania, aby to działało, ponieważ nie rozumiałem, jak nazewnictwo tagów właściwości wpływa na możliwość ich pobrania w innym miejscu w pliku pom), mój pom wygląda następująco:

<dependencies>
     <dependency>
      ...
     </dependency>
</dependencies>

<properties>
    <app.env>${app.env}</app.env>
    <app.port>${app.port}</app.port>
    <app.domain>${app.domain}</app.domain>
</properties>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.20</version>
        </plugin>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>properties-maven-plugin</artifactId>
            <version>1.0.0</version>
            <executions>
                <execution>
                    <phase>generate-resources</phase>
                    <goals>
                        <goal>write-project-properties</goal>
                    </goals>
                    <configuration>
                        <outputFile>${project.build.testOutputDirectory}/my.properties</outputFile>
                    </configuration>
                </execution>
            </executions>
        </plugin>

    </plugins>
</build>

A w wierszu poleceń:

mvn clean test -Dapp.env=LOCAL -Dapp.domain=localhost -Dapp.port=9901

Zatem do tych właściwości można uzyskać dostęp z kodu Java:

 java.io.InputStream inputStream = Thread.currentThread().getContextClassLoader().getResourceAsStream("my.properties");
 java.util.Properties properties = new Properties();
 properties.load(inputStream);
 appPort = properties.getProperty("app.port");
 appDomain = properties.getProperty("app.domain");

Mój plik właściwości w javie ma taką samą wartość jak $ {app.env}, ale nie pobiera go z wiersza poleceń mavena, czy nazwa właściwości powinna być równa takiej wartości? <app.env> $ {app.env} </ app.env>
Sujith

14

Wewnątrz pom.xml

<project>

.....

<profiles>
    <profile>
        <id>linux64</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <build_os>linux</build_os>
            <build_ws>gtk</build_ws>
            <build_arch>x86_64</build_arch>
        </properties>
    </profile>

    <profile>
        <id>win64</id>
        <activation>
            <property>
                <name>env</name>
                <value>win64</value>
            </property>
        </activation>
        <properties>
            <build_os>win32</build_os>
            <build_ws>win32</build_ws>
            <build_arch>x86_64</build_arch>
        </properties>
    </profile>
</profiles>

.....

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>target-platform-configuration</artifactId>
    <version>${tycho.version}</version>
    <configuration>
        <environments>
            <environment>
                <os>${build_os}</os>
                <ws>${build_ws}</ws>
                <arch>${build_arch}</arch>
            </environment>
        </environments>
    </configuration>
</plugin>

.....

W tym przykładzie po uruchomieniu pom bez żadnego argumentu mvn clean installzostanie wykonany domyślny profil.

Po wykonaniu z mvn -Denv=win64 clean install

profil win64 zostanie wykonany.

Zobacz http://maven.apache.org/guides/introduction/introduction-to-profiles.html


Odkąd używasz którego profilu, czy powinien być mvn clean -Pwin64?
sendon1982

6

Nazwy zmiennych można nadawać jako pliki projektu. Na przykład w konfiguracji wtyczki podaj tylko jeden tag, jak poniżej: -

<projectFile>${projectName}</projectFile>

Następnie w linii poleceń możesz podać nazwę projektu jako parametr: -

mvn [your-command] -DprojectName=[name of project]

Chcę podać nazwę przeglądarki i środowisko w poleceniu mvn. Jeśli nie podam, wybierze opcję domyślną. Jak to zrobić?
paul

1
mvn clean package -DpropEnv=PROD

Następnie używając w ten sposób w POM.xml

<properties>
    <myproperty>${propEnv}</myproperty>
</properties>
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.