Maven2 property that indicates the parent directory

Question

I have a multi-modules project  like this one   main-project      module1      module2          sub-module1          sub-module2          sub-module3                  module3      module4            I need to define a set of properties  that are dependent of the environment on which I want to release my project  in Maven2  I will not use  lt properties gt  as there is lots of properties    Thus  I use the Properties Maven2 plugin   The properties files are located in the main-project  directory  How can I set the correct directory in the main pom xml  in order to specify to any children where to find the properties file    lt plugin gt       lt groupId gt org codehaus mojo lt  groupId gt       lt artifactId gt properties-maven-plugin lt  artifactId gt       lt version gt 1 0-alpha-1 lt  version gt       lt executions gt           lt execution gt               lt phase gt initialize lt  phase gt               lt goals gt                   lt goal gt read-project-properties lt  goal gt               lt  goals gt               lt configuration gt                   lt files gt                       lt file gt     env   env  properties lt  file gt                   lt  files gt               lt  configuration gt           lt  execution gt       lt  executions gt   lt  plugin gt    If I set only  lt file gt env   env  properties lt  file gt   then when Maven2 compiles the first module  it will not find the main-project env dev properties file  If I set  lt file gt    env   env  properties lt  file gt   then an error will be raised at the parent level  or at any sub-module level

User · Answer

This extends romaintaz s answer  which is awesome in that solves the problem and also clearly points out maven s missing functionality  I picked up a later version of the plugin  and added the case where the project could be more than 3 levels deep    lt pluginManagement gt     lt plugins gt              lt plugin gt         lt groupId gt org codehaus gmaven lt  groupId gt         lt artifactId gt groovy-maven-plugin lt  artifactId gt         lt version gt 2 0 lt  version gt       lt  plugin gt            lt  plugins gt   lt  pluginManagement gt    I elected not to use a property to define the filename  Note if the build properties is not found this will spin forever  I added a  git dir detection  but didn t want to over complicate the response so it s not shown here      lt plugin gt         lt groupId gt org codehaus gmaven lt  groupId gt         lt artifactId gt groovy-maven-plugin lt  artifactId gt         lt executions gt             lt execution gt                 lt phase gt validate lt  phase gt                 lt goals gt                     lt goal gt execute lt  goal gt                 lt  goals gt                 lt configuration gt                    lt source gt                      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                                                                   lt  source gt                 lt  configuration gt             lt  execution gt         lt  executions gt     lt  plugin gt

User · Answer

Did you try       env   env  properties    Normally we do the following when module2 is on the same level as the sub-modules   lt modules gt       lt module gt    sub-module1 lt  module gt       lt module gt    sub-module2 lt  module gt       lt module gt    sub-module3 lt  module gt   lt  modules gt    I would think the       would let you jump up two levels  If not  you might want to contact the plug in authors and see if this is a known issue

User · Answer

I ve found a solution to solve my problem  I search the properties files using the Groovy Maven plugin   As my properties file is necessarily in current directory  in     or in        I wrote a small Groovy code that checks these three folders   Here is the extract of my pom xml    lt  -- Use Groovy to search the location of the properties file  -- gt   lt plugin gt       lt groupId gt org codehaus groovy maven lt  groupId gt       lt artifactId gt gmaven-plugin lt  artifactId gt       lt version gt 1 0-rc-5 lt  version gt       lt executions gt           lt execution gt               lt phase gt validate lt  phase gt               lt goals gt                   lt goal gt execute lt  goal gt               lt  goals gt               lt configuration gt                   lt source gt                      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                 lt  source gt               lt  configuration gt           lt  execution gt       lt  executions gt   lt  plugin gt   lt  -- Now  I can load the properties file using the new  env-properties-file-by-groovy  property  -- gt   lt plugin gt       lt groupId gt org codehaus mojo lt  groupId gt       lt artifactId gt properties-maven-plugin lt  artifactId gt       lt version gt 1 0-alpha-1 lt  version gt       lt executions gt           lt execution gt               lt phase gt initialize lt  phase gt               lt goals gt                   lt goal gt read-project-properties lt  goal gt               lt  goals gt               lt configuration gt                   lt files gt                       lt file gt   env-properties-file-by-groovy  lt  file gt                   lt  files gt               lt  configuration gt           lt  execution gt       lt  executions gt   lt  plugin gt    This is working  but I don t really like it   So  if you have a better solution  do not hesitate to post

User · Answer

Another alternative   in the parent pom  use    lt properties gt      lt rootDir gt   session executionRootDirectory  lt  rootDir gt   lt properties gt    In the children poms  you can reference this variable   Main caveat  It forces you to always execute command from the main parent pom directory  Then if you want to run commands  test for example  only for some specific module  use this syntax   mvn test --projects   The configuration of surefire to parametize a  path to test data  variable may then be    lt plugin gt       lt groupId gt org apache maven plugins lt  groupId gt       lt artifactId gt maven-surefire-plugin lt  artifactId gt       lt version gt   surefire plugin version  lt  version gt       lt configuration gt           lt systemPropertyVariables gt               lt path to test data gt   rootDir     testdata lt  path to test data gt           lt  systemPropertyVariables gt       lt  configuration gt   lt  plugin gt

