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
This PR is targeting improving the Java analyzer of AZD, which will:
projectstruct, to store more information related to the project