Easy Init: Enhance the Java analyzer #4640
Conversation
| return azdMvnCommand, nil | ||
| } | ||
|
|
||
| func downloadMaven(filepath string) error { |
There was a problem hiding this comment.
I'm wondering what happens if we don't download maven and just fail with a proper help here.
In azd, we generally do not acquire build tools for users. A Java user with a valid project set up should be able to land into maven / mvnw well. We can provide pointers, but I do think it may be too much if we're auto-acquiring build toolchains for them.
In my mind, not having maven installed but having pom.xml installed would be in a similar category as running Application.java without Java runtime installed -- this is something we can help users with but not abstract away.
| } | ||
|
|
||
| // replace all placeholders with properties | ||
| str := replaceAllPlaceholders(unmarshalledPom, string(bytes)) |
There was a problem hiding this comment.
Are we replicating what maven would normally be doing as part of a build evaluation? If so, I'm wondering if there is a different way of doing this?
I know we have used mvn help:evaluate -Dexpression=propertyPath -q -DforceStdout in the past
| if err != nil { | ||
| return pom{}, err | ||
| } | ||
| cmd := exec.Command(mvn, "help:effective-pom", "-f", pomPath) |
There was a problem hiding this comment.
Curious here, are we evaluating an effective POM based on the active configuration? I'm wondering how this ends up impacting the overall e2e. Does a user get a different result if they switch their active build configuration?
| if !commandExistsInPath("java") { | ||
| return pom{}, fmt.Errorf("can not get effective pom because java command not exist") | ||
| } | ||
| mvn, err := getMvnCommandFromPath(pomPath) |
There was a problem hiding this comment.
I think this is equivalent to using the existing maven package we have:
mavenCli := maven.NewCli(exec.NewCommandRunner(nil))
mavenCli.SetPath(filepath.Dir(pomPath), rootProjectPath)I have to look at it again with a deeper set of eyes, but it doesn't look quite right that we're using os.Getwd() here. We should be rooted in root passed to appdetect.Detect call, or perhaps the parent pom.xml (whichever correctly replicates the logic that mvnw would use.).
If this works, I think we can remove the maven_command*.go files.
| readPropertiesInPropertiesFile(filepath.Join(projectPath, "/src/main/resources/application.properties"), result) | ||
| readPropertiesInYamlFile(filepath.Join(projectPath, "/src/main/resources/application.yml"), result) | ||
| readPropertiesInYamlFile(filepath.Join(projectPath, "/src/main/resources/application.yaml"), result) | ||
| profile, profileSet := result["spring.profiles.active"] |
There was a problem hiding this comment.
Does this strategy also work if the active profile is set via env var or flag? https://docs.spring.io/spring-boot/how-to/properties-and-configuration.html#howto.properties-and-configuration.set-active-spring-profiles
|
Hi @saragluna. Thank you for your interest in helping to improve the Azure Developer CLI experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days. |
|
Hi @saragluna. Thank you for your contribution. Since there hasn't been recent engagement, we're going to close this out. Feel free to respond with a comment containing "/reopen" if you'd like to continue working on these changes. Please be sure to use the command to reopen or remove the "no-recent-activity" label; otherwise, this is likely to be closed again with the next cleanup pass. |
This PR is targeting improving the Java analyzer of AZD, which will:
projectstruct, to store more information related to the project