So I think we have then opportunity to model this correctly and we have something similar already in a WAR. We have a handler that clips all transitive dependencies. There would be a bit more work but if we make a separate packaging, build out the classpath correctly during the build we can probably eliminate the need for the dependency reduced POMs as we don't need it for WARs. Again, obviously not the same but I think this is the route to go.
jvz > On Oct 27, 2015, at 7:40 AM, Igor Fedorenko <[email protected]> wrote: > > I think this only highlights the need to have immutable core model. The > bundle plugin has no way to know how the shade plugin manipulates the > pom and the generated bundle manifest will be based on original project > model. (assuming I understand your suggested usecase) > > -- > Regards, > Igor > >> On Tue, Oct 27, 2015, at 10:12 AM, Benson Margulies wrote: >> On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko <[email protected]> >> wrote: >>> Did you really mean "the core model has to be mutable"? The rest of your >>> message appears to suggest you do not want the model to be mutable, but >>> I am not sure. >>> >>> In any case, I think the core model must not be mutable. If the core >>> model is mutable, this means pom.xml is not the ultimate source of truth >>> about the project. It will not be possible to look at the pom and tell >>> anything conclusively about the project if we allow plugins make random >>> changes to the model. Tools like m2e will not be able to display project >>> dependency hierarchy with any certainty, nor, in fact, be able to >>> implement workspace dependency resolution. >>> >>> As for the shade plugin, assuming I understand the usecase correctly, >>> dependency reduced pom is semantically equal to pom with all "reduced" >>> dependencies marked as optional=true. It may be okay for the shade >>> plugin to require users explicitly add optional=true to relevant >>> dependencies and fail the build if this is not the case. Maybe provide a >>> way to automatically change source pom.xml on filesystem before failing >>> the build too. >> >> I've tried to do this by hand. It yields a variety of downstream >> problems. For example, OSGi tools take optional dependences as >> optional OSGi dependences, not as removed dependencies. >> >> So I think we need another approach to this dilemma; shade, if nothing >> else, is a critical enabling technology, and having the downstream >> builds in the reactor work with the output is essential. >> >> >>> >>> -- >>> Regards, >>> Igor >>> >>>> On Tue, Oct 27, 2015, at 09:35 AM, Jason van Zyl wrote: >>>> The core model has to be mutable. I think there can be an ancillary model >>>> that carried other types of information like the dependency reduction. >>>> But mutation and re-consumption within the reactor I think is a bad idea >>>> and the complication enumerated below seems fairly extreme. Do you have a >>>> concrete use case in mind? >>>> >>>>> On Oct 27, 2015, at 2:41 AM, Stephen Connolly >>>>> <[email protected]> wrote: >>>>> >>>>> Context: MNG-5899 [1] which was originally reported as MSHADE-206 [2] >>>>> >>>>> I understand why the change[3] was made... but this change breaks >>>>> about 80-90% of the use cases for the shade plugin... >>>>> >>>>> Is there any way we can consider a compromise? >>>>> >>>>> I think it should be permitted for a plugin to replace the project >>>>> model with a dependency reduced model, i.e. one where the transitive >>>>> dependency tree is either the same or a strict subset of the >>>>> transitive dependency tree of the original. >>>>> >>>>> If a plugin makes such a substitution then the reactor build order >>>>> will remain unaffected but the classpaths of downstream modules would >>>>> be affected. >>>>> >>>>> As I see it, if we were to try and permit such substitutions, we would >>>>> need to augment the mojo API: >>>>> >>>>> * A Mojo would need to advertise that it performs Project Dependency >>>>> Reduction, because... >>>>> >>>>> * The build plan would need to delay concurrent builds of modules that >>>>> depend on the project using such a mojo until after the mojo has >>>>> completed execution >>>>> >>>>> * The replacement of the project model would have to be via a specific >>>>> API call such that validation of the transitive dependency tree rule >>>>> was maintained as well as restricting usage of that API to mojos that >>>>> have advertised their use of dependency reduction. >>>>> >>>>> Is there anything else that we would need to consider if we were >>>>> implementing the above? >>>>> >>>>> (Shade would not be the only consumer of this API as I see it, for >>>>> example the flatten maven plugin may well want to consume this API >>>>> also...) >>>>> >>>>> WDYT? >>>>> >>>>> [1]: https://issues.apache.org/jira/browse/MNG-5899 >>>>> [2]: https://issues.apache.org/jira/browse/MSHADE-206 >>>>> [3]: >>>>> https://github.com/apache/maven/commit/be3fb200326208ca4b8c41ebf16d5ae6b8049792 >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>> >>>> Thanks, >>>> >>>> Jason >>>> >>>> ---------------------------------------------------------- >>>> Jason van Zyl >>>> Founder, Takari and Apache Maven >>>> http://twitter.com/jvanzyl >>>> http://twitter.com/takari_io >>>> --------------------------------------------------------- >>>> >>>> Simplex sigillum veri. (Simplicity is the seal of truth.) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
