คุณสมบัติ Maven2 ที่ระบุไดเร็กทอรีหลัก


107

ฉันมีโครงการหลายโมดูลเช่นนี้:

main-project/
    module1/
    module2/
        sub-module1/
        sub-module2/
        sub-module3/
        ...
    module3/
    module4/
    ...

ฉันต้องการกำหนดชุดของคุณสมบัติ (ซึ่งขึ้นอยู่กับสภาพแวดล้อมที่ฉันต้องการปล่อยโปรเจ็กต์ของฉัน) ใน Maven2 ฉันจะไม่ใช้<properties>ที่มีจำนวนมากของคุณสมบัติ ... ดังนั้นผมใช้ปลั๊กอินคุณสมบัติ Maven2

ไฟล์คุณสมบัติอยู่ในmain-project/ไดเร็กทอรี ฉันจะตั้งค่าไดเร็กทอรีที่ถูกต้องใน pom.xml หลักได้อย่างไรเพื่อระบุให้กับชายน์ที่จะค้นหาไฟล์คุณสมบัติ

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <version>1.0-alpha-1</version>
    <executions>
        <execution>
            <phase>initialize</phase>
            <goals>
                <goal>read-project-properties</goal>
            </goals>
            <configuration>
                <files>
                    <file>???/env_${env}.properties</file>
                </files>
            </configuration>
        </execution>
    </executions>
</plugin>

ถ้าฉันตั้งค่าอย่างเดียว<file>env_${env}.properties</file>เมื่อ Maven2 รวบรวมโมดูลแรกจะไม่พบmain-project/env_dev.propertiesไฟล์ ถ้าฉันตั้งค่า<file>../env_${env}.properties</file>ข้อผิดพลาดจะเพิ่มขึ้นที่ระดับแม่หรือที่ระดับโมดูลย่อยใด ๆ ...


1
เพียงแค่ใช้${maven.multiModuleProjectDirectory}
qoomon

คำตอบ:


166

ลองตั้งค่าคุณสมบัติในแต่ละ pom เพื่อค้นหาไดเร็กทอรีโปรเจ็กต์หลัก

ในผู้ปกครอง:

<properties>
    <main.basedir>${project.basedir}</main.basedir>
</properties>

ในเด็ก:

<properties>
    <main.basedir>${project.parent.basedir}</main.basedir>
</properties>

ในรุ่นหลาน:

<properties>
    <main.basedir>${project.parent.parent.basedir}</main.basedir>
</properties>

19
คุณสมบัติที่ตั้งไว้ล่วงหน้าเหล่านี้ถูกลบออกหรือไม่ ${parent.basedir}ไม่แยกวิเคราะห์อีกต่อไปใน 3.0.4 ...
matt5784

7
ใช่ไม่ได้ผล $ {project.parent.basedir} ประเมินเป็น null
Jared

22
ฉันประสบความสำเร็จ${project.basedir}/..แต่นั่นใช้ได้เฉพาะกับโปรเจ็กต์หลายโมดูลที่อยู่ในลำดับชั้นของไดเร็กทอรีที่เข้มงวด
Jonathan

90
เฮ้อ. ไม่น่าเชื่อว่า Maven ทำให้ยากขนาดนี้
Stefan Haberl

5
เช่นเดียวกับโจนาธานข้างต้นฉันต้องใช้เส้นทางสัมพัทธ์ แต่รู้สึกว่าดีที่สุดที่จะใช้file.separatorตัวแปรเช่นนี้<main.basedir>${project.basedir}${file.separator}..</main.basedir>
Enwired

30

อย่างน้อยในเวอร์ชัน maven ปัจจุบัน (3.6.0) คุณสามารถใช้ประโยชน์จากไฟล์ ${maven.multiModuleProjectDirectory}


2
พยายามค้นหาเอกสารเกี่ยวกับสิ่งนี้และดูเหมือนว่านี่มีไว้เพื่อการใช้งานภายในอาจถูกลบ / เปลี่ยนแปลงในอนาคตMNG-6589
Greg Domjan

ใช้ประโยชน์อย่างไร -1
hey_you

เป็นทรัพย์สินคุณสามารถใช้ทำกับคนอื่นได้
qoomon

ฉันไม่แน่ใจว่าเราควรใช้คำตอบนี้ ตามตั๋วนี้เป็นตั๋วภายในและสามารถไปได้ตลอดเวลา นั่นเป็นเหตุผลว่าทำไมจึงไม่มีการบันทึกไว้ที่ใดก็ได้ ยังคงไม่มีวิธีแก้ปัญหาที่สะอาด
Hilikus

22

ใช้ไดเรกทอรี Maven ปลั๊กอินกับไดเรกทอรีของเป้าหมาย

ไม่เหมือนคำแนะนำอื่น ๆ :

  • โซลูชันนี้ใช้ได้กับโครงการหลายโมดูล
  • ใช้งานได้ไม่ว่าคุณจะสร้างโครงการทั้งหมดหรือโมดูลย่อย
  • ใช้งานได้ไม่ว่าคุณจะเรียกใช้ maven จากโฟลเดอร์รูทหรือโมดูลย่อย
  • ไม่จำเป็นต้องตั้งค่าคุณสมบัติพา ธ สัมพัทธ์ในแต่ละโมดูลย่อย!

ปลั๊กอินช่วยให้คุณตั้งค่าคุณสมบัติที่คุณต้องการให้เป็นพา ธ สัมบูรณ์ของโมดูลใด ๆ ของโครงการ ในกรณีของฉันฉันตั้งค่าเป็นโมดูลรูท ... ในโปรเจ็กต์ root pom:

<plugin>
    <groupId>org.commonjava.maven.plugins</groupId>
    <artifactId>directory-maven-plugin</artifactId>
    <version>0.1</version>
    <executions>
        <execution>
            <id>directories</id>
            <goals>
                <goal>directory-of</goal>
            </goals>
            <phase>initialize</phase>
            <configuration>
                <property>myproject.basedir</property>
                <project>
                    <groupId>com.my.domain</groupId>
                    <artifactId>my-root-artifact</artifactId>
                </project>
            </configuration>
        </execution>
    </executions>
</plugin>

จากนั้น $ {myproject.basedir} ในโมดูลย่อยใด ๆ จะมีพา ธ ของโมดูลรูทโปรเจ็กต์เสมอ และแน่นอนคุณสามารถตั้งค่าคุณสมบัติเป็นโมดูลใดก็ได้ไม่ใช่แค่รูท ...


อย่าใส่ "ทดสอบ" สำหรับเฟส ทำให้ฉันมีปัญหามากมาย ใช้งานได้ดีดังที่แสดงไว้ด้านบน
ElectronicBlacksmith

15

ฉันพบวิธีแก้ปัญหาของฉัน: ฉันค้นหาไฟล์คุณสมบัติโดยใช้ปลั๊กอิน Groovy Maven

เนื่องจากไฟล์คุณสมบัติของฉันจำเป็นต้องอยู่ในไดเร็กทอรีปัจจุบันใน .. / หรือใน .. / .. ฉันจึงเขียนโค้ด Groovy ขนาดเล็กเพื่อตรวจสอบโฟลเดอร์ทั้งสามนี้

นี่คือสารสกัดจาก pom.xml ของฉัน:

<!-- Use Groovy to search the location of the properties file. -->
<plugin>
    <groupId>org.codehaus.groovy.maven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.0-rc-5</version>
    <executions>
        <execution>
            <phase>validate</phase>
            <goals>
                <goal>execute</goal>
            </goals>
            <configuration>
                <source>
                    import java.io.File;
                    String p = project.properties['env-properties-file'];
                    File f = new File(p); 
                    if (!f.exists()) {
                        f = new File("../" + p);
                        if (!f.exists()) {
                            f = new File("../../" + p);
                        }
                    }
                    project.properties['env-properties-file-by-groovy'] = f.getAbsolutePath();
            </source>
            </configuration>
        </execution>
    </executions>
</plugin>
<!-- Now, I can load the properties file using the new 'env-properties-file-by-groovy' property. -->
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <version>1.0-alpha-1</version>
    <executions>
        <execution>
            <phase>initialize</phase>
            <goals>
                <goal>read-project-properties</goal>
            </goals>
            <configuration>
                <files>
                    <file>${env-properties-file-by-groovy}</file>
                </files>
            </configuration>
        </execution>
    </executions>
</plugin>

