Maven2 गुण जो मूल निर्देशिका को इंगित करता है

Question

मेरे पास एक मल्टी-मॉड्यूल प्रोजेक्ट है, जैसे यह:

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>, तो अभिभावक स्तर पर, या किसी भी उप-मॉड्यूल स्तर पर एक त्रुटि उठाई जाएगी ...

Comments

बस उपयोग${maven.multiModuleProjectDirectory}

— qoomon

Answer 1

मुख्य परियोजना निर्देशिका खोजने के लिए प्रत्येक पोम में एक संपत्ति सेट करने का प्रयास करें।

जनक में:

<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>

Comments

क्या इन पूर्व-सेट गुणों को हटा दिया गया था? ${parent.basedir}अब 3.0.4 में कुछ भी नहीं

— बताता

हाँ, यह काम नहीं करता है। $ {project.parent.basedir} शून्य का मूल्यांकन करता है।

— Jared

मुझे सफलता मिली है, ${project.basedir}/..लेकिन यह वास्तव में केवल मल्टी-मॉड्यूल परियोजनाओं में काम करता है जो एक सख्त निर्देशिका पदानुक्रम में हैं।

— जोनाथन

आह। अविश्वसनीय, कि मावेन इसे इतना कठिन बनाता है।

— स्टीफन हैबरल

ऊपर जोनाथन की तरह मुझे भी रिश्तेदार रास्तों का उपयोग करना है, लेकिन file.separatorइस तरह से चर का उपयोग करना सबसे अच्छा है<main.basedir>${project.basedir}${file.separator}..</main.basedir>

— एन्वेल्ड

Answer 2

कम से कम वर्तमान मावेन संस्करण (3.6.0) में आप इसका उपयोग कर सकते हैं ${maven.multiModuleProjectDirectory}

Comments

इस पर डॉक्टर को खोजने की कोशिश कर रहा है और ऐसा लगता है कि यह एक आंतरिक उपयोग के रूप में इरादा है, भविष्य के MNG-6589

— ग्रेग डोमजन

इसका उपयोग कैसे करें? -1

— hey_you

यह एक संपत्ति है, आप इसका उपयोग कर सकते हैं जैसा आप दूसरों के साथ करते हैं।

— क्यूमॉन

मुझे यकीन नहीं है कि हमें इस उत्तर का उपयोग करना चाहिए। इस टिकट के अनुसार यह आंतरिक है और किसी भी समय जा सकता है। इसीलिए यह कहीं भी प्रलेखित नहीं है। फिर भी कोई साफ समाधान नहीं

— २०:५०

Answer 3

निर्देशिका-मावेन-प्लगइन का उपयोग निर्देशिका-लक्ष्य के साथ करें ।

अन्य सुझावों के विपरीत:

• यह समाधान मल्टी-मॉड्यूल परियोजनाओं के लिए काम करता है।
• यह काम करता है कि आप पूरी परियोजना का निर्माण करते हैं या एक उप-मॉड्यूल।
• यह काम करता है कि क्या आप रूट फ़ोल्डर या उप-मॉड्यूल से मावेन चलाते हैं।
• प्रत्येक उप-मॉड्यूल में एक रिश्तेदार पथ संपत्ति सेट करने की कोई आवश्यकता नहीं है!

प्लगइन आपको प्रोजेक्ट के किसी भी मॉड्यूल के निरपेक्ष-पथ पर अपनी पसंद की संपत्ति सेट करने देता है। मेरे मामले में मैंने इसे रूट मॉड्यूल पर सेट किया है ... मेरी परियोजना में रूट 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} में हमेशा प्रोजेक्ट रूट मॉड्यूल का पथ होता है। और हां, आप किसी भी मॉड्यूल को संपत्ति सेट कर सकते हैं, न कि केवल रूट ...

Comments

चरण के लिए "परीक्षण" मत डालो। मुझे कई तरह की समस्याएं हुईं। जैसा कि ऊपर दिखाया गया है महान काम करता है।

— इलेक्ट्रॉनिकब्लाक्समैथ

Answer 4

मुझे अपनी समस्या को हल करने के लिए एक समाधान मिला है: मैं ग्रूवी मावेन प्लगइन का उपयोग करके गुणों की फाइलों को खोजता हूं।

जैसा कि मेरे गुण फ़ाइल वर्तमान निर्देशिका में आवश्यक है, ../ या .. में .., मैंने एक छोटा ग्रूवी कोड लिखा है जो इन तीन फ़ोल्डरों की जांच करता है।

यहाँ मेरे 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>

यह काम कर रहा है, लेकिन मुझे यह वास्तव में पसंद नहीं है।

इसलिए, यदि आपके पास एक बेहतर समाधान है, तो पोस्ट करने में संकोच न करें!

Answer 5

तो जैसा कि मैंने देखा कि समस्या यह है कि आप मावेन में एक मूल निर्देशिका के लिए पूर्ण पथ प्राप्त नहीं कर सकते हैं।

