SVT: Import option "Codewind liberty" can be confusing for the users

[sujeilyfonseca]

Codewind version: 0.9.0 & 0.11.0 OS: Any OS

IDE extension version: 0.9.0 & 0.11.0 IDE version: Code 1.44.0

Description: Import option "Codewind liberty" can be confusing for the users

If you select that option for a Default Open Liberty project, it will be imported as a WebSphere Liberty MicroProfile project.

We should use Other > Java, but if there is an option named "Codewind liberty", users can wrongly select it for a Default Open Liberty project.

@jagraj

[tetchel]

yes, that option could read 'codewind microprofile'?

[tetchel]

That string comes from this route which gets liberty from the template index file

[stalleyj]

Totally agree that this is confusing. I think a full description would give the user the information required to select the right type. The project-types api was significantly changed for this issue https://github.com/eclipse/codewind/issues/292 to give full information for appsody stacks but not Codewind style. Resolving this will require modification to the API and also changes to the VSCode plugin I believe. @sujeilyfonseca have you looked at the behaviour in Eclipse or IntelliJ to if the experience is similar ?

[sujeilyfonseca]

@stalleyj, I verified the import feature using Eclipse (Linux) and IntelliJ (MacOS), and the user experience is different.

Eclipse: The IDE automatically prompted me to approve the type Other (Codewind Basic Container) and the Java language.

Also, if the user clicks next to select another type and language, there is no Codewind liberty option. Instead, there is a MicroProfile / Java EE option, which is more accurate.

IntelliJ: The user experience is similar to the Eclipse Plugin.

[stalleyj]

It seems that we must be providing all the required information if Eclipse and IntelliJ can provide the desired user experience. @tetchel Are you able to use the same info that the other IDEs use ?

[tetchel]

Yes. I meant to revisit this but forgot about the issue because it wasn't tagged with my area

[tetchel]

ok, I investigated this, and I still think the backend should be improved.

The reason the other two IDEs have better labels is that they have hard-coded mappings of the Codewind project types to user-friendly project types (see here). VS Code doesn't have this.

A proper, scalable solution would be to provide a label for each project type, combined with the description. The Appsody stacks use both of these, so no frontend hard-coding is necessary:

I think the Codewind project types should provide more info, the way the appsody ones do. The Codewind 'subtypes' are confusing because they are actually languages, which I can't recall the reason for (@makandre ?). But I think the following would serve our purpose, and wouldn't require redesigning the API:

Old:

    "projectType": "liberty",
    "projectSubtypes": {
      "items": [
        {
          "id": "java",
          "label": "java"
        }
      ]
    }
  }

New:

    "projectType": "liberty",
    "projectSubtypes": {
      "label": "Codewind template",
      "items": [
        {
          "id": "java",
          "label": "Microprofile / Java EE",
          "version": "It would be great if our templates had versions",
          "description": "It would be great if our templates had descriptions"
        }
      ]
    }
  }

Current Appsody stack project-type for reference:

  {
    "projectType": "appsodyExtension",
    "projectSubtypes": {
      "label": "Appsody stack",
      "items": [
        {
          "id": "incubator/java-microprofile",
          "version": "0.2.26",
          "label": "Appsody java-microprofile",
          "description": "Eclipse MicroProfile on Open Liberty & OpenJ9 using Maven"
        }
      ]
    }
  },

[makandre]

@tetchel It was to align all 3 styles (Codewind/Appsody/ODO) such that:

• first choice: select project type, i.e. nodejs, or docker, or Appsody, or ODO, etc (remember that for Codewind types, each "technology" is itself a project type)

• second choice:

  • if you picked Appsody, choices are the stacks, i.e. nodejs-express or java-openliberty
  • if you picked ODO, choices are the component types
  • if you picked a Codewind type, choices are the languages (tho this is only applicable for the docker type; in all other cases the language is implied)

Note the menu in VSCode is flatten out to a single list, this was due to feedback.

[tobespc]

ths information is here https://github.com/codewind-resources/codewind-templates/blob/master/devfiles/index.json

[stalleyj]

It is clear that style, type, subtype, language, framework are all being used and in slightly different ways for the different "styles". We need design/user experience input here so that we get this right going forward.

[tetchel]

I think that putting the data we already have (in the index.json Toby linked) into this API's response would solve this just fine

[thisguy-1]

please someone assign this to me

[tobespc]

@tetchel I think for now, with this being no where near the experience we want that until we get the UX sorted out, we hold off making any changes to pfe.