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. +1 > 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 consumption) > 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 > > <https://issues.apache.org/jira/browse/MNG-4463> > > 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, Hervé > > Regards, --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
