Execute global directives before runtime config #56
Conversation
|
@ctrueden the only reason I didn't merge directly is that there is a bit of oddness with user args not being validated until they've already been used in the global directives. So I can imagine a situation where a user launches an app with some invalid argument, it successfully applies an update, but then quits because of the arg. Personally I find this tolerable given that I prefer the two passes of executing directives to one with maybe a second runtime configuration. I didn't see any utility in checking args before executing the global directives, since we can't definitively reject any args until we have the runtimes later. |
There was a problem hiding this comment.
This is awesome! Very nice, logical solution.
I can imagine a situation where a user launches an app with some invalid argument, it successfully applies an update, but then quits because of the arg.
Yeah, I agree it's a bit strange, but also that it's a minor issue... maybe even a non-issue. Unless/until a third global directive besides help and apply-updates comes along, we shouldn't really have to worry about it much, eh? 😄
Global directives are necessarily runtime-agnostic, and may have impact on building the subsequent runtimes (e.g. in the case of applying updates and then building a classpath that includes those updated libraries). Thus we split directive execution into two phases: first global directives, then runtime directives (after runtimes have been configured). Closes #47 Closes #55
hinerm
force-pushed
the
separate-global-directives
branch
from
beea943
to
bb32461
Compare
Fixes #47 by executing global directives before the runtime is configured.