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? Regards, Hervé Le mardi 23 août 2016 17:39:28 Christian Schulte a écrit : > Am 23.08.2016 um 15:53 schrieb Paul Benedict: > > I advise to not introduce any new POM version in the 3.x series. Please do > > that in Maven 4.0 where you can blue sky ideas and green field the > > development. Let the 3.x series be the place to shakeout compatibility > > concerns in gracefully handling the new POM version (like appropriate > > warnings and errors). If you do this correctly, you should be able to be > > forward compatible. > > Maybe another example helps. Something everyone agreed upon decades ago. > Java platform versioning. We have jars in central targetting a wide > range of Java platforms. A mix of -target 1.2 to -target 1.8. Everyone > knows what happens when trying to load a Java 7 class with a Java 6 > runtime environment. When incrementing the model version, we are just > setting the target Maven version to 3.4+. There is really nothing > uncommon about that. Just as you cannot load classes targetted at Java 7 > with a Java 6 JRE, you cannot load POMs targetted at 4.3+ with <4.3. > That's all there is to it. We would need to do the same for Maven 4 as > well. Call it target model version 4.1.0 or 5.0.0 or just something not > 4.0.0 and you get Maven behaving exactly like a JRE behaves when asked > to load a class targetted at a higher JRE (load a Java 7 class with a > Java 6 runtime). We are not doing anything uncommon by incrementing the > model version, in my opinion. > > Regards, --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
