Feature/launch script accept java options

[morgen-peschke]

Based off the general idea from #106, with tweaks so the -D* arguments aren't passed on to the jar

[xerial]

Thanks for the enhancement!

[morgen-peschke]

@xerial My pleasure. Do you have a date planned for the next release to hit maven?

[alexarchambault]

@morgen-peschke Does this mean that one cannot anymore pass options that start with -D to programs launched via sbt-pack?

[morgen-peschke]

Thanks for noticing that, @alexarchambault, I'd missed that implication because I avoid using -D as arguments to programs which run on the JVM to avoid confusion.

How important of a use case is this? If it's a real consideration, as opposed to hypothetical (it's still a valid point, though), escaping them should be fairly straightforward.

Two straightforward ways of working around this could be:

• Tweaking the blob slightly and putting a notice in the readme that -D... would be understood as an argument for the JVM, but -D ... would be passed to the program.
• Modifying the blob to check for -D-D instead and stripping off the extra -D before passing it to the JVM

[alexarchambault]

(Oops, sorry for the late answer :/ )

Couldn't this feature be put behind an sbt option? Like a packAutoJavaOptions? If true, then the arguments starting with -D would be passed as java options. If false, they wouldn't (sbt-pack behavior before that PR). I'm using sbt-pack to run some applications where I think I'm using basically all the letters of the alphabet as options ;), so I would disable it here.

But when it's enabled, other forms of Java options could be handled too then (like -Xmx, -Xms, etc.)