Maven 2.x Compiler Plugin

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

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Maven version: 2.0.7
  • Number of attachments :
    3

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>

Attachments

  1. Text File
    MCOMPILER-62.patch
    08/Nov/09 1:14 AM
    0.9 kB
    Igor Vaynberg
  2. Text File
    MCOMPILER-62-2.3.2.patch
    07/Jan/11 11:29 AM
    0.8 kB
    Artem Melentyev
  3. Text File
    MCOMPILER-62-2.3.2.patch
    07/Jan/11 10:34 AM
    0.9 kB
    Artem Melentyev

Issue Links

This issue is related to:
MCOMPILER-135 Passing multiple parameters to Java 6 annotation processors with javac does not work Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
Sanjeeb 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
Sanjeeb 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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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>

People

Vote (17)
Watch (16)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.