[jira] Created: (MCOMPILER-62) Allow multiple options to be passed to compiler for options not supported by the compiler mojo

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

                 Key: MCOMPILER-62
                 URL: http://jira.codehaus.org/browse/MCOMPILER-62
             Project: Maven 2.x Compiler Plugin
          Issue Type: Improvement
         Environment: Maven version: 2.0.7
            Reporter: Sanjeeb Sahoo


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>  

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

    [ http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115043 ]

Nick Stolwijk commented on MCOMPILER-62:
----------------------------------------

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?

> Allow multiple options to be passed to compiler for options not supported by the compiler mojo
> ----------------------------------------------------------------------------------------------
>
>                 Key: MCOMPILER-62
>                 URL: http://jira.codehaus.org/browse/MCOMPILER-62
>             Project: Maven 2.x Compiler Plugin
>          Issue Type: Improvement
>         Environment: Maven version: 2.0.7
>            Reporter: Sanjeeb Sahoo
>
> 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>  

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

    [ http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115143 ]

Sanjeeb Sahoo commented on MCOMPILER-62:
----------------------------------------

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.

> Allow multiple options to be passed to compiler for options not supported by the compiler mojo
> ----------------------------------------------------------------------------------------------
>
>                 Key: MCOMPILER-62
>                 URL: http://jira.codehaus.org/browse/MCOMPILER-62
>             Project: Maven 2.x Compiler Plugin
>          Issue Type: Improvement
>         Environment: Maven version: 2.0.7
>            Reporter: Sanjeeb Sahoo
>
> 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>  

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

    [ http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115165 ]

Nick Stolwijk commented on MCOMPILER-62:
----------------------------------------

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.

> Allow multiple options to be passed to compiler for options not supported by the compiler mojo
> ----------------------------------------------------------------------------------------------
>
>                 Key: MCOMPILER-62
>                 URL: http://jira.codehaus.org/browse/MCOMPILER-62
>             Project: Maven 2.x Compiler Plugin
>          Issue Type: Improvement
>         Environment: Maven version: 2.0.7
>            Reporter: Sanjeeb Sahoo
>
> 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>  

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

     [ http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg updated MCOMPILER-62:
-----------------------------------

    Attachment: MCOMPILER-62.patch

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.

> Allow multiple options to be passed to compiler for options not supported by the compiler mojo
> ----------------------------------------------------------------------------------------------
>
>                 Key: MCOMPILER-62
>                 URL: http://jira.codehaus.org/browse/MCOMPILER-62
>             Project: Maven 2.x Compiler Plugin
>          Issue Type: Improvement
>         Environment: Maven version: 2.0.7
>            Reporter: Sanjeeb Sahoo
>         Attachments: MCOMPILER-62.patch
>
>
> 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>  

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

    [ http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197589#action_197589 ]

Igor Vaynberg edited comment on MCOMPILER-62 at 11/8/09 1:55 AM:
-----------------------------------------------------------------

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, maybe support should be added for values that start with a "=" so that

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

      was (Author: ivaynberg):
    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.
 

> Allow multiple options to be passed to compiler for options not supported by the compiler mojo
> ----------------------------------------------------------------------------------------------
>
>                 Key: MCOMPILER-62
>                 URL: http://jira.codehaus.org/browse/MCOMPILER-62
>             Project: Maven 2.x Compiler Plugin
>          Issue Type: Improvement
>         Environment: Maven version: 2.0.7
>            Reporter: Sanjeeb Sahoo
>         Attachments: MCOMPILER-62.patch
>
>
> 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>  

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

    [ http://jira.codehaus.org/browse/MCOMPILER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=197589#action_197589 ]

Igor Vaynberg edited comment on MCOMPILER-62 at 11/8/09 2:19 AM:
-----------------------------------------------------------------

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.

      was (Author: ivaynberg):
    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, maybe support should be added for values that start with a "=" so that

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

> Allow multiple options to be passed to compiler for options not supported by the compiler mojo
> ----------------------------------------------------------------------------------------------
>
>                 Key: MCOMPILER-62
>                 URL: http://jira.codehaus.org/browse/MCOMPILER-62
>             Project: Maven 2.x Compiler Plugin
>          Issue Type: Improvement
>         Environment: Maven version: 2.0.7
>            Reporter: Sanjeeb Sahoo
>         Attachments: MCOMPILER-62.patch
>
>
> 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>  

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira