You can clone with
HTTPS or Subversion.
It took me a while to figure out that my changes to the sample config file weren't getting picked up unless I set CLOUD_FOUNDRY_CONFIG_PATH. Is there a reason to not have it pick up the default one?
Which "sample config file"? Since there are many uaa.yml files in the repo (e.g. for testing different scenarios), we can't point to all of them (they don't make sense as a single config entity). The README has instructions about environment variables and config file locations, so I'm not sure what else we could do.
I'd expect config/uaa.yml to be picked up by default if you start it from the root of the repo. That would match the other cf components.
Ah, that config file. I had forgotten that one even existed. It's there to support dev_setup (remember that?), but I suppose we could make it do something out of the box as well. I would prefer to simply remove it.
I'd like to keep it and make it a sane example config file that works out of the box with cf. I may be reinventing dev_setup again, but it's nice to just clone and run with sane defaults.
Where do the defaults come from anyways? I had to add cf as a trusted client to use the new gem, vmc seemed trusted by default.
The defaults are embedded in the Spring config files where they are used, so if you clone and run it should be sane. We should add "cf" as a client for sure.
[gh-38]: add cf client by default
Actually, if you use the bin/uaa script to launch the server it does use that config file (and set the env var). I still think we should remove those artifacts because they were only there for dev_setup (e.g. you don't really need NATS to run the UAA, but the script is mainly there to send the router registration over NATS.
Ah, I didn't see the bin/uaa script since it's not referenced in the readme.
I think having a start script that makes uaa look like a cloudfoundry component is a good thing. It's good if you just want to start the thing up without bosh.