Add a second Plugin Portal-compatible ID to the Gradle plugin

[wilkinsona]

Chatting with @eriwen about getting our plugin into Gradle's plugin portal, the idea of easing the move to a Portal-compatible ID by having two IDs for a while came up. Eric's checked, and it's supported. There are already plugins using the approach.

I propose that we:

• Add org.springframework.boot:spring-boot as a second ID
• Update the docs to use the new ID
• Output a deprecation warning when the old ID is used

See #1567

[vpavic]

Please consider prioritizing publishing of plugin to portal a bit more if possible. Gradle's new plugin resolution mechanism backed by plugin portal was introduced in Gradle 2.1, and that was over 2 years ago. I'm sure many users are using old fashioned plugin mechanism solely for Boot's plugin.

[wilkinsona]

@vpavic Our plugin's absence from Gradle's Portal has nothing to do with the prioritisation of the work. I won't rehash all the problem here as they're covered extensively in #1567 and the thread on discuss.gradle.org to which it links, but suffice to say that the plugin would already be in the portal if a robust, build system agnostic publishing mechanism was available.

All that said, thanks to @eriwen's efforts, there's some light at the end of the tunnel. I can't make any promises on the timescale as almost all of the problems are out of our control, but things are moving in the right direction now.

[vpavic]

@wilkinsona Thanks for the feedback - I'm aware of the history of this problem as I've been following it closely. I didn't mean to say absence from the portal is due to prioritization concerns (sorry if it came out that way). My priority comment was related to "from this point on" since the things appear to have started moving.