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 > > > > > > > > > > > > > >
