The displayed dependencies block for a given plugin may be incorrect in the case that the plugin has had multiple groupId/artifactId combinations (system_ids) in bintray. Take the excel-export plugin. This plugin is currently at version 2.0.2 and had a previous groupId in bintray of pl.touk while the current version is org.grails.plugins.
When building the plugin page, it looks like plugin metadata is read from bintray and used to build out the plugin details on the page. Continuing our example, that metadata is read from https://api.bintray.com/packages/grails/plugins/excel-export and looks like so:
From that data, the Plugins.es6 file builds the dependencies block from the latest_version, and the last value in the system_ids array. Herein lies the problem if the latest version does not correspond to that last system_id in the array. The result is:
Thanks for the info. It seems like in general the last value in the system_ids array corresponds to the latest_version. I'm not sure why this one's different but I'll look into it when I get a sec.
The displayed
dependencies
block for a given plugin may be incorrect in the case that the plugin has had multiple groupId/artifactId combinations (system_ids) in bintray. Take the excel-export plugin. This plugin is currently at version 2.0.2 and had a previous groupId in bintray of pl.touk while the current version is org.grails.plugins.When building the plugin page, it looks like plugin metadata is read from bintray and used to build out the plugin details on the page. Continuing our example, that metadata is read from https://api.bintray.com/packages/grails/plugins/excel-export and looks like so:
From that data, the Plugins.es6 file builds the dependencies block from the
latest_version
, and the last value in thesystem_ids
array. Herein lies the problem if the latest version does not correspond to that last system_id in the array. The result is:when it should be:
I'm not sure the best solution to fix this otherwise I would have made a pull request.