I think this should be ready to review now. A long the way, I found more issues:

1. The change to selectively run findMainClass isn't really practical because of how many other tasks can run with it. With the task correctly caching now, the impact should be low, and it will just run when we compile instead of only when boot* tasks are in the task graph. Merging forge found this because of the ScaffoldingSpec being a functional end-to-end test.
2. includeBuild() works on gradle builds that run as part of grails-forge, but for the "functional tests" that fork a java process, they don't. Since we added GRAILS_REPO_URL support to Grails shell, I've gone ahead and added support to forge so that if that's set, any generated project will have that as the first repo. Since I added this support, tests can use this to set to a local repo that's published as part of building forge. The only tooling that doesn't support that environment now is profiles. It would be nice if they did, but that's for another ticket.
3. I updated the publishing plugin to use lazy properties & defined better defaults
4. I updated the publishing plugin to publish a local testing repo (which grails-core uses for number 2 above)
5. I added the IP output to all of our builds after discovering the timeouts are due to 404 blocks. See associated dev list email for follow-up discussion.
6. I removed the metaspace restrictions since later jdks define it as unlimited by default and suggest not setting it
7. the first load in intellij (the EAP with the grails plugin fix) took a bit to recover. Once it loaded, it worked fine.
8. You won't be able to run grails-forge from grails-core since grails-forge includes core, instead of vice versa. This is actually a benefit - people who want to just work on core can do so. If you open the grails-forge folder as a project, intellij will show you all of the gradle projects - grails-core, grails-gradle, and grails-forge. If you want to do end-to-end testing, that's my suggestion on which project to open.
9. I removed the rat config from grails-forge because it scans from the repo root, which will include forge (it doesn't respect gradle project boundaries)

I did notice that the license headers are different in the forge projects, still using the Copyright XXXX original authors text.

1. headers updated via spotless
2. INSTALL, etc should be fixed in the distribution now

Concerning the windows path, @jamesfredley can you try adding uri('mypath') where mypath is the local path? I suspect that will fix it.