นี่ใช้งานได้ แต่ฉันไม่ชอบมันจริงๆ

ดังนั้นหากคุณมีทางออกที่ดีกว่านี้อย่าลังเลที่จะโพสต์!


12

ดังนั้นปัญหาที่ฉันเห็นคือคุณไม่สามารถรับเส้นทางสัมบูรณ์ไปยังไดเรกทอรีหลักใน maven ได้

<rant> ฉันเคยได้ยินเรื่องนี้พูดถึงว่าเป็นรูปแบบการต่อต้านแต่สำหรับรูปแบบการต่อต้านทุกรูปแบบจะมีกรณีการใช้งานที่แท้จริงและถูกต้องตามกฎหมายและฉันเบื่อที่จะบอกว่าฉันสามารถทำตามรูปแบบของพวกเขาได้เท่านั้น </ พูดจาโผงผาง>

ดังนั้นวิธีแก้ไขที่ฉันพบคือการใช้ antrun ลองสิ่งนี้ใน pom.xml ลูก:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.7</version>
    <executions>
        <execution>
            <id>getMainBaseDir</id>
            <phase>validate</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <exportAntProperties>true</exportAntProperties>
                <target>
                    <!--Adjust the location below to your directory structure -->
                    <property name="main.basedir" location="./.." />
                    <echo message="main.basedir=${main.basedir}"/>
                </target>
            </configuration>
        </execution>
    </executions>
</plugin>

หากคุณเรียกใช้mvn verifyคุณจะเห็นสิ่งนี้:

main:
     [echo] main.basedir=C:\src\parent.project.dir.name

จากนั้นคุณสามารถใช้${main.basedir}ในปลั๊กอินอื่น ๆ ได้ ฯลฯ ใช้เวลาสักพักเพื่อคิดออกดังนั้นหวังว่าจะช่วยคนอื่นได้


ฉันจะส่งต่อไปยัง maven-surefire-plugin ได้อย่างไร
Kalpesh Soni

7

ทางเลือกอื่น:

ในพ่อแม่ใช้:

<properties>
   <rootDir>${session.executionRootDirectory}</rootDir>
<properties>

ใน children poms คุณสามารถอ้างอิงตัวแปรนี้ได้

ข้อแม้หลัก: บังคับให้คุณดำเนินการคำสั่งจากไดเร็กทอรีหลัก pom เสมอ จากนั้นหากคุณต้องการเรียกใช้คำสั่ง (ตัวอย่างการทดสอบ) สำหรับโมดูลเฉพาะบางโมดูลให้ใช้ไวยากรณ์นี้:

การทดสอบ mvn - โครงการ

การกำหนดค่าของ surefire เพื่อกำหนดพารามิเตอร์ตัวแปร "path_to_test_data" อาจเป็น:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>${surefire.plugin.version}</version>
    <configuration>
        <systemPropertyVariables>
            <path_to_test_data>${rootDir}/../testdata</path_to_test_data>
        </systemPropertyVariables>
    </configuration>
</plugin>

5

โปรไฟล์เล็ก ๆ ต่อไปนี้เหมาะสำหรับฉัน ฉันต้องการการกำหนดค่าดังกล่าวสำหรับ CheckStyle ซึ่งฉันใส่ไว้ในconfigไดเร็กทอรีในรูทของโปรเจ็กต์ดังนั้นฉันจึงสามารถเรียกใช้จากโมดูลหลักและจากโมดูลย่อย

<profile>
    <id>root-dir</id>
    <activation>
        <file>
            <exists>${project.basedir}/../../config/checkstyle.xml</exists>
        </file>
    </activation>
    <properties>
        <project.config.path>${project.basedir}/../config</project.config.path>
    </properties>
</profile>

มันจะไม่ทำงานสำหรับโมดูลที่ซ้อนกัน แต่ฉันแน่ใจว่ามันสามารถแก้ไขได้สำหรับการที่ใช้โปรไฟล์ที่มีหลายที่แตกต่างกันexistsของ (ฉันไม่รู้ว่าทำไมจึงควรมี "../ .. " ในแท็กการยืนยันและมีเพียง ".. " ในคุณสมบัติการลบล้างเท่านั้น แต่ใช้ได้เฉพาะในลักษณะนั้นเท่านั้น)


ฉันไม่รู้ว่าทำไมถึงได้ผล (.. /) แต่นี่ดูเหมือนวิธีแก้ปัญหาที่สะอาดที่สุด (ฉันก็มีปัญหากับการกำหนดค่า checkstyle.xml เหมือนกัน)
RockMeetHardplace

5

ในกรณีของฉันมันใช้งานได้ดังนี้:

...
<properties>
  <main_dir>${project.parent.relativePath}/..</main_dir>
</properties>
...

<plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <version>1.0-alpha-1</version>
        <executions>
          <execution>
            <phase>initialize</phase>
            <goals>
              <goal>read-project-properties</goal>
            </goals>
            <configuration>
              <files>
                 <file>${main_dir}/maven_custom.properties</file>
              </files>
            </configuration>
          </execution>
        </executions>
</plugin>

3

ฉันพบวิธีแก้ปัญหานี้แล้ว: ใช้ $ {parent.relativePath}

<parent>
    <artifactId>xxx</artifactId>
    <groupId>xxx</groupId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>..</relativePath>
</parent>
<build>
    <filters>
        <filter>${parent.relativePath}/src/main/filters/filter-${env}.properties</filter>
    </filters>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
        </resource>
    </resources>
</build>

2
สิ่งนี้อาจไม่ปลอดภัยเสมอไป $ {parent.relativePath} สามารถใส่ชื่อไฟล์เช่น "../pom.xml"
pimlottc

3

คุณอยู่ในโครงการ C โครงการ C เป็นโมดูลย่อยของ B และ B เป็นโมดูลย่อยของ A คุณพยายามเข้าถึงsrc/test/config/etcไดเร็กทอรีของโมดูล D จากโครงการ C D ยังเป็นโมดูลย่อยของ A นิพจน์ต่อไปนี้ทำให้สามารถรับเส้นทาง URI ได้:

-Dparameter=file:/${basedir}/../../D/src/test/config/etc

2
<plugins>
  <plugin>
    <groupId>org.codehaus.groovy.maven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.0</version>
    <executions>
      <execution>
        <phase>validate</phase>
        <goals>
          <goal>execute</goal>
        </goals>
        <configuration>
          <source>
            import java.io.File
            project.properties.parentdir = "${pom.basedir}"
            while (new File(new File(project.properties.parentdir).parent, 'pom.xml').exists()) {
                project.properties.parentdir = new File(project.properties.parentdir).parent
            }
          </source>
        </configuration>
      </execution>
    </executions>
  </plugin>
  <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>properties-maven-plugin</artifactId>
    <version>1.0-alpha-2</version>
    <executions>
      <execution>
        <phase>initialize</phase>
        <goals>
          <goal>read-project-properties</goal>
        </goals>
        <configuration>
          <files>
            <file>${parentdir}/build.properties</file>
          </files>
        </configuration>
      </execution>
    </executions>
  </plugin>
  ...

1

ในคำตอบสำหรับคำถามอื่นฉันได้แสดงให้เห็นว่า maven-properties-plugin สามารถขยายเพื่อใช้ตัวบอกคุณสมบัติภายนอกที่กำหนดไว้ในการอ้างอิง Maven ได้อย่างไร

คุณสามารถขยายความคิดนั้นให้มีหลาย ๆ ตัวบอก jar โดยแต่ละอันมีชื่อสภาพแวดล้อมเป็นส่วนหนึ่งของ artifactId โดยมี $ {env} .properties จากนั้นคุณสามารถใช้คุณสมบัติเพื่อเลือกไฟล์ jar และคุณสมบัติที่เหมาะสมตัวอย่างเช่น:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>properties-ext-maven-plugin</artifactId>
  <version>0.0.1</version>
  <executions>
    <execution>
      <id>read-properties</id>
      <phase>initialize</phase>
      <goals>
        <goal>read-project-properties</goal>
      </goals>
    </execution>
  </executions>                              
  <configuration>
    <filePaths>
      <!--assume the descriptor project has a file in the root of the jar -->
      <filePath>${env}.properties</filePath>
    </filePaths>
  </configuration> 
  <dependencies>
    <!-- reference the properties jar for the particular environment-->
    <dependency>
      <groupId>some.descriptor.group</groupId>
      <artifactId>env-${env}-descriptor</artifactId>
      <version>0.0.1</version>
    </dependency>
  </dependencies>
