-
Notifications
You must be signed in to change notification settings - Fork 27
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
🌱 Extract getConfigVolumes to an interface #372
base: main
Are you sure you want to change the base?
Conversation
4595a8a
to
3450367
Compare
Signed-off-by: Alejandro Brugarolas <[email protected]>
3450367
to
0e885ba
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 👍
@eemcmullan what do you think about the comments regarding refactoring that @abrugaro mentioned? I guess the idea going forward is to split the analyze.go file, which is huge. If we export that struct (and also maybe split it?) we can further refactor this a bit.
import "github.com/konveyor/analyzer-lsp/provider" | ||
|
||
type Provider interface { | ||
GetConfigVolume(a *analyzeCommand, tmpDir string) (provider.Config, error) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could probably remove the return err here - I don't notice it being used. We can always add it back later if needed.
|
||
import "github.com/konveyor/analyzer-lsp/provider" | ||
|
||
type Provider interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be extended to include other methods. In particular, setProviders
"github.com/konveyor/analyzer-lsp/provider" | ||
) | ||
|
||
type DotNetProvider struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about moving the provider files into a folder such as providers
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My initial idea was to place the provider structs in a providers
folder. However, the analyzeCommand does not export any parameters, and I didn't want to change that in this PR since I don't have enough context on the code.
Should I change the AnalyzeCommand
to export the necessary properties?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There could be a pkg/providers
dir, and export necessary params from the analyze cmd. I think it would be good if it could further be refactored so that the providers
were agnostic to the analyze command. This would require a bit more work though, as some of the analyze cmd fields would need to be copied into a map, or similar, to pass to the providers (mostly the Java provider). But, I do think this is a good start to that, so am happy to merge and address these things later.
This PR addresses issue #249. I have modified the
getConfigVolume
method to extract the configuration creation for each provider into an interface implemented by each corresponding structInitially, my idea was to place the provider structs in an internal package. However, the
analyzeCommand
does not export any parameters, and I didn't want to change that in this PR since I don't have enough context on the code.I also considered refactoring other elements, such as separating the
analyzeCommand
itself from the execution context (which is currently also added toanalyzeCommand
). However, I decided not to address this in this PR because I wasn't entirely sure about the scope of the issue@eemcmullan Should I address what I mention in this PR as well? Is there anything else I'm missing regarding the issue?
Thanks!
CC @jmle