Currently a base aspect of Passage Core is represented by a feature, composed of all the functionality plug-ins for the aspect support. For instance, it we take keys domain, appropriate feature will comprise api, model, ecore, core plug-ins to facilitate the aspect runtime and development, but also all the ui plug-ins empowering the domain presence in UI products.
This way of feature composition lays unexpected dependency burden on headless products that rely on such an aspect: target platform for such a product doomed to refernce fundamental ui libraries despite the product's headless state.
The agreed solution is to separate each such feature to several, named after use case (cli for headless support, gui for graphical ui support, etc).
Currently a base aspect of Passage Core is represented by a feature, composed of all the functionality plug-ins for the aspect support. For instance, it we take
keys
domain, appropriate feature will comprise api, model, ecore, core plug-ins to facilitate the aspect runtime and development, but also all the ui plug-ins empowering the domain presence in UI products.This way of feature composition lays unexpected dependency burden on headless products that rely on such an aspect: target platform for such a product doomed to refernce fundamental ui libraries despite the product's headless state.
The agreed solution is to separate each such feature to several, named after use case (cli for headless support, gui for graphical ui support, etc).