2010-03-01 10 views
36

mam zależność maven w moim pom.xml jako takie:Czy mogę użyć ścieżki do zależności Maven jako własności?

<dependency> 
    <groupId>com.foo</groupId> 
    <artifactId>Bar</artifactId> 
    <version>1.2.3</version> 
</dependency> 

I chciałbym użyć ścieżki do systemu binarnego jako własność (tak mogę przekazać go do procesu zewnętrznego, który jest wykluczony off przez maven). Można zrobić to w niezręcznej sposób:

<properties> 
    <my.lib>${settings.localRepository}/com/foo/Bar/1.2.3/Bar.jar</my.lib> 
</properties> 

Ale naprawdę chciałbym użyć bardziej standardowego mechanizmu, takich jak:

<properties> 
    <my.lib>${com.foo:Bar:1.2.3}</my.lib> 
</properties> 

ja coś takiego jest możliwe?

+0

jestem trochę zdezorientowany: jeśli chcesz odnieść 'Bar.jar' jako biblioteki systemowej, należy określić' systemowych $ {my.lib} 'ale wydaje chcesz użyć' $ {my.lib} 'gdzieś indziej. Pokaż pełny przykład, jak chcesz użyć '$ {my.lib}' ... –

+1

@dma_k OP chce przekazać fizyczną ścieżkę do zależności do zewnętrznego procesu wyzwalanego przez maven. –

Odpowiedz

36

Zakładając, że com.foo:Bar:jar:1.2.3 artefakt jest zadeklarowana jako zależność w swoim POM następującą właściwość zwraca ścieżkę do słoika w lokalnym repozytorium

${maven.dependency.com.foo.Bar.jar.path} 

Aktualizacja: Oto prosty POM demonstrując w ten sposób:

<?xml version="1.0" encoding="UTF-8"?> 
<project> 
    <modelVersion>4.0.0</modelVersion> 
    <groupId>com.stackoverflow</groupId> 
    <artifactId>q2359872</artifactId> 
    <version>1.0-SNAPSHOT</version> 
    <name>q2359872</name> 
    <properties> 
    <my.lib>${maven.dependency.junit.junit.jar.path}</my.lib> 
    </properties> 
    <dependencies> 
    <dependency> 
     <groupId>junit</groupId> 
     <artifactId>junit</artifactId> 
     <version>3.8.1</version> 
     <scope>test</scope> 
    </dependency> 
    </dependencies> 
    <build> 
    <plugins> 
     <plugin> 
     <artifactId>maven-antrun-plugin</artifactId> 
     <executions> 
      <execution> 
      <phase>process-resources</phase> 
      <configuration> 
       <tasks> 
       <echo>${my.lib}</echo> 
       </tasks> 
      </configuration> 
      <goals> 
       <goal>run</goal> 
      </goals> 
      </execution> 
     </executions> 
     </plugin> 
    </plugins> 
    </build> 
</project> 

Running mvn process-resources daje następujący wynik:

 
$ mvn process-resources 
[INFO] Scanning for projects... 
[INFO] ------------------------------------------------------------------------ 
[INFO] Building q2359872 
[INFO] task-segment: [process-resources] 
[INFO] ------------------------------------------------------------------------ 
[INFO] [resources:resources {execution: default-resources}] 
[INFO] Using 'UTF-8' encoding to copy filtered resources. 
[INFO] skip non existing resourceDirectory /home/pascal/Projects/stackoverflow/q2359872/src/main/resources 
[INFO] [antrun:run {execution: default}] 
[INFO] Executing tasks 
    [echo] /home/pascal/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar 
[INFO] Executed tasks 
[INFO] ------------------------------------------------------------------------ 
[INFO] BUILD SUCCESSFUL 
[INFO] ------------------------------------------------------------------------ 
[INFO] Total time: 7 seconds 
[INFO] Finished at: Tue Mar 02 14:41:32 CET 2010 
[INFO] Final Memory: 7M/68M 
[INFO] ------------------------------------------------------------------------ 
+1

