Truthfully, I must say a lot of this conversation sounds much like Subversion's client/server architecture:
*) The server has a Repository Format version = "build POM" *) The clients create a Working Copy version on checkout = "consumer POM" *) Two distinct schema series *) A client that understands the Repository Format version converts it locally to a Working Copy *) A client that cannot understand a future Repository Format version cannot convert it to a Working Copy *) An upgraded client can "upgrade" an older Working Copy version to the latest Working Copy version Is this the way Maven wants to go? Cheers, Paul On Tue, Aug 23, 2016 at 4:03 PM, Christian Schulte <[email protected]> wrote: > Am 08/23/16 um 22:52 schrieb Christian Schulte: > > future-proofness, this would need to be reverted as well. Does not solve > > the version range issue, however. This is what makes it impossible to > > deploy a pre-resolved dependency tree to the repository. So maybe that > > is the major issue we need to find a solution for first to get a > > solution solving everything else automatically. > > Pragmatism would make us update the deploy plugin to deploy the > effective model without import, include, version ranges, build, whatever > instead of the on-disk model. This would be breaking backwards > compatibility badly, of course but would solve the major issues so far. > > Regards, > -- > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
