Christian, I could argue that's not much different than today. The "consumer pom" -- no matter how much you distill or flatten it -- will still require processing. Data is useless without an interpretation. A Maven client will still have to have to process it, and there will likely be bugs in that code, too. So please forgive me for being skeptical of what's being proposed.
I see a deployed faulty "consumer pom" to be more more harmful than generating it locally on demand. At least with the local one I can upgrade my client to fix a dependency calculation. There will be no such relief in the case of your proposal. Cheers, Paul On Mon, Aug 29, 2016 at 4:56 PM, Christian Schulte <c...@schulte.it> wrote: > Am 08/29/16 um 23:35 schrieb Paul Benedict: > > Robert, I am mostly in agreement here. However, the big downside to > > deploying the calculations is that they are forever. Furthermore, > deploying > > the "consumer pom" takes away the ability for a newer Maven client with > > resolution bug fixes and/or optimizations to build a leaner and more > > efficient calculation. > > That's exactly what everyone is requesting. Once deployed, things are > forever. We are asked to not change anything in Maven in a way leading > to different build results than an older Maven version would produce > when operating on the same pom again and again. That's the way out of > it. The content of those consumer poms can change when using a more > recent Maven version. Once deployed, all Maven versions always see the > same result, even if the version in use would have generated a different > consumer pom (containing new features/bug fixes). > > Regards, > -- > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
