The Work Item Definitions are actually populated and being consumed by different workbench components, which finally results in same the functionalities and capabilities being duplicated across the platform and potentially causing issues on any further concurrent interactions.

AFAIK these are the components that manage WID:

• jbpm-designer
• stunner
• case projects (jbpm-wb)
• jbpm (flow) at some point?

AFAIK these are the capabilities expected for the WID management:

• Installation of some default WID for each project (Email, Log, FTP...)
• Installation of the service repository items specified in the jvm system properties
• Notice by "Installation" means
  • Deploying the assets into VFS - icons, descriptors (json), libraries (jar)
  • Installation into current KIE project - pom, dependencies, etc
• Lookup (or CRUD) services (by path, project)
• Populate some WID registries (cache) - At runtime, some components like any of both designers, need to consume the registered WID's, which acttually implies both consuming remote backend services and producing local caches
• UI for the installation from the remote service repositories - repository explorer widget (at KIE level)

So at this point, these are (at least) goals for this task:

• Create some common WID module that provides
  • Common API
  • Lookup service (search/get)
  • Registration service
  • Deployment service (default, from system properties)
  • Common WID registry for runtime access (caché)
• Refactor the WID code stuff, at least, from jbpm-desginer, stunner, jbpm-wb (case projects) into some common module
• Avoid the need for both designer, or any other components, to do the registration, deployment or whatever common action related to WID's
• (Optional) - Support for importing "all" items from an external service repository, rather than having to specify each of the taskName's