Should Mutiny be an optional dependency?

[DavideD]

Follows #996

This would mean move the code that uses Mutiny in a separate module.
We could require users to include it in their project as an additional dependency (option 1), or we could at least make it so that it can be removed (option 2).

I prefer option 2 because we recommend using Mutiny over CompletionStage usually.

This means that we would need a way to plug new interfaces. I don't think it's possible at the moment without changing the code base but it shouldn't be too hard to add this functionality. This would make it easier for people to use the reactive interface they prefer and maybe contribute to new external modules.

@gavinking, @Sanne ?

[Sanne]

Initially this was modular, but Gavin didn't like the notion that people need to know which modules to import - and I think he has a valid point.

+1 for option 2 by suggesting people can exclude the dependency if they don't want it.

So it could be resolved by a simple suggestion in docs.

A better solution - but which would require more work - is to address the fact that I don't believe the source code organization should match the way libraries are consumed.

So for example we could have different source modules, so to ensure among others that the core components actually do compile cleanly w/o having Mutiny on the classpath, and then trick the build scripts into merging the multiple units into a single jar (or a couple of jars - my point is that build tools imply a 1:1 mapping between compilation units and jars, and we should break away from this for sake of better usability).

But I can't say this effort seems worth it - especially since we like Mutiny and I believe it should be available by default, so all this work would only be for the sake of making it easier to remove, optionally.

[DavideD]

I like the idea of different sources for this case. Not sure about the complexity.