maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Cooke <fred.co...@gmail.com>
Subject Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs
Date Mon, 29 Aug 2016 22:33:57 GMT
I fail to see how any such flattening can do away with interpolation. Your
typical nonlib project has say 5-100 deps, each of which would have a flat
tree that needs to be compared with and resolved against the others. I can
see it speeding things up due to having all of the information for just the
declared number after that many downloads, but you can't have simple code
that just gets stuff. Not going to work.

Or am I blind?

On Tue, Aug 30, 2016 at 10:27 AM, Christian Schulte <cs@schulte.it> wrote:

> Am 08/30/16 um 00:16 schrieb Paul Benedict:
> > 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.
>
> It's not my proposal but I agree to what is proposed. This whole
> discussion started because users have requested to revert commits due to
> compatibility issues. They want to keep such "faulty" behaviour. If they
> want to fix it, they can deploy a new version using a more recent Maven
> version. The older Maven version will then also see this new behaviour.
> If the consumer pom contains the complete resolved dependency tree, the
> code interpreting that data is not much more than downloading some files
> from some repository. Yes. Repository information needs to be part of
> that consumer pom as well. So the resolved dependency tree including
> repository information from where to get the resolved artifacts. And we
> also need to find a way to handle version ranges.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message