Nie mogę udowodnić, że ta funkcja działa w Maven. Działa to tylko dla 'maven-antrun-plugin' (patrz http://jira.codehaus.org/browse/MANTRUN-110). Podaj pełny przykład pom, tak jak przypuszczam, nie odwołujesz się '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' –

+0

@dma_k Problem Jira, o którym wspomniałeś, nie pokazuje niczego oprócz tego, że był błąd w dokumentacji Antrun. Teraz sam możesz przetestować to rozwiązanie. I BTW, zawsze testuję moje odpowiedzi :) –

+0

@Pascal Dzięki za aktualizację! W pełni ci ufam, że działa na twojej stronie :) Moje pytanie brzmiało: czy ma działać w połączeniu z 'maven-antrun-plugin'. Pokazujesz to na swoim przykładzie, świetnie! I na przykład widzę, że jest to specyficzna funkcja 'maven-antrun-plugin', tzn. Jeśli chcę zastąpić zmienną' $ {my.lib} 'dla zasobów (bez użycia dodatkowego pugina) - nie mogę tego zrobić, prawda ? –

0

Musisz napisać nową wtyczkę maven, która ustawia wartość właściwości na pełną ścieżkę do nazwy zależności. Wtyczka zależna od mavenów nie zrobi tego za ciebie.

To będzie skopiować gdzieś swoją zależność, a następnie możesz odwoływać się do niej przez tę ścieżkę.

47

Oto prawidłowa realizacja, za pomocą maven-dependency-plugin properties goal, który może być używany w dowolnym miejscu pom:

<?xml version="1.0" encoding="UTF-8"?> 
<project> 
    <modelVersion>4.0.0</modelVersion> 
    <groupId>com.stackoverflow</groupId> 
    <artifactId>q2359872</artifactId> 
    <version>2.0-SNAPSHOT</version> 
    <name>q2359872</name> 

    <properties> 
     <!-- Must be listed in the dependencies section otherwise it will be null. --> 
     <my.lib>${org.jmockit:jmockit:jar}</my.lib> 
    </properties> 
    <dependencies> 
     <dependency> 
      <groupId>org.jmockit</groupId> 
      <artifactId>jmockit</artifactId> 
      <version>1.11</version> 
     </dependency> 
    </dependencies> 
    <build> 
     <defaultGoal>generate-sources</defaultGoal> 
     <plugins> 
      <plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-dependency-plugin</artifactId> 
       <version>2.3</version> 
       <executions> 
        <execution> 
         <goals> 
          <goal>properties</goal> 
         </goals> 
        </execution> 
       </executions> 
      </plugin> 
      <!-- Example usage: --> 
      <plugin> 
       <groupId>org.codehaus.mojo</groupId> 
       <artifactId>exec-maven-plugin</artifactId> 
       <version>1.2</version> 
       <executions> 
        <execution> 
         <goals> 
          <goal>exec</goal> 
         </goals> 
         <phase>generate-sources</phase> 
        </execution> 
       </executions> 
       <configuration> 
        <executable>echo</executable> 
        <arguments> 
         <argument>path to jar=</argument> 
         <argument>${org.jmockit:jmockit:jar}</argument> 
         <argument>my.lib=</argument> 
         <argument>${my.lib}</argument> 
        </arguments> 
       </configuration> 
      </plugin> 
      <!-- end of Example usage --> 
     </plugins> 
    </build> 
</project> 

a wyjście jest ...

