workspace master and agent : avoid scan of classes at runtime in order to find DynaModules

[mkuznyetsov]

What does this PR do?

Today, ws-che-master and ws-che-agent are deployed using war files. In order to have extensibility, we can apply a @DynaModule annotation on guice class modules. Then, at runtime, Servlet container(Tomcat) is scanning the jar files to find the @DynaModuleclasses and then call the org.eclipse.che.inject.ModuleScanner class by calling onStartupmethod

When Che is initialized, it calls CheBootStrapclass that ask the modules found by the scanner by calling modules.addAll(ModuleScanner.findModules());

The issue is that we've a lot of scanning operations (performed by SCI (ServletContainerInitializer) .
Following https://wiki.apache.org/tomcat/HowTo/FasterStartUp if we disable all JAR scanning operations we lost the ability to use DynaModulewhich is not good.

The idea is then to still disable scanning at runtime but keep using DynaModule.
By writing a plugin that could scan all @DynaModule when generating the war file, we could avoid the scan at runtime and then keep the ability to use `@DynaModule``

This PR introduces this plugin and the use of this plugin inside ws-master and ws-agent.
On the agent, we should also add <absolute-ordering />element but it will break archetypes/custom assemblies.

How is it working ?

The DynaModule plugin scan all the classes (there is a way to skip some jars that we're sure doesn't contain any @DynaModule annotations) and generate a class that provides a getModules() method returning all DynaModule modules.
This class is then loaded at runtime and CheBootstrap can load these modules, avoiding the use of scanning classes at runtime.

Details

• Plugin uses ASM visitor to scan classes avoiding the need to instantiate classes (if some dependencies are available only at runtime)
• Plugin generates a META-INF/services/org.eclipse.che.inject.ModuleFinder file contaning the generated class.
• Plugin generates the class implementing the ModuleFinder interface (getModules() method) at process-classes lifecycle (based on maven lifecycle : process-classes | post-process the generated files from compilation, for example to do bytecode enhancement on Java classes)
• ModuleScanner class also ask ServiceLoader SPI to get modules through ModuleFinder implementations.

then CheBootStrap is able to find all DynaModule modules.

the flow being:
CheBootStrap --> ModuleScanner.getModules() --> ServiceLoader --> GeneratedClass.getModules()

What issues does this PR fix or reference?

#6169

Changelog

workspace master and agent : avoid scan of classes at runtime in order to find DynaModules

Release Notes

N/A

Docs PR

N/A

[benoitf]

FYI there is a merge conflict