"-XjsInteropMode JS" support

[salk31]

Make playing with the new feature a lot easier.

Would this make sense?

Also, for future things, any sensible way to allow arbitrary arguments to GWTC?

I'm up for having a stab at the new parameter if it seems a sensible idea.

Sam

[tbroyer]

The more I think about it the more I think the plugin should only expose non-experimental arguments and have a way to pass arbitrary arguments for the experimental (or new) ones; like it's done in Buck, as suggested by Google.

[salk31]

That makes sense. Since such a core fix, rather than just more of the same, are you planning to do it? I'd like to but might take a while before I could work on it.

[tbroyer]

For backwards compatibility we just need to add an extra experimentalArguments property. I have no idea what type would be best, probably List<String>.

I'm afraid I won't have time to it myself though.

[salk31]

I'll have a go then and see what I can come up with.

[salk31]

Could I tempt you to extraGwtcArgs (coded in AbstractGwtShellMojo) to match extraJvmArgs?

The downside would be users being tempted to put things better handled by standard arguments but it makes it clear the args will go to GWTC?

My second choice would be experimentalGwtArgs

[tbroyer]

That makes me think: we need different properties for each goal, as you'll want different values for compile, run and run-codeserver (and you can't solve that for the last too with different <execution>s).

[salk31]

I see what you mean but sensible to have a "default" or baseline that goes across the goals?

This takes me out of my depth with Maven I'm afraid.

[salk31]

Some combination of executions and profiles might be enough for most people?

[tbroyer]

That would be misusing and abusing profiles IMO, and is not practical, but Maven doesn't really gives us much choices. We could use a String property which would be easier to use but would need to be parsed by the plugin. I don't have a strong opinion, Maven is broken by design and there's no ideal solution in this broken world.

[salk31]

Seems best to keep the problems at their source rather than inventing a new mechanism in the wrong place.

If you have the patience I'll have a first stab at a commit - trying to remember documentation, unit tests etc...

Maven can be pretty painful. Shame on the Java world but not has shameful as dates and logging ;)

[salk31]

Hmmm. Slowly catching up after looking at the code. Also if these are experimental options it wouldn't be surprising to need some fiddly combination of settings for compile, test, codeserver...

Could decide not to support dev mode so then reduces it to extraCompileArgs, extraTestArgs, extraCodeServerArgs? :(

Think that brings me back to the start with experimentalArguments or extraGwtArgs as a blunt instrument that should work for most cases?

[salk31]

I've got a working prototype with String extraGwtArgs...

Should I look into supporting -Xweird='white space'? At the moment I've just copy and pasted the code for splitting extraJvmArgs...

I need more time and energy to attempt an automated test.

[salk31]

Thomas, First attempt at the commit above. I'm still up for better ideas about parameter name(s).

Regarding just the code. Two smelly bits:

• I've copied and pasted the parsing bit. Maybe do something as suggested in http://stackoverflow.com/questions/3259143/split-a-string-containing-command-line-parameters-into-a-string-in-java at least for the new parameter? Or at least factor it out?
• I've smuggled the test into the compiler test. For good or bad GWTC considers an unknown -X as an error so I couldn't test with an invented parameter. Would you rather I did a completely new test?

Cheers

Sam