Java Guestbook sample should have a parent pom.xml about cloud-code-samples

[simonz130]

Etan, the repo is public, @saturnism is welcome to comment and contribute.

[daniel-sanche]

Do we need to sync the project as a whole with maven? Won't users of these samples be mostly interacting with the container images rather than the local java environment?

Adding a parent pom that connects to all the sub-components seems to be breaking the spirit of microservices, and it could add more confusion to the project (it makes it seem like the services are more tightly coupled than they are)

[etanshaul]

hey @dansanche

Here is what happens, as is, with the project.

1. open the root java-guestbook app in IntelliJ. Notice the maven modules are not detected:
   

2. look at the module setup under Project Structure. Notice the frontend and backend modules are not present. Most importantly, no source roots are found. This means that the java files will not be compiled and treated sources. This is because there is no root pom.xml. IntelliJ does not automatically pick up the submodules' poms.
   
   

Note: At this point, you could deploy the application to Kubernetes using the Run Configurations and it will work. This is independent of the fact that the IDE is not aware of the project structure. But any attempt to add or modify code would be like editing a plain text file.

3. To fix this (without modifying the sample), you can manually add each submodule pom to the maven structure of the project. We would need to document this for users.
   
   
   

Adding a parent pom that connects to all the sub-components seems to be breaking the spirit of microservices

While I see your point here, the sample in its current state has a skaffold configuration that runs both microservices at the same time. Presumably the user would want to open the root guestbook app and have a view of both services in the IDE. If the user only wanted to deal with a single microservice, they could load only the subproject into their IDE and things would compile correctly - however, we currently do not have the ability to load a skaffold.yaml that lives outside of the project root (in this case the skaffold.yaml would live in a parent directory outside of the project).

I guess this ultimately depends on what we are trying to present the user: a multimodule project with a couple services, or independent microservices developed independently.

Maybe @saturnism has some input on a canonical setup for a simple 2 service guestbook app with a frontend and a backend?

[etanshaul]

@dansanche / @simonz130 could you give @saturnism (Ray) access to this repo if he doesn't aleady? He may have some valuable input on the java projects.

[daniel-sanche]

That's surprising that IntelliJ won't catch Java errors without the root pom file. Since it seems like IntelliJ requires rigid project structure, would it even support an app made up of many microservices written in different languages? Or would that break the IDEs expectations like this? I'll probably have to experiment with IntelliJ before I can comment more

In general, adding a root pom that references the others wouldn't be the end of the world, but it could be confusing to new users. I'd prefer if all language-specific files were contained completely in the directory for the service. But we could explain the issue with a comment in the file if we really need to

[etanshaul]

That's surprising that IntelliJ won't catch Java errors without the root pom file

Yeah thats mainly coming from the module screenshot that I showed above. There are no source roots defined, therefore IntelliJ is not treating any of the files as Java files.

Adding a root pom would work. Although this is a bit tricky given the Dockerfiles in each submodule which would need access to the parent pom (which is outside of the Docker context itself).

The other option, if adding a parent pom, is to update Skaffold to use Jib and get rid of the Dockerfiles.

[simonz130]

I am not comfortable with using Jib for Java and docker files for all the rest. Developers who might be interested in creating microservices in different languages will find it a bit confusing.
Also, parent pom sounds like a stop gap to address IntelliJ issues.

Let's see if Ray has ideas on this.

[etanshaul]

That's fine. In the meantime, do you want to tackle adding a parent pom?

[saturnism]

+1 to have a parent pom. the original (simpler) was here: https://github.com/saturnism/helloworld-java-springboot.

We should start off simple w/o little dependency as possible.

[saturnism]

i noticed that the current sample uses a Dockerfile. For Java, we should use Jib, and also a newer version of OpenJDK version (adoptopenjdk:openjdk8)

[etanshaul]

@simonz130 given what Ray suggested, are you ok making these changes? I'll still go ahead and instruct tech writer to use the guestbook sample in the docs since at least the parent pom issue will get resolved. I was considering falling back to helloworld depending on how quickly we can resolve this.

[simonz130]

We wanted the samples to be consistent across different languages. This include working with docker files. How Jib plays with Skaffold? We never tested it and I'm not comfortable to make this change in the last minute.

As to root pom - we might have to do it as I don't see anything better we can do for now.
@dansanche - are you OK with adding root pom?

[daniel-sanche]

Yeah, it seems like we probably need to add the pom to support IntelliJ at this point. I threw togther a PR with simple parent pom here #35

I'm not too familiar with intelliJ though, so idk if this pom will work automatically with the intended work flow. Someone more familiar should try it out and give feedback/fixes. (I seemed to get a couple "cannot resolve symbol" issues, but I think that's because I didn't set up the IDE properly last time I used it)

[etanshaul]

The parent pom added in the PR works now. I'd suggest we iterate on the samples to introduce Jib for the Java apps as Ray suggested. We can do this later after v1 and I can help answer any Jib related concerns.

[simonz130]

OK, sounds good. I'm closing this issue for now as Dan's PR was merged.