eclipse-archived
[odo] Project extension (odo and Appsody) improvement in Turbine layer
Description of the enhancement:
In today's Turbine layer we have code like this for extension project type:
else if (projectType == "odo") {
const componentName: string = await getComponentName(projectName);
args = [
projectLocation,
operation.projectInfo.projectID,
command,
operation.projectInfo.language,
componentName,
logDir,
String(operation.projectInfo.autoBuildEnabled)
];
}
Instead of burning extension specific code into Turbine layer, we can define generic function in extension interface then all extensions can implement the function in their own class.
For example:
In extension interface we can have:
getExtensionArgs?(projectID: string): Promise<string[]>;
Then implements the function in extension class.
In Turbine layer if getExtensionArgs is available in the extension project handler then we use it, if not we go to the same code path as before.
Proposed solution:
I also noticed that a OdoExtensionProject.ts class was added, but I wonder if the extra functions in this class could be consolidated back to the generic ShellExtensionProject.ts class so there isn't an ODO specific class type. Just a thought.
@makandre I think this can be boiled down to Merge all extensions into same class and add lots of conditions into the same class for different extensions VS Use extension specific class to implement the same interface. In my opinion, I would go for the latter for simplicity and scalability.
Well in that case, could we at least rename the class to be less ODO specific? Perhaps something like (for lack of better name) ShellExtensionProject2.ts, or a better name of your choosing.
For naming, I think if we choose the latter as I mention above. Given we have a generic interface IExtensionProject, then it makes sense we have extension specific naming for the class to implement the interface because it's easier to read. I think the key point from Elson is try to not burning the extension specific stuff into the generic stuff like Portal, Installer, Turbine. But I can bring up the naming topic in our status meeting.
The original intent was that you could implement an extension without needing to add a new class into the Codewind codebase; you would just need to have the .sh-extension and entrypoint.sh files (both of which are part of the extension's codebase)