Add support for "pseudo" dependencies

[maverick1601]

I am currently missing a feature to add "pseudo" dependencies in the Initializr configurations, which will not really get added to Maven/Gradle build as dependency, but rather are solely used as a trigger for ProjectContributor or BuildCustomizer implementations.
For instance, if I want to let the user select an additional build plugin, such as jQAssistant, which isn't represented by a real dependency, but rather manifestates itself as a new plugin configuration in the pom.xml, I have to give the dependency dummy coordinates and remove it from within the BuildCustomizer, once plugin configuration is done.
Ideally, the dependencies would allow me to select such "features" for a project as well. Having to given them unique dummy coordinates and removing them in code, however, is cumbersome and error-prone.
I am proposing to add a special "pseudo" scope to the metadata Dependency, which is handled differently, i.e. not added to the actual dependencies of the build. This way, customizers could simply be triggered using the dependency conditions w/o having to worry about the actual coordinates and removal.

[snicoll]

Thanks for the suggestion but I am not keen to change the API in that direction. The current contract for Dependency is to really represent a dependency as how the concept is defined in Maven and Gradle. In particular, Dependency is not a generic way of gathering user's opinions.

If you need to add an additional plugin and you want that to be an option, you should add such option to the UI and react accordingly. This may prove to be challenging with the latest API and if you're interested to explore that route, we're more than happy to discuss that on our Gitter channel