Bintray/Gradle URLs

[wwilk]

Problem

Generating and customization of URLs, in this case for artifact repository (Bintray or Gradle plugin at the moment), but the similar problem would apply to other areas (eg. GitHub vs other VCS's).

Use cases

1. Release notes - we need an URL of a release in the repository for the badge, eg "https://plugins.gradle.org/plugin/org.shipkit.java/0.9.95" or "https://bintray.com/powermock/maven/powermock/powermock-1.7.3"

There are some issues with generating it automatically:

• version can be customized for Bintray, eg. powermock uses "powermock-1.7.3" while project version is 1.7.3, in this case version is tag + projectVersion, but it doesn't have to be. It can be customized in bintray.pkg.version.name

• "org.shipkit.java" part of Gradle plugins URL cannot really be automated, especially if there are multiple Gradle plugins in the project

• other parts of Bintray URL can be customized as well (userOrg, repo, packageName), eg in Mockito name = centralRelease? "mockito" : "mockito-development"

• at the moment we allow generating release notes for multiple versions. So what happens if you have a customized version name, we would need some kind of version resolver too.

2. URL of arbitrary version artifact for comparing publications. This may be easier to automate but in some cases (like with Mockito different packageName for different versions) it can be hard.

Possible solutions

1. OO approach - using a factory returning a correct type of UrlResolver depending on applied plugins (eg. if BintrayPlugin applied -> BintrayResolver)

Really nice solution for Shipkit developers, easily extendible and testable. The problem is with any customizations, user would have to write their own implementations of url resolvers. It is not that hard but also doesn't look so good in Gradle configuration files.

2. Pattern with placeholders, eg "https://bintray.com/{userOrg}/{repository}/{package}/{version}". Easily customizable by the user, but we would have to maintain a lot of different placeholders (eg. {bintrayVersionName}). So it doesn't scale.

3. Closure returning the correct URL, which you could configure like that: shipkit.releaseNotes.repositoryUrl = { https://bintray.com/${bintray.pkg.userOrg}/repo/package/${bintray.pkg.version.name} }

Easy to customize but harder to test and maintain by us. But what happens when generating release notes for different versions? Version would have to be an argument of closure which makes it more complicated.

What do you guys think? At the moment we use 1st approach for comparingPublications and partially 2nd approach for release notes (we have a project property publicationRepository, to which we concatenate the proper version). In my opinion the 3rd approach is the most convenient to the users and flexible, but I am not so sure about it, therefore I created this issue.

[StefMa]

Just for reference #452

[mockitoguy]

The problem is nicely described, thank you!

I suggest to keep things simple. On the high level:

• org.shipkit.java provides sensible default
• org.shipkit.gradle-plugin requires to the user to configure the repo

Powermock

In PowerMock's shipkit.gradle, we can have:

shipkit {
  releaseNotes.publicationRepository = "https://bintray.com/powermock/maven/powermock"
  //or
  releaseNotes.publicationRepository = "https://bintray.com/powermock/maven/powermock/powermock-$version"
}

Above looks pretty good to me and offers decent way of configuring it for end users.

Shipkit

In shipkit we have:

releaseNotes.publicationRepository = "https://plugins.gradle.org/plugin/org.shipkit.java"

Above works well because if you click through, you will be taken to the latest version in Gradle Plugin Portal.

Summary

I think that we have a decent API now and we don't have to complicate it. Rather, we can work on un-incubating the upgrade-downstream plugin (#460, #443) or making existing functionality more robust - avoiding unnecessary releases in 'org.shipkit.gradle-plugin' (#487, #419).

Great discussion! Thank you for bringing this up before the team.