Both these use cases sound like adding incredible complexity to support less than 1% situations, and worse, encouraging monolithic builds.
In the first case, the module creating a shaded jar can mark its constituent jars as optional; preventing the transitive dependencies. In the second case, It would be better for the plugin be an independent build to encourage re-use of that plugin. > There are two sets of problems that, assuming we want to fix, both need > some way to rally a concurrent multimodule build at. > > 1. There is the shade like class of problems, where a plugin wants to > modify the effective transitive dependencies of a module. > > 2. There is the extensibility class of problems, where people want to build > a plugin and consume the same plugin in one reactor. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
