Simplify setup

[jmfayard]

Changelog

🎉 Make the new updater the default
✨ Bootstraping refreshVersions #155

The setup for Groovy should now be:

// settings.gradle
import de.fayard.versions.RefreshVersionsSetup
buildscript {
        dependencies.classpath("de.fayard:refreshVersions:VERSION")
}
RefreshVersionsSetup.bootstrap(settings)

The setup for Kotlin should now be:

// settings.gradle.kts
import de.fayard.versions.bootstrapRefreshVersions

buildscript {
    dependencies.classpath("de.fayard:refreshVersions:VERSION")
}

settings.bootstrapRefreshVersions()

[jmfayard]

@LouisCAD regarding to the package issue
Answer from Louis Jacomet on the Gradle slack channel

Yes it works, but no you should really not do it. You are effectively leveraging split packages.
You end up squatting the Kotlin DSL namespace in a plugin, potentially causing risks of collision with others attempting the same or even Gradle adding new things.

I think this equally applies to using the root package, so I moved it simply to de.fayard.versions

[LouisCAD]

I think if we have a name that is very unique for the bootstrap symbols, using the root package is less of an issue as there would be no clash with future Gradle APIs, buildSrc code or other dependencies using root package as well.

[jmfayard]

We don't need to use the root package, IntelliJ auto-improts flawlessly the extension fuction if you don't put the import.

[jmfayard]

@LouisCAD please review the last commit who generate properties for all deps
2173c74

[LouisCAD]

I merged master into this branch now that there's a file format and exposed API for version keys (#161), and I fixed the merge conflicts.

I'm in the process of reviewing locally, fixing what needs to be fixed, before this can be merged and released.

[LouisCAD]

I noticed versions.properties is now filled with all versions, but for the ones that are hardcoded, the latest version is put, not the version that is actually used with the other candidates. That happens because the plugin wasn't designed for the change of getting all the versions.

I'll work on a solution for that in this PR, or revert that part, so it's being worked on in another PR, after this one is merged.

[LouisCAD]

Also, the changes broke dependencies rewrite as you can see the version placeholder stays in the publication as the GitHub actions failure shows.

Edit: Found the root cause, it is because the dependencies plugin has not been upgraded to the latest version of refreshVersions despite having its property removed.

[LouisCAD]

It's now ready to be published, I'll merge it.

Next up are:

• Documenting what we have
• Easing migration towards refreshVersions
• Remove old implementation to clear up the codebase
• Ditch versions sorter and keep order or maven-metadata, sorting the results in the order of the repos declaration.
• Simplifying setup of the dependencies plugin, so we can have a bootstrap that enables it along with refreshVersions?