<rant> मैंने सुना है कि यह एक विरोधी पैटर्न के रूप में बात की है , लेकिन हर विरोधी पैटर्न के लिए वास्तविक, वैध उपयोग का मामला है, और मैं मावेन से बीमार हूं, यह बताकर कि मैं केवल उनके पैटर्न का पालन कर सकता हूं। < शेख़ी>

इसलिए मेरे आस-पास का काम एंटीरन का उपयोग करना था। बच्चे 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}किसी भी अन्य प्लगइन्स आदि में उपयोग कर सकते हैं , मुझे यह पता लगाने में थोड़ा समय लगा, इसलिए आशा है कि यह किसी और की मदद करता है।

Comments

मैं इसे मावेन-अचूक-प्लगइन पर कैसे पास करूं?

— कल्पेश सोनी

Answer 6

एक अन्य विकल्प:

मूल पोम में, उपयोग करें:

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

बच्चों के पोम्स में, आप इस चर का संदर्भ दे सकते हैं।

मुख्य चेतावनी: यह आपको हमेशा मुख्य पैरेंट पोम निर्देशिका से कमांड निष्पादित करने के लिए मजबूर करता है। फिर यदि आप केवल कुछ विशिष्ट मॉड्यूल के लिए कमांड (उदाहरण के लिए परीक्षण) चलाना चाहते हैं, तो इस सिंटैक्स का उपयोग करें:

mvn परीक्षण - विशेषण

एक "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>

Answer 7

निम्नलिखित छोटी प्रोफ़ाइल ने मेरे लिए काम किया। मुझे 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। (मुझे नहीं पता है कि सत्यापन टैग में "../ .." क्यों होना चाहिए और केवल ".." ओवरराइड संपत्ति में है, लेकिन यह केवल उसी तरीके से काम करता है।)

Comments

मुझे नहीं पता कि यह क्यों काम करता है (अतिरिक्त ../) लेकिन यह सबसे साफ समाधान की तरह लगता है (मैं भी checkstyle.xml कॉन्फ़िगरेशन के साथ समस्या थी)

— RockMeetHardplace

Answer 8

मेरे मामले में यह इस तरह काम करता है:

...
<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>

Answer 9

