Plug-ins are not entirely self-contained drop-ins on the install directory

[whisperity]

Let's consider the scenario that someone wants to make their own plugin for CodeCompass. In case the full source code build is available, this works, as a drop-in to the plugins folder, a reconfigure-rebuild-reinstall will ensure all necessary files are updated. (Due to how file(GLOB works in CMake, changing of folder contents for a Web plugin won't update what needs to be copied until a CMake target is altered, or a manual reconfigure on the build folder is called.)

However, if servers with different enabled functionality (related to #268) are to be created, this means a build per configuration (of course something like ccache could help it). The problem is that while C++ code for a plugin is contained in the respective shared objects, related things, such as database schema files and web GUI components are deployed differently by the build script. Plugins can be dropped into an existing build as long as they don't rely on either the database or the WebGUI (what's worse, in some cases this hardcoding of content is even tighter, see #124), but the moment they do, simply installing a pre-built CodeCompass library does not work anymore.

(This also makes iterative development and jumping between developer branches problematic, as shared objects and JS files are not cleaned from the install dir.)

It should be investigated, along with #124, for a way to compress web content into the plugin binaries which are available, perhaps from the server's memory, once a plugin is loaded.

[mcserep]

Can we target the main objectives to achieve the goal this issue?

• CSS sources of the plugins shall be decomposed (#22).
• Plugins shall only depend on their own database tables. Common tables should be accessed through the SourceManager if the plugin is written in C++; or through a common internal service in case of another programming language. The latter was proposed in #324, basically extending ProjectService would fulfill this.

What else @whisperity ?

[whisperity]

Those two are good points, yes, but not the whole picture. I think the file(GLOB issue mentioned in the original post is obsoleted by the new JS build system. May be, I'm not exactly sure.

Here's some more:

• Just like how CSS should be decomposed, the JS of the plugins should be properly decomposed and separated, too.
  • Instead of dumping everything into some install directory (which is prone to overwriting, especially if we want to have separate sources of plugins use in a drop-in fashion), they should be compartmentalised in some way, that is more resilient than just having the JS file prefixed with cpp or python or whatever.
  • This way, the binary distribution of a parser plugin could work in a way that you don't need to self-compile and install the rest of CodeCompass. Unpacking a tarball into the install directory should throw every plugin binary and textual resource to the right location.
• I would prefer if these resource files, instead of being dumped out as files in a bare fashion to a directory, would be embedded into the shared object that is built from the plugin.
  • std::embed is still just a proposal, sadly, but there are ways to auto-generate an encoded span<char> via CMake and have that appear as a symbol in the plugin, which we can have the running web server expose from memory.
  • So basically, if you send me a codecompassHaskellService.so that has been built against my version properly, I want to just drop it in into my lib/parserplugins or whatever, restart the server, and bam, everything is there.

The .sql files suffer from the same issue. We are taking a resource from the file system and executing it, instead of supplying it encapsulated with the plugin binary they should be part of.