No, I meant immutable. > On Oct 27, 2015, at 6: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. > > -- > 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] >
Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- Three people can keep a secret provided two of them are dead. -- Benjamin Franklin --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
