Cannot add query parameters to custom repository URL

[baron1405]

I am using the custom plugin repository feature but have hit a blocking issue. I cannot add any query parameters to the repository URL. The problem is in the logic for constructing the repository URL. In the constructor for the CustomPluginsRepository class there is the following code:

        if (repoUrl.endsWith(".xml")) {
            this.repoUrl = repoUrl.substring(0, repoUrl.lastIndexOf('/'))
            pluginsXmlUrl = repoUrl
        } else {
            this.repoUrl = repoUrl
            pluginsXmlUrl = repoUrl + "/updatePlugins.xml"
        }

Notice that if I pass https://foo/updatePlugins.xml, the first branch of the if is executed and my URL is used. However, if I pass https://foo/updatePlugins.xml?build=202.7319, the URL string does not end with .xml and the second branch is run, which results in the final URL being https://foo/updatePlugins.xml?build=202.7319/updatedPlugins.xml, which is clearly not the desired URL.

I recommend converting the passed in URL to a URI object and testing its components using that class. That way, query parameters are taken into account and construction of a new URL can add the query parameters back. Something like the following (not tested):

CustomPluginsRepository(@NotNull Project project, @NotNull String repoUrl) {
    this.project = project
    String pluginsXmlUrl
    if (new URI(repoUrl).path.endsWith('.xml')) {
        this.repoUrl = repoUrl.substring(0, repoUrl.lastIndexOf('/'))
        pluginsXmlUrl = repoUrl
    } else {
        this.repoUrl = repoUrl
        String[] urlComps = repoUrl.split(/\?/)
        pluginsXmlUrl = urlComps[0] + '/updatePlugins.xml'
        if (urlComps.length > 1) {
          pluginsXmlUrl += "?${urlComps[1]}"
        }
    }
    Utils.debug(project, "Loading list of plugins from: ${pluginsXmlUrl}")
    pluginsXml = Utils.parseXml(new URI("${pluginsXmlUrl}").toURL().openStream())
}

The above is just a suggestion but it should at least illustrate the problem.

[baron1405]

Hi @zolotov, would appreciate your help on this issue. This and #590 are blockers for our development of plugins that use custom repositories for plugin dependencies against our Enterprise plugin repository.

[zolotov]

@baron1405 sure, I'll take a look. This one looks easy, not sure about #590. Do you have a special server implementation that can understand those parameters and wildcard version? If so, is #590 really required? Maybe you could use some predefined version (e.g. "1.0.0") and use build parameter (set to IDE version) and the server would generate xml with plugins on the fly?

[baron1405]

Thanks @zolotov for getting back to me. Yes, hopefully this one is straightforward. As for #590 we do have our own service that handles the request so we could do some workaround using the version or query parameters (hence the need for this fix). Implementing #590 would allow the custom repository query to act like the query you do for the JetBrains plugin repository (i.e. specify a ?build= and you get the latest plugin compatible with that IntelliJ version). Besides consistency with the JB repo query, it would allow us to avoid adding new query parameters to our service because our service already acts like the JB service and accepts a build query parameter. In the end #589 is a must have, and #590 is a really^3 nice to have.

[zolotov]

the custom repository query to act like the query you do for the JetBrains plugin repository

Often, custom repository is a static XML, the change might work unexpectedly for those usages. Anyway, please see #543, I think it's quite similar

[baron1405]

The problem mainly has to do with the order in which things are done in the custom repository. First a catalog is obtained and then the requested version is resolved against that catalog. During resolve the catalog is searched for the requested plugin id and version. My enterprise repo acts just like the JB plugin repo in that if I specify the IntelliJ build as a query parameter I will get back a catalog with the latest versions compatible with that IntelliJ build. That means, if I could just wildcard the plugin version, I will get exactly what I and my developers want, the latest compatible plugin to develop against as a dependency. If I cannot wildcard the version, I will have to specify the versions of the plugins as query parameters and have my repo return a catalog created around those versions. Certainly doable but feels clumsy compared to relying on similar behavior to the JB repo.

I reviewed #543 but what appears to be different about my ask is that we could still identify non-bundled plugins using a special character in place of the version (e.g. *) and we could restrict the handling of that wildcard to custom repos.

[baron1405]

@zolotov Hi, do you have an estimate of when we can expect 0.7.0 to be released?

[zolotov]

@baron1405 in few days I think