Issue Details (XML | Word | Printable)

Key: MCOMPILER-62
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Sanjeeb Sahoo
Votes: 6
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
Maven 2.x Compiler Plugin

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

Created: 26/Nov/07 08:29 PM   Updated: 08/Nov/09 02:19 AM
Return to search
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Text File MCOMPILER-62.patch (0.9 kB)

Environment: Maven version: 2.0.7


 Description  « Hide

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>



Nick Stolwijk added a comment - 27/Nov/07 10:23 AM

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?


Sanjeeb Sahoo added a comment - 27/Nov/07 11:55 PM

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.


Nick Stolwijk added a comment - 28/Nov/07 01:54 AM

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.


Igor Vaynberg added a comment - 08/Nov/09 01:14 AM - 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.