</plugin>

1

ฉันเพิ่งปรับปรุงสคริปต์ groovy จากด้านบนเพื่อเขียนคุณสมบัติในไฟล์คุณสมบัติหลักของ root:

import java.io.*;
String p = project.properties['env-properties-file']
File f = new File(p)
if (f.exists()) {
try{
FileWriter fstream = new FileWriter(f.getAbsolutePath())
BufferedWriter out = new BufferedWriter(fstream)
String propToSet = f.getAbsolutePath().substring(0, f.getAbsolutePath().lastIndexOf(File.separator))
if (File.separator != "/") {
propToSet = propToSet.replace(File.separator,File.separator+File.separator+File.separator)
}
out.write("jacoco.agent = " + propToSet + "/lib/jacocoagent.jar")
out.close()
}catch (Exception e){
}
}
String ret = "../"
while (!f.exists()) {
f = new File(ret + p)
ret+= "../"
}
project.properties['env-properties-file-by-groovy'] = f.getAbsolutePath()

0

ฉันคิดว่าถ้าคุณใช้รูปแบบส่วนขยายที่ใช้ในตัวอย่างสำหรับ findbugs plugin & multimodule คุณอาจสามารถตั้งค่าคุณสมบัติส่วนกลางที่เกี่ยวข้องกับพา ธ สัมบูรณ์ได้ มันใช้ด้านบน

ตัวอย่างสำหรับโมดูลหลายโมดูล

pom ระดับบนสุดมีโปรเจ็กต์ build-config ที่ไม่เกี่ยวข้องและแอพพาเรนต์สำหรับโมดูลของโปรเจ็กต์หลายโมดูล app-parent ใช้ส่วนขยายเพื่อเชื่อมโยงตัวเองกับโครงการ build-config และรับทรัพยากรจากมัน ใช้เพื่อนำไฟล์ config ทั่วไปไปยังโมดูล อาจเป็นท่อร้อยสายสำหรับคุณสมบัติเช่นกัน คุณสามารถเขียน dir ด้านบนไปยังไฟล์คุณสมบัติที่ build-config ใช้อยู่ (ดูเหมือนซับซ้อนเกินไป)

ปัญหาคือต้องเพิ่มระดับบนสุดใหม่ในโครงการหลายโมดูลเพื่อให้ทำงานได้ ฉันพยายามที่จะก้าวไปข้างหน้ากับโครงการ build-config ที่ไม่เกี่ยวข้องอย่างแท้จริง แต่มันก็ดูไม่ดีและดูเหมือนเปราะ


0

นี่เป็นการขยายคำตอบของ romaintaz ซึ่งยอดเยี่ยมในการแก้ปัญหาและยังชี้ให้เห็นอย่างชัดเจนถึงฟังก์ชันการทำงานที่ขาดหายไปของ maven ฉันเลือกปลั๊กอินรุ่นที่ใหม่กว่าและเพิ่มกรณีที่โครงการอาจมีความลึกมากกว่า 3 ระดับ

<pluginManagement>
  <plugins>
    ..
    <plugin>
      <groupId>org.codehaus.gmaven</groupId>
      <artifactId>groovy-maven-plugin</artifactId>
      <version>2.0</version>
    </plugin>
    ..
  </plugins>
</pluginManagement>

ฉันเลือกที่จะไม่ใช้คุณสมบัติเพื่อกำหนดชื่อไฟล์ โปรดทราบว่าหากไม่พบ build.properties สิ่งนี้จะหมุนตลอดไป ฉันเพิ่มการตรวจจับ. git dir แต่ไม่ต้องการให้การตอบสนองซับซ้อนมากเกินไปจึงไม่แสดงที่นี่

  <plugin>
      <groupId>org.codehaus.gmaven</groupId>
      <artifactId>groovy-maven-plugin</artifactId>
      <executions>
          <execution>
              <phase>validate</phase>
              <goals>
                  <goal>execute</goal>
              </goals>
              <configuration>
                 <source>
                    import java.io.File;
                    String p = "build.properties";
                    while(true) {
                      File f = new File(p); 
                      if(f.exists()) {
                        project.properties['project-properties-file'] = f.getAbsolutePath();
                        break;
                      }
                      else {
                        p = "../${p}";
                      }
                    }
                </source>
              </configuration>
          </execution>
      </executions>
  </plugin>

