-
Notifications
You must be signed in to change notification settings - Fork 267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
{Dependency,Plugin}UpdatesReport overhaul #637
Comments
Heads up: it looks like using dependency inversion can offer much here, going with it. |
Extra item to do: convert xml report generators to "real" |
Still work in progress, so far have introduced a common model for the renderers and changed renderers into injectable components. It's not done yet -- I'd like to use a templating engine like Velocity. Sadly, it's not possible to inject a "context" into AptParser, otherwise I'd use it and would create a few macros to process content. For now, refactored and unified the renderers. |
Please close @slawekjaranowski @slachiewicz |
I see that there's quite some code duplication between DependecyUpdatesReport and PluginUpdatesReport. The classes could possibly use some refactoring. Plus maybe a name change to be in line with the convention (name should probably end with Mojo).
Speaking of which, DependencyUpdatesRenderer uses a completely different interface than DependencyUpdatesXmlRenderer. There's no common factory or a common interface to use the two and the user classes, need to create and handle the two different classes differently.
Here we should create a common API with probably a common abstract factory to instantiate the correct implementation of the renderer.
I appreciate this is not a functional nor a performance issue, but rather a code quality one. I will gladly take it.
The text was updated successfully, but these errors were encountered: