On Tue, Oct 27, 2015 at 10: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)
At one extreme, we could declare that things like shade can't fit into the reactor model. If you need to produce an artifact with a pom different than the pom you start from, you need to build it separately, put it into a repo, and consume it in other builds. We have this situation because people don't like that; they want to incorporate changes to the dependency tree in the reactor process. That's what you'd have with a 100% immutable model. So, we could ask, is there anything we can design that supplies the feature without making a giant mess? > > -- > 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]