0

ฉันต้องการแก้ปัญหาที่คล้ายกันสำหรับพื้นที่เก็บข้อมูลในเครื่องที่วางไว้ในโครงการหลักของโครงการหลายโมดูล โดยพื้นฐานแล้วเส้นทางที่แท้จริงคือ${basedir}/ lib ในที่สุดฉันก็ตัดสินสิ่งนี้ในparent.pom:

<repository>
    <id>local-maven-repo</id>
    <url>file:///${basedir}/${project.parent.relativePath}/lib</url>
</repository>

นั่นbasedirแสดงให้เห็นถึงโมดูลโลคัลปัจจุบันเสมอไม่มีทางที่จะไปยังโปรเจ็กต์ "ต้นแบบ" ได้ (ความอัปยศของ Maven) โมดูลย่อยบางส่วนของฉันลึกกว่าหนึ่ง dir บางส่วนลึกกว่าสอง dirs แต่ทั้งหมดเป็นโมดูลย่อยโดยตรงของพาเรนต์ที่กำหนด URL ของ repo

ดังนั้นจึงไม่สามารถแก้ปัญหาได้โดยทั่วไป คุณสามารถรวมเข้ากับคำตอบที่ยอมรับของ Clay และกำหนดคุณสมบัติอื่น ๆ ได้เสมอ - ใช้งานได้ดีและจำเป็นต้องกำหนดใหม่เฉพาะในกรณีที่ค่าจากparent.pomไม่ดีพอ หรือคุณอาจแค่กำหนดค่าปลั๊กอินใหม่ซึ่งคุณทำได้เฉพาะในส่วนของ POM เท่านั้น (พ่อแม่ของโมดูลย่อยอื่น ๆ ) ค่าที่แยกออกมาเป็นคุณสมบัติน่าจะดีกว่าหากคุณต้องการใช้ในสถานที่อื่น ๆ โดยเฉพาะอย่างยิ่งเมื่อไม่มีการเปลี่ยนแปลงการกำหนดค่าปลั๊กอิน

การใช้basedirค่าเป็นส่วนสำคัญที่นี่เนื่องจาก URL file://${project.parent.relativePath}/libไม่ต้องการทำเคล็ดลับ (ฉันลบหนึ่งสแลชเพื่อให้สัมพันธ์กัน) การใช้คุณสมบัติที่ให้เส้นทางสัมบูรณ์ที่ดีแก่ฉันและจากนั้นไปสัมพันธ์กับมันเป็นสิ่งจำเป็น

เมื่อเส้นทางไม่ URL / URI basedirมันอาจจะไม่ได้เป็นปัญหาเช่นการลดลง


0

ฉันเข้าถึง dir ด้านบนโดยใช้ $ {basedir} .. \ src \


1
ใช่ แต่ไม่ใช่ สำหรับsub-module1มันจะชี้ไปที่ไดเร็กทอรีของmodule2ไม่ใช่ไฟล์main-project.
Romain Linsolas

-1

คุณลอง../../env_${env}.propertiesหรือยัง?

โดยปกติเราจะทำสิ่งต่อไปนี้เมื่อ module2 อยู่ในระดับเดียวกับโมดูลย่อย

<modules>
    <module>../sub-module1</module>
    <module>../sub-module2</module>
    <module>../sub-module3</module>
</modules>

ฉันคิดว่า ../ .. จะช่วยให้คุณกระโดดขึ้นสองระดับ หากไม่เป็นเช่นนั้นคุณอาจต้องการติดต่อผู้เขียนปลั๊กอินและดูว่านี่เป็นปัญหาที่ทราบหรือไม่


ถ้าฉันใส่ ../../env.props ใน pom.xml หลักฉันจะได้รับข้อผิดพลาดเมื่อ Maven2 พยายามสร้างปอมหลักและ moduleX ทั้งหมด ในความเป็นจริงการกำหนดค่านี้จะใช้ได้กับโมดูลย่อยทั้งหมดเท่านั้น ...
Romain Linsolas
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.