The utility can then be added to the application context, and only one
lookup is needed. Also switchews on autoconfiguration in the deployer
app, since the deployer implementations support that now.
Instead of JAVA_OPTS (didn't like the name anyway), user can define
generic "properties" in each deployable that will be passed down
to the app request.
The current 1.0 snapshots of the local deployer look in there for
JAVA_OPTS (but that hopefully will change to something more
"property like") before 1.0.3 is released.
If user runs `spring cloud dataflow h2` you'd expect the database to
be used by dataflow. It's tricky to achieve, and impossible with
an in-memory data store (because of the way dataflow is set up
currently). This was achieved by adding a feature: each deployable
can specify "enabled" (in addition to existing "disabled" feature)
properties: i.e. environemnt properties that are applied to all
other apps as long as this one is running.
Another change here is to pass the "PATH" env var from the deployer
down to deployed apps. This affects dataflow in particular because
it likes to launch other apps, and it will pick the wrong Java
version (for instance) if the path is not preserved.
(also try config/<name>.yml). In this way user can easily launch config
server with custom uri, h2 with custom tcp endpoints, etc. The local
app deployer puts these properties in sys env vars (a bit yuck), but
that's not in our control here.
spring cloud --git-uri=http://mygit/myrepo.git configserver
Above command option changes configserver to use the git profile with the configured git url.
fixes gh-24
