Closed arashi01 closed 4 years ago
Thanks for the PR!
This is great, and something I always found quite cumbersome, so this is greatly appreciated. We probably should add a deprecation release first to let uses know of the upcoming change.
@hamnis agreed.
Haven't found a very clean way to do this though. Added a commit with my best attempt so far. Basically involves keeping the old SignedAetherPlugin and changing the package of the new SignedAetherPlugin to allow both to be loaded concurrently. This shouldn't be an issue since users are unlikely to reference the new SignedAetherPlugin directly.
Some cleanup would be required once the deprecated support is removed though (included as comments in code),
there really isnt a good way of doing that that I know of.
We COULD release a 0.24.1 of the current codebase with a deprecation warning with no replacement, then release this next week. That would allow Scala-steward to do its thing and allow users to be notified.
Otherwise we can do it like you suggest. I'm not sure about the best way forward.
I think the method you suggest is probably the better way forward.
The other option has quite a bit of duplication and will need cleanup later.
@hamnis If you can cut a 0.24.1 release deprecating SignedAetherPlugin
I can rebase this PR against the new master so we can get 0.25.0 out?
Just did that now, should be in central in max couple of hours.
Okay great. Just rebased.
Currently using SignedAetherPlugin can get complicated in the case of multi-module projects, where the plugin has to be enabled and configured separately for each module.
This also makes it difficult to add the plugin to a multi-module build as part of a CI process in cases where it isn't possible to modify a build definition.
This PR splits SignedAetherPlugin into its own plugin
aether-deploy-signed
to overcome this issue.