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]
