Duplicate entries in plugin.zip

[Eugene Petrenko]

I'm building a plugin that is compatible with a set of TeamCity versions. It turned out, the gson library was included in the version I was building against. To workaround it I specified the same dependency for agent and compile configurations. As the result, I noticed a duplicated entry in the generated .zip file of agent plugin.

In the sources in TeamCityAgentPlugin.groovy I spot the following:

into("lib") {
                project.plugins.withType(JavaPlugin) {
                    def jar = project.tasks[JavaPlugin.JAR_TASK_NAME]
                    from(jar)
                    from(project.configurations.runtime - project.configurations.provided)
                }
                from(project.configurations.agent)
            }

It looks like those several from declarations does not check for duplicates (at least with Gradle 4.7)
Similar code is for the server-side plugin.

[Eugene Petrenko]

My usage example and a workaround are here https://github.com/jonnyzzz/TeamCity.Node/

[Rod MacKenzie]

I was able to observe this problem, not with the gson library but with the httpclient library.

An alternative workaround for the problem is to specify a duplicatesStratey for the agentPlugin task when adding a dependency to the compile and agent configurations.

tasks.withType<Zip> {
    duplicatesStrategy = DuplicatesStrategy.EXCLUDE
}

A longer term fix is to update the gradle-teamcity-plugin to use the compileOnly configuration for TeamCity API dependencies, that would allow the following line, that is removing your explicit dependency, to be removed from(project.configurations.runtime - project.configurations.provided).

[Eugene Petrenko]

Thanks! In general, it looks unclear, what dependency should one re-publish and which dependency must not be published. It is possible to check - as long as a dependency class is visible in TeamCity API - it is not possible to re-publish (a LinkageError os similar error will appear of one uses the API). It looks nice if you would be able to set up the `duplicatesStrategy` for Zip tasks you create in the plugin. That would play as a good workaround for the future. `compileOnly` dependencies configuration does not play well in any other configurations (in my case there was a test project that depends on the server and agent plugin classes). It looks better to re-include any dependencies I specify with `compile` dependency automagically. Shall the rule in the `zip` task only exclude TeamCity dependencies instead? Best regards, Eugene Petrenko

…

On Mon, Apr 30, 2018 at 2:18 PM, Rod MacKenzie ***@***.***> wrote: I was able to observe this problem, not with the gson library but with the httpclient library. An alternative workaround for the problem is to specify a duplicatesStratey for the serverPlugin task when adding a dependency to the compile and agent configurations. tasks.withType<Zip> { duplicatesStrategy = DuplicatesStrategy.EXCLUDE } A longer term fix is to update the gradle-teamcity-plugin to use the compileOnly configuration for TeamCity API dependencies, that would allow the following line, that is removing your explicit dependency, to be removed from(project.configurations.runtime - project.configurations. provided). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAPpr9RgsDzOunV2uFax8lgKKY12xWSgks5ttwEegaJpZM4TrjV_> .

[Eugene Petrenko]

It looks like I found the source of my bug. It was caused by my dependency from `agentImpl`, which in charge induced a set of other dependencies, that included `gson`

[Eugene Petrenko]

One more problem, I found out the workaround does not work fully, because of transitive dependencies, which are not being included (probably, excluded by the agentImpl dependency)

[Rod MacKenzie]

I've published a new version of the plugin, 1.2-beta-1, that uses the compileOnly configuration for TeamCity API dependencies. I've tried this building your TeamCity.Node plugin without the fix_dependencies workaround and it appears to produce a plugin with the same contents. I also removed the duplcatesStrategy setting, this shouldn't be needed.