George Gastaldi

This issue was moved to fabric8-launcher/launcher-planning#82

Quoting @kenfinnigan's email that originated this issue (for context) >If we're going to say that anything Istio related is "manual", then we need a solid user experience around how the...

One idea is to put this information inside the booster's `metadata:` tag. This would make it a centralized place that the UI (and others) can also read from.

It is already possible to do https://forge.api.openshift.io/api/launcher/zip?groupId=io.openshift.booster&mission=health-check&runtime=vert.x&runtimeVersion=community&artifactId=app and automatically download the booster code without much fuzz.

Add a parameter named `PROJECT` to the template and Launcher will set that for you

PROJECT contains the Openshift project name that Launcher creates when you specify it in the Project Info step. I'll have a look if we can add more variables. Btw here...

One solution would be to have a ProjectilePreparer implementation (like in https://github.com/fabric8-launcher/launcher-backend/blob/master/core/core-impl/src/main/java/io/fabric8/launcher/core/impl/preparers/ChangeMavenMetadataPreparer.java) to replace the hardcoded name in the application with the Projectile artifactId. You would end up with a...

Just to be clear we are talking about the same thing, what is "ApplicationName" in your context? I assume it is the project name when you type here or is...

Also, if you deploy a REST HTTP booster AND a Health Check booster in the same OpenShift project you would not get any name conflict afaik

Ah I think I understand now, maybe a solution in this case would be to replace the hardcoded `wfswarm-rest-http` with the Github repository name used to launch the Booster or...