Init process different between Java and Spring stacks

[makandre]

Describe the bug

I’ve observed that the init for Java and Spring stacks run differently.

For Java, init runs mvn locally and setup the m2 cache such that I can do mvn commands in the project right after.

For Spring, init only setup the m2 cache after an appsody run (it appears setup happens inside the app container where ~/.m2/repository:/mvn/repository mount exists). As a result, running mvn commands in spring project after init gives “Non-resolvable parent POM” errors.

Additional context

I'm coming at this as a developer for the appsody extension for Codewind. It is preferable for us that the initialization behaviour is consistent between the stacks so we can use a single method to configure the IDEs correctly (VSCode and Eclipse) when creating an appsody project.

Also, the Java way of initialization essentially requires for mvn to be present (aside: isn't appsody supposed to shield the developer from requiring specific tools?) This is problematic for us too because we run appsody in Codewind's container (DinD) and we likely cannot install maven.

Spring way of initialization works better for us, but happening during run is not ideal because when the project is imported into Eclipse workspace after it's created and it's supposed to be "initialized" but it is actually not, so the project will not be configured correctly.

To Reproduce
Steps to reproduce the behavior:

Java:

1. appsody init java-microprofile
2. mvn validate
3. Succeeds

Spring:

1. appsody init java-spring-boot2
2. mvn validate
3. Get "Non-resolvable parent POM" errors
   (need to run appsody run in order for m2 cache to be setup properly)

Expected behavior

The behaviour between Java and Spring initialization should be consistent

Actual behaviour

The behaviour between Java and Spring differs as described above

Environment Details (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

If applicable please specify:

• CLI version:
• Stack you are using:

Screenshots
If applicable, add screenshots to help explain your problem.

[neeraj-laad]

@makandre You are right there are 2 slightly different approaches in those 2 stacks. The main reason being the init hooks were not present when the spring stack was initially created. We can look at implementing that, but there are always pros and cons to each approach and we would like the stack providers to be able to choose what they believe works best for them and their developers.

Also, the maven dependency (incase of microprofile) is only needed for IDEs to be happy. When users execute appsody run the appsody container provides all that is needed to run the application.

@ebullient @Emily-Jiang Would like your thoughts on this.

[makandre]

Understood. Tho given we are in the business of making (Codewind) IDEs to be happy, we really would appreciate a solution to address the inconsistency and the need for locally installed maven. Thanks.

[Emily-Jiang]

Here is my thought:
As an end user, I think below are the steps they will perform.

1. create a project based on the template using appsody init

2. import the project to IDE such as VSCode

3. add their business logic

4. Do local run using mvn install

5. Package away by issuing appsody run
   If you agree on the above steps, the way laid out by MicroProfile is logical. We should not make decision for the tool implementation point of view, we should think what the end user do normally.

[neeraj-laad]

I have submitted a PR to enable maven cache sharing on java-microprofile stack and install parent pom on host from within the appsody container during appsody run/debug/test.

This is a short term fix for this problem as it will not be possible for any other languages.

@makandre please can you test this fix with CodeWind?

[makandre]

I just tested, it works for us!

Just one caveat, because the setup happens during run, the project initially still shows compile error in Eclipse until the setup is done (and user may need to do a Maven > Update project to get rid of the errors). But this is something we can deal with separately on Codewind side.

Thank you very much for this fix.

[neeraj-laad]

I believe this would be similar to spring stack. We install the parent pom for both during appsody run.

If this can be worked around in CodeWind I'd keep the rest of the stack as is.