Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

abrugaro
Copy link

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 struct

Initially, 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 to analyzeCommand). 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

@jmle jmle requested review from eemcmullan and jmle November 13, 2024 17:02
@abrugaro abrugaro force-pushed the extract-providers-to-interface branch from 4595a8a to 3450367 Compare November 19, 2024 13:15
Signed-off-by: Alejandro Brugarolas <[email protected]>
@abrugaro abrugaro force-pushed the extract-providers-to-interface branch from 3450367 to 0e885ba Compare November 19, 2024 14:10
Copy link
Contributor

@jmle jmle left a 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)
Copy link
Collaborator

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 {
Copy link
Collaborator

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 {
Copy link
Collaborator

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?

Copy link
Author

@abrugaro abrugaro Nov 19, 2024

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?

Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants