maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <>
Subject Re: POM Model version 4.1.0 in 3.4.0-SNAPSHOTs
Date Wed, 24 Aug 2016 06:23:15 GMT
Le mardi 23 août 2016 22:52:18 Christian Schulte a écrit :
> Am 08/23/16 um 22:33 schrieb Hervé BOUTEMY:
> > yes, people providing libraries have this big choice to do: when to
> > upgrade
> > minimum JRE version for consumers.
> > 
> > yes, we can add them another new big decision to take: when to upgrade
> > minium Maven version to consume the library?
> > 
> > but with consumer pom vs build pom, we should be able to avoid this new
> > decision: build pom can evolve (having a prerequisite to builkd the
> > library is not an issue), consumer pom stays compatible
> > 
> > 
> > Now, I don't yet investigated the new include feature, with a simple
> > example of the difference between include and import, and see if a build
> > pom with include could be transformed into a consumer pom without it: is
> > it feasible?
> It could be transformed only when not using version ranges.
version ranges: I hate version ranges... :)
notice: what is the issue with version ranges? the generated consumer pom can 
contain version ranges, since it is a long-standing feature

> That is -
> the deployed POM just does not contain any import or include scope
> dependencies any more but the effective dependency management after
> inclusion or import.

> I really like the idea of deploying only the
> information necessary to consume a project and have an option of using
> something completely different to do the build.
yes, that's the general idea: do like other build tools that publish to 
central (with a generated minimal pom, not intended for build but only 

> There are two big issues
> all solutions presented so far do not solve. Version ranges and same
> syntax but different semantics. There is some good news to this as well.
> Currently the import scope feature does not support using version
> ranges! That got implemented on current master due to
> <>
> by me but has not been released so far. So Maven 3.4.0-SNAPSHOT
> currently supports using version ranges in import declarations. This
> will make it impossible to deploy a POM with the imported dependency
> management flattened no matter how that has been built.
I don't like classical dependencies version ranges, but the idea of such 
feature for imports looks even worse: the dirty dependency tree will be really 
huge, I imagine. And if the content of imported pom changes in the ganre, I 
fear the result is quite un-predictible

> Heading for
> 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.
why does it need to be pre-resolved?

notice: this is another good reason to finish Aether import first... :)



> Regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message