Le lundi 16 novembre 2020, 17:15:39 CET Michael Osipov a écrit : > Am 2020-11-13 um 18:31 schrieb Karl Heinz Marbaise: > > Hi, > > > > On 12.11.20 20:00, Robert Scholte wrote: > >> Hi, > >> > >> It is already several years ago where we started discussing about > >> Maven Next Generations. > >> Clearly we needed to work on the pom, because over time we're facing > >> more and more limitations. > >> For (Maven) Central the Model 4.0.0 will be required pom format, > >> there's no discussion about that. So we needed a new architecture > >> where there's a local pom that is transformed to Model 4.0.0 or where > >> it can be generated. > >> With the implementation of MNG-6656 and the improvement with MNG-6957 > >> we've made the first and important steps based on pom transformation. > >> If this concept proofs itself, we can start thinking about enhancing > >> the pom model. > >> > >> When talking about Model 5.0.0 it looked like it would be great to > >> introduce it for Maven 5. There was even a period where we thought > >> about skipping Maven 4, just to sync the Model version with the Maven > >> version. > >> However, we discovered that this would be a huge change, and that we > >> would probably need a couple of Maven 4 releases before moving to > >> Maven 5. Maven 4 would consist of preparation releases. > >> I've started writing the build/consumer to proof that the it is indeed > >> possible to separate the local pom from the distributed pom, even > >> though they both are currently still Model 4.0.0 compatible. > >> The original idea was: > >> Maven 3: build/consumer feature disabled by default > >> Maven 4: build/consumer feature enabled by default > >> > >> Maven 5: Model 5 > >> > >> We were worried that this wouldn't give us enough feedback. > >> maven-integration-testing shows that build/consumer does work. There > >> should be enough trust to enable it by default, it shouldn't impact > >> existing projects (the last find by Michael was actually great. It > >> demonstrated the effect when using threads. The fix made sense and > >> Maven was stable again). But it is simply not enough. We need much > >> more feedback. > >> > >> Meanwhile other improvements have been done, that has impact: > >> - new behavior of reactor commandline arguments > >> - upgrade of default versions of plugins per packaging type > >> - requiring Java 8 > >> - Maven wrapper > >> - there's a PR waiting that will shift the logic of the > >> ProjectBuilder/ModelBuilder. As this is quite important for more > >> people to understand, I'll record a Q&A with Maarten+Martin soon and > >> share it with you. > > > > it would be nice to have a kind of information here on the dev list to > > see what kind of consequences this has? > > > >> There are probably more, but all these already defend my opinion about > >> the next Maven version. > >> > >> To me it is not a Maven 3 anymore, we're reached a point where we > >> should start calling it Maven 4. > >> The next release should probably have an alpha suffix, just to give > >> users the chance to do alpha testing. > > > > With a new major version we start to produce high expectations with 4.X > > > > I would suggest to do 3.7.0 first with support: > > > > - new behavior of reactor commandline arguments(?) ? > > - Maven 3: build/consumer feature disabled by default (??) > > > > Needs more testing of corse... > > cause this would help a lot of people... make it easier > > and get rid of flatten part.. > > - Signing of artifacts etc. needed to solved first. > > > > - requiring Java 8 (not a big issue; done for several Maven minor > > versions before) > > - Maven wrapper > > > > getting all that above working fine... and mark a number of classes / > > parts/modules as deprecated ... which has not being done yet. > > > > Also I suggest to 3.7.0 instead of 4.0.0 for this cause otherise the > > adoption is more hesitant than for a 4.0.0 which is a major version > > upgrade.... > > > > > > Maven 4.0.0 > > > > - build/consumer feature enabled by default > > - Remove old stuff > > - break things and improve the build pom ... > > - Remove maven-compat .. ? introducing maven-compat3 ?.. > > - Maybe JDK 11 base? (LTS?) just a thought > > - > > > > Also making a 3.7.0 before so we can learn things related to > > build-consumer pom before going to Maven 4.0.0 ....where we can break > > things which we can not in 3.7.0 ... > > Hi Karl, > > I don't think that that we should press such an amount of changes into a > minor release. If you want to have a 3.7.0 why not branch off 3.6.3 and > cherry-pick selected changes.... going to 4.0.0-alpha is a way to avoid additional complexity of feature flags and an explicit testing period: even if we feature-flag build/consumer feature, there are many changes that require more serious testing IMHO than going directly to 3.7.0 with implicit high confidence
> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
