vsCode as part of the software package

[maybeec]

As long as the current stategy is to keep the open source IDE way of developing with OASP, we should consider and evaluate whether vsCode can be part of the software package and oasp-ide internal environment variables can have impact on the vsCode configuration (i.e. nodejs path).

[hohwille]

If so, we should IMHO make our current eclipse config management more generic and allow support for templating any kind of tool. What we are actually doing is already quite generic. We can handle arbitrary config files such as properties/prefs and XML. We can do merges of properties/prefs.
We can copy binary files as is.

we have a folder for the tool X in settings what is currently hardwired to eclipse.
In this folder we support setup and update. That same concept could be applied to any other tool in the workspace. In the settings/X folder could also be a oasp4j-ide.properties file that configures the path where to write the "workspace" to. This could be ${WORKSPACE} or something else (${HOME}/.idea or whatever).

[hohwille]

We also have the need to reuse the config template mechanism that is currently hardwired to eclipse also for IntelliJ. It would be relatively easy to make this more generic. We should file a separate ticket for this.
Addition templates for additional tools such as vsCode oder IntelliJ to settings package would not hurt. Projects can choose what they copy to their VCS. If they do not care and just commit everything it will also not hurt but just waste a few KBs of diskspace.
Adding larger tools to the standard software package is of more impact as this is causing Gigabytes. As we have to work with stupid windows filesystems we can also not rely on advanced deduplication of FS like brtfs. So if someone like me has ~10 projects with their IDE each on the disc this will duplicate each GB by 10. That is quite a lot. So here it is better to align the tools we offer by default. For additional tools we can provide a separate ZIP. For our new OOMPH approach we might consider to split each tool into a separate ZIP as the installation and extraction is automated. Then only by config you can choose for or against a tool like vsCode as the project architect.

[maybeec]

yes, completely aggree. I am currently working on a portable vsCode for my project.
However, it might be questionable whether there is a different way for sharing settings in different tools. So I would not propose any gneneric solution for that. This would be overkill.

I will keep you updated.