Support comments in jvm-opts file about sbt-extras

[paulp]

Amazingly this has never worked in the year since it was checked in! A resounding statement that untested projects are going to be big disappointments. Thankfully @yyuu did something about the tests and since the windows aren't so broken anymore I fixed and tested this in 73aba99 .

[gildegoma]

I'd like to clarify a few more things about this bug report:

This situation will also happen when building on Travis CI...

No, the version of sbt-extras (2fd0642) that currently runs on Travis CI is not (so) flawed as reported here. By default /etc/sbt/jvmopts is successfully loaded (skipping the two comments and the blank line mentioned above), as illustrated by these examples:

• https://travis-ci.org/scalaz/scalaz/jobs/19503327#L17-L40
• https://travis-ci.org/twitter/scalding/jobs/19358087#L24-L42

For an example see this failed Travis CI build triggered by this script.

In mohiva/play-silhouette@bd17777, Travis script was customized to run with a more recent version of sbt-extras (apparently b170cdd), which indeed is broken.

I didn't take time to identify the cause of the regression... But yeah, having automated tests/specs is the only way!

As still unexperienced shellscripter and moreover non-native english speaker, I am not certain to fully understand last part of 73aba99 commit comment:

, but lines with a non-initial # are options

@paulp Do you want to support non-initial # comments or not?
I ask because my original regexp-based implementation supported it...

PS: This is great that sbt-extras is now checked by travis :)

[paulp]

"I ask because my original regexp-based implementation supported it..."

Did it handle all the forms of quoting which might appear? The problem is if you want to pass a string containing a #, e.g. as part of a system property. Even if it did handle this - and it's really tricky with regexps - I find the feature unnecessary and prefer the implementation which doesn't take on baroque quoting issues.

[paulp]

@gildegoma Indeed try your runner with a .jvmopts of

-Dfoo.bar="my #string"

and you will see what I mean.

[gildegoma]

Sure, I understand :)

"I ask because my original regexp-based implementation supported it..."

You're right to correct me on this point. Sorry for writing this line too fast. I was not pretending my implementation was so robust, but I just wanted to be sure that we all agree to drop this feature.

And fixing this weakness is actually a good argument to update the sbt-extras version on Travis CI as well. I'll take care of this...

[paulp]

It wasn't exactly fixed until just now, but as of 4f44188 I believe it is.

[gildegoma]

@paulp looks good! Thanks again for all your amazing work!
I'll keep you informed about the update on Travis CI.

[fernandoacorreia]

Thank you @paulp and @gildegoma for looking into this.

[gildegoma]

FYI: the JVM worker machine on Travis CI (.org) will be updated in the next days with 60b6f26. The exact rollout date will be announced on http://blog.travis-ci.com.

Note that sbt 0.13.2 won't be pre-installed in this VM image, but in next VM update.