Maven Compiler Plugin
  1. Maven Compiler Plugin
  2. MCOMPILER-62

Allow multiple options to be passed to compiler for options not supported by the compiler mojo

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Auto Closed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Maven version: 2.0.7

      Description

      Look at the mail thread in maven user group:
      http://www.nabble.com/Not-able-to-pass-multiple-arguments-to-javac-tf4857909s177.html

      User may have to pass options to the underlying compiler that are not yet supported by the mojo. Current implementation of the maven-compiler-plugin allows user to specify only one option. Neither of the following techniques work:
      <configuration>
      <compilerArgument>-proc:none</compilerArgument>
      <compilerArgument>-implicit</compilerArgument>
      </configuration>

      or

      <configuration>
      <compilerArgument>-proc:none -impicit</compilerArgument>
      </configuration>

      In the first approach, only one of the compilerArgument is considered, in the second approach since maven quotes the argument, it ends up as a single argument to javac and hence becomes an invalid option.

      The best suggestion is to allow multiple compilerArgument – may be something like:
      <compilerArguments>
      <compilerArgument/>
      <compilerArgument/>
      </compilerArguments>

      1. MCOMPILER-62.patch
        0.9 kB
        Igor Vaynberg
      2. MCOMPILER-62-2.3.2.patch
        0.8 kB
        Artem Melentyev
      3. MCOMPILER-62-2.3.2.patch
        0.9 kB
        Artem Melentyev

        Issue Links

          Activity

          Hide
          Nick Stolwijk added a comment -

          To be more precise, the Plexus Compiler and more specific, the Plexus CommandLine and Shell classes quotes each argument. Maybe also a suggestion for the Maven debug statement, which ommits these quotes. (It creates an own version of the commandline and output it) Show the real arguments given to javac.

          I can try to create a patch for the

          <compilerArguments>
          <compilerArgument/>
          <compilerArgument/>
          </compilerArguments>

          solution. Is this the best solution?

          Show
          Nick Stolwijk added a comment - To be more precise, the Plexus Compiler and more specific, the Plexus CommandLine and Shell classes quotes each argument. Maybe also a suggestion for the Maven debug statement, which ommits these quotes. (It creates an own version of the commandline and output it) Show the real arguments given to javac. I can try to create a patch for the <compilerArguments> <compilerArgument/> <compilerArgument/> </compilerArguments> solution. Is this the best solution?
          Hide
          Sahoo added a comment -

          I am not the right person to comment what is the best solution, but another option to pass multiple arguments could be to just allow multiple compilerArgument without introducing compilerARguments, i.e.,
          <configuration>
          <compilerArgument>-foo</compilerArgument>
          <compilerArgument>-bar</compilerArgument>
          </compilerArgument>

          I am hoping maven-compiler-plugin developers will make the right call.

          Show
          Sahoo added a comment - I am not the right person to comment what is the best solution, but another option to pass multiple arguments could be to just allow multiple compilerArgument without introducing compilerARguments, i.e., <configuration> <compilerArgument>-foo</compilerArgument> <compilerArgument>-bar</compilerArgument> </compilerArgument> I am hoping maven-compiler-plugin developers will make the right call.
          Hide
          Nick Stolwijk added a comment -

          Then you'll get something like this:

          <configuration>
          <compilerArguments>
          <verbose />
          <bootclasspath>$

          {java.home}

          \lib\rt.jar</bootclasspath>
          </compilerArguments>
          <compilerArgument>-proc:none</compilerArgument>
          <compilerArgument>-implicit</compilerArgument>
          </configuration>

          In my opinion it is easier to read when there is a collection element around it.

          Show
          Nick Stolwijk added a comment - Then you'll get something like this: <configuration> <compilerArguments> <verbose /> <bootclasspath>$ {java.home} \lib\rt.jar</bootclasspath> </compilerArguments> <compilerArgument>-proc:none</compilerArgument> <compilerArgument>-implicit</compilerArgument> </configuration> In my opinion it is easier to read when there is a collection element around it.
          Hide
          Igor Vaynberg added a comment - - edited

          a patch for the <compilerArgument> value not working propery. currently the entire value is used as a simple parameter, i think all that needs to happen is that the value needs to be splint on whitespace and each part added as a separate argument. this is what the patch does.

          a more robust version may handle <cr> <lf> just in case.

          if someone asks why not simply use <compilerArguments> tag, the reason is simple. currently the arguments tag works like this:

          <compilerArguments><a>b</b><c/></compilerArguments>

          becomes

          javac a b c

          but it is not uncommon to have parameters with an equal sign, such as -Acom.mycom.myprocessor.param=value, there types of params cannot be modelled in compilerArguments currently because <a=b/> is not valid xml. maybe support should be added for this usecase if values start with a "=" so that

          <Acom.mycom.myprocessor.param>=value</..> will be properly handled as a single param instead of being split into two.

          Show
          Igor Vaynberg added a comment - - edited a patch for the <compilerArgument> value not working propery. currently the entire value is used as a simple parameter, i think all that needs to happen is that the value needs to be splint on whitespace and each part added as a separate argument. this is what the patch does. a more robust version may handle <cr> <lf> just in case. if someone asks why not simply use <compilerArguments> tag, the reason is simple. currently the arguments tag works like this: <compilerArguments><a>b</b><c/></compilerArguments> becomes javac a b c but it is not uncommon to have parameters with an equal sign, such as -Acom.mycom.myprocessor.param=value, there types of params cannot be modelled in compilerArguments currently because <a=b/> is not valid xml. maybe support should be added for this usecase if values start with a "=" so that <Acom.mycom.myprocessor.param>=value</..> will be properly handled as a single param instead of being split into two.
          Hide
          Nick Fortescue added a comment -

          Is there any chance this patch could be incorporated? It seems to solve all the issues with a nice design, and has been around for 3 years. It also resolves the problems with MCOMPILER-135. I can't see any downside to it. It won't break any existing pom files.

          Show
          Nick Fortescue added a comment - Is there any chance this patch could be incorporated? It seems to solve all the issues with a nice design, and has been around for 3 years. It also resolves the problems with MCOMPILER-135 . I can't see any downside to it. It won't break any existing pom files.
          Hide
          Artem Melentyev added a comment -

          here is updated MCOMPILER-62.patch for 2.3.2 version.
          Also if you tired to wait, you can use my repo:

            <pluginRepositories>
              <pluginRepository>
                <id>am</id>
                <url>https://bitbucket.org/amelentev/mvnrepo/raw/tip/</url>
              </pluginRepository>
            </pluginRepositories>
          

          And use <version>2.3.2-fix62</version> of maven-compiler-plugin

          Show
          Artem Melentyev added a comment - here is updated MCOMPILER-62 .patch for 2.3.2 version. Also if you tired to wait, you can use my repo: <pluginRepositories> <pluginRepository> <id>am</id> <url>https: //bitbucket.org/amelentev/mvnrepo/raw/tip/</url> </pluginRepository> </pluginRepositories> And use <version>2.3.2-fix62</version> of maven-compiler-plugin
          Hide
          Artem Melentyev added a comment -

          update patch to use StringUtils.split. support all whitespace chars.

          Show
          Artem Melentyev added a comment - update patch to use StringUtils.split. support all whitespace chars.
          Hide
          Jesse Glick added a comment -

          "It won't break any existing pom files." - if you intentionally had <compilerArgument>-Akey=value with spaces</> that would be broken, if I understand the intent of the patch correctly.

          Show
          Jesse Glick added a comment - "It won't break any existing pom files." - if you intentionally had <compilerArgument>-Akey=value with spaces</> that would be broken, if I understand the intent of the patch correctly.
          Hide
          Stephane Nicoll added a comment -

          there's a thread that is referring to this issue regarding annotation processors but there is a separate option for that since 2.2

          <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
              <annotationProcessors>
                <annotationProcessor>
                  org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor
                </annotationProcessor>
              </annotationProcessors>
            </configuration>
          </plugin>
          
          Show
          Stephane Nicoll added a comment - there's a thread that is referring to this issue regarding annotation processors but there is a separate option for that since 2.2 <plugin> <artifactId> maven-compiler-plugin </artifactId> <configuration> <annotationProcessors> <annotationProcessor> org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor </annotationProcessor> </annotationProcessors> </configuration> </plugin>
          Hide
          Christian Semrau added a comment -

          I just noted that the documentation at
          http://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-compiler-arguments.html
          is currently telling me that giving multiple arguments as the value of a <compilerArgument> element is valid, which is not true.

          "For such arguments, the Compiler Plugin's compilerArguments will be used." Note the plural, which is not used in the following code snippet!

          pass-compiler-arguments.html
          ...
                <plugin>
                  <groupId>org.apache.maven.plugins</groupId>
                  <artifactId>maven-compiler-plugin</artifactId>
                  <version>2.3.2</version>
                  <configuration>
                    <compilerArgument>-verbose -bootclasspath ${java.home}\lib\rt.jar</compilerArgument>
                  </configuration>
                </plugin>
          
          Show
          Christian Semrau added a comment - I just noted that the documentation at http://maven.apache.org/plugins/maven-compiler-plugin/examples/pass-compiler-arguments.html is currently telling me that giving multiple arguments as the value of a <compilerArgument> element is valid, which is not true. "For such arguments, the Compiler Plugin's compilerArguments will be used." Note the plural, which is not used in the following code snippet! pass-compiler-arguments.html ... <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <compilerArgument>-verbose -bootclasspath ${java.home}\lib\rt.jar</compilerArgument> </configuration> </plugin>
          Hide
          Michael Osipov added a comment -

          This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.

          Show
          Michael Osipov added a comment - This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.

            People

            • Assignee:
              Unassigned
              Reporter:
              Sahoo
            • Votes:
              17 Vote for this issue
              Watchers:
              18 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development