मुझे इस समस्या को हल करने के लिए एक समाधान मिला है: $ {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>

Comments

यह हमेशा सुरक्षित नहीं हो सकता है; $ {parent.relativePath} में एक फ़ाइल नाम शामिल हो सकता है, जैसे "../pom.xml"

— pimlottc

Answer 10

आप प्रोजेक्ट C में हैं, प्रोजेक्ट C, B का सबमॉड्यूल है और B, A का सबमॉड्यूल है। आप src/test/config/etcप्रोजेक्ट C से मॉड्यूल D की डायरेक्टरी तक पहुंचने की कोशिश करते हैं । D भी A. का सबमॉड्यूल है। निम्न अभिव्यक्ति URI पथ को प्राप्त करने के लिए संभव बनाती है:

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

Answer 11

<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>
  ...

Answer 12

एक अन्य प्रश्न के उत्तर में मैंने दिखाया कि मावेन-गुण-प्लगइन को मावेन निर्भरता में परिभाषित बाहरी संपत्ति विवरणकों का उपयोग करने के लिए कैसे बढ़ाया जा सकता है।

आप उस विवरण का विस्तार कर सकते हैं जिसमें कई विवरणात्मक जार हों, जिनमें से प्रत्येक का नाम ArtIdI के भाग के रूप में हो, जिसमें $ {env} .properties हो। फिर आप उदाहरण के लिए उपयुक्त जार और प्रॉपर्टीज़ फ़ाइल का चयन करने के लिए संपत्ति का उपयोग कर सकते हैं:

<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>

Answer 13

मैं बस मूल अभिभावक संपत्ति फ़ाइल में संपत्ति लिखने के लिए ऊपर से ग्रूवी स्क्रिप्ट में सुधार करता हूं:

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()

Answer 14

मुझे लगता है कि यदि आप फाइंडबग्स प्लगइन और मल्टीमॉड्यूल के लिए उदाहरण में उपयोग किए गए एक्सटेंशन पैटर्न का उपयोग करते हैं तो आप पूर्ण पथ से संबंधित वैश्विक गुणों को सेट करने में सक्षम हो सकते हैं। यह एक शीर्ष का उपयोग करता है

मल्टी मॉड्यूल के लिए उदाहरण

शीर्ष स्तर के पोम में एक असंबंधित बिल्ड-कॉन्फिग प्रोजेक्ट और मल्टीमॉडल प्रोजेक्ट के मॉड्यूल के लिए एक ऐप-पैरेंट है। ऐप-पैरेंट बिल्ड-कॉन्फिगरेशन प्रोजेक्ट से खुद को जोड़ने और उससे संसाधन प्राप्त करने के लिए एक्सटेंशन का उपयोग करता है। यह मॉड्यूल के लिए सामान्य विन्यास फाइल ले जाने के लिए प्रयोग किया जाता है। यह गुणों के लिए एक नाली भी हो सकता है। आप बिल्ड-कॉन्फ़िगरेशन द्वारा उपभोग की गई संपत्ति फ़ाइल में शीर्ष dir लिख सकते हैं। (यह बहुत जटिल लगता है)

समस्या यह है कि इस काम को करने के लिए मल्टी-मॉड्यूल प्रोजेक्ट में एक नया शीर्ष स्तर जोड़ा जाना चाहिए। मैंने वास्तव में असंबंधित बिल्ड-कॉन्फिगरेशन प्रोजेक्ट के साथ कदम रखने की कोशिश की, लेकिन यह हास्यास्पद था और भंगुर लग रहा था।

Answer 15

यह रोमेंटस के उत्तर का विस्तार करता है, जो कि भयानक है जो समस्या को हल करता है और मावेन की लापता कार्यक्षमता को भी स्पष्ट रूप से इंगित करता है। मैंने प्लगइन के एक बाद के संस्करण को उठाया, और उस मामले को जोड़ा जहां परियोजना 3 स्तर से अधिक गहरी हो सकती है।

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

मैंने फ़ाइलनाम को परिभाषित करने के लिए एक संपत्ति का उपयोग नहीं करने के लिए चुना। ध्यान दें कि अगर build.properties नहीं मिली है तो यह हमेशा के लिए स्पिन हो जाएगा। मैंने एक .it 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>

Answer 16

मुझे मल्टी-मॉड्यूल प्रोजेक्ट के मुख्य प्रोजेक्ट में स्थानीय रिपॉजिटरी के लिए इसी तरह की समस्या को हल करने की आवश्यकता थी। अनिवार्य रूप से वास्तविक मार्ग ${basedir}/ दायित्व था । अंत में मैं अपने में इस पर बस गया parent.pom:

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

वह basedirहमेशा वर्तमान स्थानीय मॉड्यूल को दिखाता है, "मास्टर" प्रोजेक्ट (मेवेन की शर्म) के लिए रास्ता पाने का कोई रास्ता नहीं है। मेरे कुछ सबमॉड्यूल्स एक डीर डीप हैं, कुछ दो डीआरएस गहरे हैं, लेकिन ये सभी रेपो URL को परिभाषित करने वाले पेरेंट के सीधे सबमॉडल्स हैं ।

तो यह सामान्य रूप से समस्या का समाधान नहीं करता है। आप इसे हमेशा क्ले के स्वीकृत उत्तर के साथ जोड़ सकते हैं और कुछ अन्य संपत्ति को परिभाषित कर सकते हैं - ठीक काम करता है और केवल उन मामलों के लिए फिर से परिभाषित करने की आवश्यकता होती है जहां से मूल्य parent.pomकाफी अच्छा नहीं है। या आप बस प्लगइन को फिर से कॉन्फ़िगर कर सकते हैं - जो आप केवल पीओएम कलाकृतियों (अन्य उप-मॉड्यूल के माता-पिता) में करते हैं। संपत्ति में निकाला गया मूल्य शायद बेहतर है यदि आपको अधिक स्थानों पर इसकी आवश्यकता होती है, खासकर जब प्लगइन कॉन्फ़िगरेशन में कुछ भी नहीं बदलता है।

का उपयोग करते हुए basedirमूल्य में यहाँ आवश्यक हिस्सा था, क्योंकि URLfile://${project.parent.relativePath}/lib चाल नहीं करना चाहता था (मैंने इसे रिश्तेदार बनाने के लिए एक स्लैश हटा दिया)। संपत्ति का उपयोग करना जो मुझे अच्छा निरपेक्ष मार्ग देता है और फिर उससे संबंधित होना आवश्यक था।

जब पथ URL / URI नहीं है, तो संभवतः इसे गिराने के लिए ऐसी कोई समस्या नहीं है basedir।

Answer 17

मैंने $ {बेस्ड} .. \ _ src \

Comments

हां लेकिन नहीं। इसके लिए sub-module1, यह निर्देशिका की ओर इंगित करेगा module2, न कि main-project।

— रोमेन लिंसोलास

Answer 18

क्या आपने कोशिश की ../../env_${env}.properties?

आमतौर पर हम निम्नलिखित करते हैं जब मॉड्यूल 2 उप-मॉड्यूल के समान स्तर पर होता है

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

मुझे लगता है कि ../ .. आप दो स्तरों को कूदने देंगे। यदि नहीं, तो आप लेखकों में प्लग से संपर्क कर सकते हैं और देख सकते हैं कि क्या यह एक ज्ञात मुद्दा है।

Comments

अगर मैं मुख्य pom.xml में ../../env.props डालता हूं, तो मुझे एक त्रुटि मिलेगी जब Maven2 मुख्य पोम, और सभी मॉड्यूलएक्स बनाने की कोशिश करेगा। यह विन्यास वास्तव में सभी उप-मॉड्यूलों के लिए ही काम करेगा ...

— रोमेन लिंसोलस