User · Answer

Use directory-maven-plugin with directory-of goal   Unlike other suggestions    This solution works for multi-module projects  It works whether you build the whole project or a sub-module  It works whether you run maven from the root folder or a sub-module  There s no need to set a relative path property in each and every sub-module    The plugin lets you set a property of your choice to the absolute-path of any of the project s modules  In my case I set it to the root module    In my project root pom    lt plugin gt       lt groupId gt org commonjava maven plugins lt  groupId gt       lt artifactId gt directory-maven-plugin lt  artifactId gt       lt version gt 0 1 lt  version gt       lt executions gt           lt execution gt               lt id gt directories lt  id gt               lt goals gt                   lt goal gt directory-of lt  goal gt               lt  goals gt               lt phase gt initialize lt  phase gt               lt configuration gt                   lt property gt myproject basedir lt  property gt                   lt project gt                       lt groupId gt com my domain lt  groupId gt                       lt artifactId gt my-root-artifact lt  artifactId gt                   lt  project gt               lt  configuration gt           lt  execution gt       lt  executions gt   lt  plugin gt    From then on    myproject basedir  in any sub-module pom always has the path of the project root module  And of course  you can set the property to any module  not just the root

User · Answer

I think that if you use the extension pattern used in the example for findbugs plugin  amp  multimodule you may be able to set global properties related to absolute paths   It uses a top  example for multi module  The top level pom has an unrelated build-config project and a app-parent for the modules of the multimodule project   The app-parent uses extension to link itself to the build-config project and obtain resources from it    This is used to carry common config files to the modules   It may be a conduit for properties as well    You could write the top dir to a property file consumed by the build-config    it seems too complex   The problem is that a new top level must be added to the multi-module project to make this work   I tried to side step with a truly unrelated build-config project but it was kludgy and seemed brittle

User · Answer

I ve found a solution to solve this problem   use   parent relativePath    lt parent gt       lt artifactId gt xxx lt  artifactId gt       lt groupId gt xxx lt  groupId gt       lt version gt 1 0-SNAPSHOT lt  version gt       lt relativePath gt    lt  relativePath gt   lt  parent gt   lt build gt       lt filters gt           lt filter gt   parent relativePath  src main filters filter-  env  properties lt  filter gt       lt  filters gt       lt resources gt           lt resource gt               lt directory gt src main resources lt  directory gt               lt filtering gt true lt  filtering gt           lt  resource gt       lt  resources gt   lt  build gt

User · Answer

The following small profile worked for me  I needed such a configuration for CheckStyle  which I put into the config directory in the root of the project  so I can run it from the main module and from submodules    lt profile gt       lt id gt root-dir lt  id gt       lt activation gt           lt file gt               lt exists gt   project basedir        config checkstyle xml lt  exists gt           lt  file gt       lt  activation gt       lt properties gt           lt project config path gt   project basedir     config lt  project config path gt       lt  properties gt   lt  profile gt    It won t work for nested modules  but I m sure it can be modified for that using several profiles with different exists s   I have no idea  why there should be         in the verification tag and just      in the overriden property itself  but it works only in that way

User · Answer

I just improve the groovy script from above to write the property in the root parent properties file   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

User · Answer

I needed to solve similar problem for local repository placed in the main project of multi-module project  Essentially the real path was   basedir  lib  Finally I settled on this in my parent pom    lt repository gt       lt id gt local-maven-repo lt  id gt       lt url gt file      basedir    project parent relativePath  lib lt  url gt   lt  repository gt    That basedir always shows to current local module  there is no way to get path to  master  project  Maven s shame   Some of my submodules are one dir deeper  some are two dirs deeper  but all of them are direct submodules of the parent that defines the repo URL   So this does not resolve the problem in general  You may always combine it with Clay s accepted answer and define some other property - works fine and needs to be redefined only for cases where the value from parent pom is not good enough  Or you may just reconfigure the plugin - which you do only in POM artifacts  parents of other sub-modules   Value extracted into property is probably better if you need it on more places  especially when nothing in the plugin configuration changes   Using basedir in the value was the essential part here  because URL file     project parent relativePath  lib did not want to do the trick  I removed one slash to make it relative   Using property that gives me good absolute path and then going relative from it was necessary   When the path is not URL URI  it probably is not such a problem to drop basedir

User · Answer

Try setting a property in each pom to find the main project directory    In the parent     lt properties gt       lt main basedir gt   project basedir  lt  main basedir gt   lt  properties gt    In the children     lt properties gt       lt main basedir gt   project parent basedir  lt  main basedir gt   lt  properties gt    In the grandchildren     lt properties gt       lt main basedir gt   project parent parent basedir  lt  main basedir gt   lt  properties gt

User · Answer

At least in current maven version  3 6 0  you can make use of   maven multiModuleProjectDirectory

User · Answer

You are in project C  project C is submodule of B and B is submodule of A  You try to reach module D s src test config etc directory from project C  D is also submodule of A  The following expression makes this possible to get the URI path   -Dparameter file    basedir        D src test config etc

User · Answer

In an answer to another question I showed how the maven-properties-plugin could be extended to use external property descriptors defined in Maven dependencies   You could extend that idea to have multiple descriptor jars  each with the environment name as part of the artifactId  containing a   env  properties  Then you can use the property to select the appropriate jar and properties file  for example    lt plugin gt     lt groupId gt org codehaus mojo lt  groupId gt     lt artifactId gt properties-ext-maven-plugin lt  artifactId gt     lt version gt 0 0 1 lt  version gt     lt executions gt       lt execution gt         lt id gt read-properties lt  id gt         lt phase gt initialize lt  phase gt         lt goals gt           lt goal gt read-project-properties lt  goal gt         lt  goals gt       lt  execution gt     lt  executions gt                                   lt configuration gt       lt filePaths gt         lt  --assume the descriptor project has a file in the root of the jar -- gt         lt filePath gt   env  properties lt  filePath gt       lt  filePaths gt     lt  configuration gt      lt dependencies gt       lt  -- reference the properties jar for the particular environment-- gt       lt dependency gt         lt groupId gt some descriptor group lt  groupId gt         lt artifactId gt env-  env -descriptor lt  artifactId gt         lt version gt 0 0 1 lt  version gt       lt  dependency gt     lt  dependencies gt   lt  plugin gt

User · Answer

I accessed the dir above using   basedir    src

User · Answer

In my case it works like this        lt properties gt     lt main dir gt   project parent relativePath     lt  main dir gt   lt  properties gt        lt plugin gt           lt groupId gt org codehaus mojo lt  groupId gt           lt artifactId gt properties-maven-plugin lt  artifactId gt           lt version gt 1 0-alpha-1 lt  version gt           lt executions gt             lt execution gt               lt phase gt initialize lt  phase gt               lt goals gt                 lt goal gt read-project-properties lt  goal gt               lt  goals gt               lt configuration gt                 lt files gt                    lt file gt   main dir  maven custom properties lt  file gt                 lt  files gt               lt  configuration gt             lt  execution gt           lt  executions gt   lt  plugin gt

User · Answer

So the problem as I see it is that you can t get the absolute path to a parent directory in maven    lt rant gt  I ve heard this talked about as an anti-pattern  but for every anti-pattern there is  real  legitimate use case for it  and I m sick of maven telling me I can only follow their patterns  lt  rant gt   So the work around I found was to use antrun   Try this in the child pom xml    lt plugin gt       lt groupId gt org apache maven plugins lt  groupId gt       lt artifactId gt maven-antrun-plugin lt  artifactId gt       lt version gt 1 7 lt  version gt       lt executions gt           lt execution gt               lt id gt getMainBaseDir lt  id gt               lt phase gt validate lt  phase gt               lt goals gt                   lt goal gt run lt  goal gt               lt  goals gt               lt configuration gt                   lt exportAntProperties gt true lt  exportAntProperties gt                   lt target gt                       lt  --Adjust the location below to your directory structure -- gt                       lt property name  main basedir  location          gt                       lt echo message  main basedir   main basedir    gt                   lt  target gt               lt  configuration gt           lt  execution gt       lt  executions gt   lt  plugin gt    If you run mvn verify you should see something like this   main        echo  main basedir C  src parent project dir name   You can then use   main basedir  in any of the other plugins  etc   Took me a while to figure this out  so hope it helps someone else

User · Answer

lt plugins gt     lt plugin gt       lt groupId gt org codehaus groovy maven lt  groupId gt       lt artifactId gt gmaven-plugin lt  artifactId gt       lt version gt 1 0 lt  version gt       lt executions gt         lt execution gt           lt phase gt validate lt  phase gt           lt goals gt             lt goal gt execute lt  goal gt           lt  goals gt           lt configuration gt             lt source gt              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                          lt  source gt           lt  configuration gt         lt  execution gt       lt  executions gt     lt  plugin gt     lt plugin gt       lt groupId gt org codehaus mojo lt  groupId gt       lt artifactId gt properties-maven-plugin lt  artifactId gt       lt version gt 1 0-alpha-2 lt  version gt       lt executions gt         lt execution gt           lt phase gt initialize lt  phase gt           lt goals gt             lt goal gt read-project-properties lt  goal gt           lt  goals gt           lt configuration gt             lt files gt               lt file gt   parentdir  build properties lt  file gt             lt  files gt           lt  configuration gt         lt  execution gt       lt  executions gt     lt  plugin gt

[maven-2] Maven2 property that indicates the parent directory

Examples related to maven-2

Examples related to properties