[email protected] /projects/wkspc/tmp/foo 
$ /cygdrive/c/programs.x86_64/apache-software-foundation/apache-maven-3.1.1/bin/mvn 
[INFO] Scanning for projects... 
[INFO] 
[INFO] ------------------------------------------------------------------------ 
[INFO] Building q2359872 2.0-SNAPSHOT 
[INFO] ------------------------------------------------------------------------ 
[INFO] 
[INFO] --- maven-dependency-plugin:2.3:properties (default) @ q2359872 --- 
[INFO] 
[INFO] --- exec-maven-plugin:1.2:exec (default) @ q2359872 --- 
path to jar= C:\Documents and Settings\jpyeron\.m2\repository\org\jmockit\jmockit\1.11\jmockit-1.11.jar my.lib= C:\Documents and Settings\jpyeron\.m2\repository\org\jmockit\jmockit\1.11\jmockit-1.11.jar 
[INFO] ------------------------------------------------------------------------ 
[INFO] BUILD SUCCESS 
[INFO] ------------------------------------------------------------------------ 
[INFO] Total time: 2.032s 
[INFO] Finished at: Wed Sep 17 12:07:18 EDT 2014 
[INFO] Final Memory: 10M/153M 
[INFO] ------------------------------------------------------------------------ 
+2

To działało idealnie dla mnie. Dzięki za post! – kurzweil4

+0

Może to być mniej kłopotliwe, jeśli Twój przykład użył innej zależności. Dla zainteresowanych, jeśli potrzebne słoik dla JMockit, nieruchomość będzie tak: $ {org.jmockit: jmockit: jar} to znaczy: $ {GroupID: artifactId: jar} – kurzweil4

+0

dobry punkt, edytowany. –

1

Jeśli żadna z górnej pracy , zawsze możesz użyć gmaven, aby agresywnie zanurkować w obiekt MavenProject i uzyskać informacje o artefakcie. W moim przypadku, miałem następujący artefakt zadeklarowanej w profilu:

  <!-- Neo4J connector. This dependency is scoped to be usable by maven-exec-plugin 
       which installs it in Glassfish --> 
      <dependency> 
       <groupId>com.netoprise</groupId> 
       <artifactId>neo4j-connector</artifactId> 
       <version>${neo4j.connector.version}</version> 
       <type>rar</type> 
       <!-- Set in test scope to avoid release issues --> 
       <scope>test</scope> 
      </dependency> 

dostać swoją ścieżkę i umieścić go w nieruchomości maven, napisałem następujące gmaven skrypt:

   <!-- Small script used to build maven property for neo4j-connector path --> 
       <plugin> 
        <groupId>org.codehaus.gmaven</groupId> 
        <artifactId>gmaven-plugin</artifactId> 
        <version>1.3</version> 
        <executions> 
         <execution> 
          <id>get-neo4j-connector-rar-path</id> 
          <phase>validate</phase> 
          <goals> 
           <goal>execute</goal> 
          </goals> 
          <configuration> 
           <source> 
            <![CDATA[ 
println "initial value of neo4j.connector.rarPath is \""+project.properties['neo4j.connector.rarPath']+"\""        

// Duplicate model in a Mavenproject, allowing me to get associated artifact 
// So sad I can't get the embdder object 

// More info here : http://maven.apache.org/ref/3.0.3/maven-core/apidocs/org/apache/maven/project/MavenProject.html 
def mavenProject = new org.apache.maven.project.MavenProject(project) 

// More infos on Artifact there : http://maven.apache.org/ref/3.0.3/maven-artifact/apidocs/org/apache/maven/artifact/Artifact.html 
def neo4jConnector = mavenProject.getArtifacts().find { artifact -> artifact.getArtifactId()=='neo4j-connector' } 
// Now resolve dependency to produce an artifact 
// notice maven property interpolation doesn't do toString, so we have to do it ourselves 
project.properties['neo4j.connector.rarPath'] = neo4jConnector.getFile().getAbsolutePath() 

println "usable neoj4Connector can be found at "+project.properties['neo4j.connector.rarPath'] 

            ]]> 
           </source> 
          </configuration> 
         </execution> 
        </executions> 
       </plugin> 

to jakiś metody brutalnej siły, ale działa znacznie lepiej niż poprzednie rozwiązania, które tam widziałem.

Powiązane problemy