@Robert: agree and we must move forward, just wanted to put a small warning we shouldn't release just to let it go out but more to ensure it is adopted in good conditions
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le ven. 13 nov. 2020 à 09:14, Robert Scholte <[email protected]> a écrit : > This is a good topic, but I suggest to start a different thread for it, so > we can focus here on the version. > Main question is: are there concerns about moving the version of Maven on > master to 4.0.0? > > thanks, > Robert > On 13-11-2020 08:20:25, Romain Manni-Bucau <[email protected]> wrote: > Hmm, this is used by several testing tools and static analyzis tools so the > new pom should likely be at least next to this one but not replace it, like > META-INF/maven/{G}/{A}/pom.original.xml. > Flattening dependencies will likely speed up some tools parsing poms but > tools also parse parent gav and module list (for the part I know) to find > some structure so breaking that part is likely wrong, even for a consumed > pom, this is meta we should keep IMHO. > For instance, when Apache Beam moved from Maven to Gradle, they lost that > and broke some tooling companies had, it requires some effort to compensate > it so I think we shouldn't be that bad, in particular since it does not > cost much to keep it working. > > Romain Manni-Bucau > @rmannibucau | Blog > | Old Blog > | Github | > LinkedIn | Book > > > > Le jeu. 12 nov. 2020 à 22:43, Robert Scholte a > écrit : > > > The pom next to the artifact will be correct and ready to be consumed. > > Only the /META-INF/maven/{G}/{A}/pom.xml will now be the local pom. If > you > > make use of some new features this pom might be incomplete, but AFAIK > there > > are only a few cases where this embedded pom is used. > > > > Robert > > On 12-11-2020 22:38:33, Romain Manni-Bucau wrote: > > Le jeu. 12 nov. 2020 à 22:14, Robert Scholte a > > écrit : > > > > > The discussion is first of all saying the next release should be > > > 4.0.0-alpha-1 (or something similar), so 3.6.3 was the last of the > Maven > > 3 > > > releases unless we need to backport security fixes. > > > What to add to that release is the next discussion. > > > Signing is only relevant for releases, but I think most companies don't > > > sign jars for their internal projects. > > > For those developers the missing features don't matter, but they can > > > benefit from a huge amount of improvements. > > > > > > > I disagree, a release is not only about signing but also letting others > > consume artifacts you produce. > > Having a proof it works for us is important before considering it can be > a > > released feature (on by default). > > Also agree we shouldnt put a lot of features per release so maybe just > the > > pom one in alpha-1? This ensures people can test what we propose and not > > only something else more shining. > > > > > > > Robert > > > On 12-11-2020 21:55:51, Romain Manni-Bucau wrote: > > > Hmm, if it does not work e2e then even an alpha is pointless cause > nobody > > > can test it further than a hello world, was my point. > > > > > > Le jeu. 12 nov. 2020 à 21:01, Robert Scholte a > > > écrit : > > > > > > > I don't expect that signing will work with the the first alpha, but > > that > > > > shouldn't stop us of collecting feedback. > > > > Also we need to have a look at all plugins that do something with the > > > pom, > > > > like every packaging plugin, maven-source-plugin, > maven-release-plugin > > to > > > > ensure the "right" pom is added. > > > > > > > > And for Maven 4.0.0 we shouldn't have milestone releases of plugins > > (even > > > > though they are stable). > > > > There's still enough work to reach 4.0.0, but most likely the first > > > alphas > > > > are already good enough for the majority. > > > > > > > > On 12-11-2020 20:45:09, Romain Manni-Bucau wrote: > > > > Did we already do mvn or mvn plugins (multimodules) release with the > > > > consumer/producer pom feature? > > > > If so +1 to do a v4 with this new feature "for us" and v5 with real > > user > > > > features and align it with the xsd. > > > > > > > > Le jeu. 12 nov. 2020 à 20:00, Robert Scholte a > > > > écrit : > > > > > > > > > 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. > > > > > 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. > > > > > > > > > > WDYT? > > > > > Robert > > > > > > > > > > > > > > > > > > > >
