The only Che stack that is used is the plain java one

[l0rd]

Even if Che has a distinct stack for every quick start (vertx, spring boot, wildfly) these are never used in OSIO. When Platform starts a Che workspace it uses always the same plain Java stack even if user has selected a vertx quickstart.

It's a pity because these stacks would ensure a better UX for the developers (dependencies are pre-downloaded and commands to build and run applications are pre-configured).

The clean solution to solve that:

• Forge should add a chefile at the root of the github repository when it generates the quickstart.
• Che should parse the chefile and run the workspace based on the info that are in the chefile

This solution can take many weeks to be implemented.

A short term solution could be to prompt the user with five options (plain java, vertx, spring boot, wildfly swarm, node js) when it select "create workspace". That's not a nice option from a UX point of view: the user is asked twice about the technology stack. But once the IDE is started he will be happy to find the commands and the pre-downloaded dependencies.

cc/ @gorkem @joshuawilson @burrsutter @benoitf @ibuziuk @aslakknutsen

[joshuawilson]

Let's use this to discuss the long term and short term plan.

cc @maxandersen @catrobson @jstrachan @corinnekrych

[joshuawilson]

@l0rd can you be clarify that this issue is blocking the use of Che?

[joshuawilson]

I thought the only stack we were using was the one for vert.x.

[l0rd]

@joshuawilson no it's not blocking Che usage. It makes a the UX worst. A user needs to manually run mvn clean vertx:run or needs to create a custom command. Whereas with vertx stack a user can click the run button right away.

[l0rd]

The UX problem has been described by @burrsutter here: redhat-developer/rh-che#95.

We need to discuss if it makes sense to implement a temporary workaround to address @burrsutter concern or if we can wait untill forge/chefile integration is completed.

[catrobson]

Thanks for the very comprehensive explanation of the situation @l0rd - very helpful! @joshuawilson is there anything we can do on the front-end carry the knowledge from the wizard (where we knew what stack they chose) into the workspaces page so that we can pass that into the "create workspace" action without adding a user-driven UI step for this?

[joshuawilson]

This needs to be discussed by the team.

[maxandersen]

@l0rd what part is it that are missing ?

Does che today read the file that Forge is generating or is it because Forge is not generating the file you need ?

[aslakknutsen]

The Forge service needs to return the stack id to the UI so the Codebase can be created with the correct stack. If that is done, Codebases will call the CheStarter with the stack id.

[jstrachan]

The Forge UI adds an annotation to the BuildConfig with the correct Che Stack ID. This is also returned to the front end as the cheStackId property.

We just need to use that stack ID value in the wizard front end when we create the Codebase (and for the Create Workspace to use that value too)

apiVersion: v1
kind: BuildConfig
metadata:
  annotations:
    che.fabric8.io/stack: vert.x
  labels:
    space: beer
  name: beer2

[jstrachan]

Forge can generate a Chefile in the source of newly created projects too; but I thought we were some ways off reading Chefiles?

[gorkem]

@jstrachan correct, It is better to adopt the chefile based solution once eclipse-che/che#4362 is resolved. This solution also requires factories which is not part of our assembly of Che yet.

[jstrachan]

@gorkem is there a way to pass the stack id into the create Codebase REST call?

[gorkem]

che-starter REST api has a parameter for stack ID but codebases are on core @aslakknutsen can provide the best information.

[ibuziuk]

che-starter supports all 5 stacks with project-type mapping [1]. So, if Forge is able to pass stack id to Codebases, che-starter will be able to create a workspace against it (AFAIK, currently platform is always passing java-centos to che-starter)
[1] https://github.com/redhat-developer/che-starter/blob/master/src/main/java/io/fabric8/che/starter/model/stack/StackProjectMapping.java#L28

[jstrachan]

@ibuziuk cool thx; so Forge passes the stack id to the fabric8-ui.

I've split this into separate sub issues:

• we need the App Wizard to pass the cheStackId into the Codebase (assuming it can be included as a property): App Wizard should pass the cheStackId property from Forge into the Codebases resource when it creates a Codebase #1546
• then we need the create Workspace to reuse the stack id on the Codebase: create Workspace should reuse the stackId property on the Codebase  #1547

we can probably close this one now? Or use wait until those 2 issues are fixed?

[l0rd]

@jstrachan I would prefer to keep this open and log here the work related to Chefiles and factories.

[aslakknutsen]

@l0rd The title of this issue is wrong at this point, correct? Could you rename it to reflect the CheFile/Factories issues?

[l0rd]

@aslakknutsen I'm going to close this since the original issue has been solved. The Chefile/factory issue already exists in eclipse/che repo: eclipse-che/che#4362