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: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • 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

          Sahoo created issue -
          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.
          Igor Vaynberg made changes -
          Field Original Value New Value
          Attachment MCOMPILER-62.patch [ 45691 ]
          Jesse Glick made changes -
          Link This issue is related to MCOMPILER-135 [ MCOMPILER-135 ]
          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
          Artem Melentyev made changes -
          Attachment MCOMPILER-62-2.3.2.patch [ 53040 ]
          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.
          Artem Melentyev made changes -
          Attachment MCOMPILER-62-2.3.2.patch [ 53043 ]
          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>
          Mark Thomas made changes -
          Project Import Sun Apr 05 09:20:51 UTC 2015 [ 1428225651644 ]
          Mark Thomas made changes -
          Workflow jira [ 12718578 ] Default workflow, editable Closed status [ 12749909 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 22:48:53 UTC 2015 [ 1428274133206 ]
          Mark Thomas made changes -
          Workflow jira [ 12956147 ] Default workflow, editable Closed status [ 12993196 ]

            People

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

              Dates

              • Created:
                Updated:

                Development