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. 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. 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. 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. Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
