Re: [DISCUSS] Next release should a pre Maven 4.0.0

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 m

Re: [DISCUSS] Next release should a pre Maven 4.0.0

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

Re: [DISCUSS] Next release should a pre Maven 4.0.0

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 di

Re: [DISCUSS] Next release should a pre Maven 4.0.0

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 m

Re: [DISCUSS] Next release should a pre Maven 4.0.0

The Dependency Resolution Strategy must exist somewhere Maven Artifact Resolver, my guess is the org.eclipse.aether.collection package. On 12-11-2020 21:41:57, Andres Almiray wrote: Hi Robert, Understood. I remember our discussion at JAlba last year about the resolution strategy options at hand.

Re: [DISCUSS] Next release should a pre Maven 4.0.0

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 feed

Re: [DISCUSS] Next release should a pre Maven 4.0.0

Hi Robert, Understood. I remember our discussion at JAlba last year about the resolution strategy options at hand. Do you think it would be possible to expose the resolution strategy hooks in a way that may be overridden by an extension/plugin? That way alternate RS can be prototyped and tested d

Re: [DISCUSS] Next release should a pre Maven 4.0.0

Hi Andres, BanDuplicatePomDependencyVersions is easy to add. IIRC now it is a warning, I don't mind changing it to make it break the build. DependencyConvergence is way too difficult to achieve with the larger projects. RequireUpperBoundDeps sounds reasonable as warning, although I'm sure if th

Re: [DISCUSS] Next release should a pre Maven 4.0.0

Woohoo! While I'd love for Maven moving forward to 4 I was hoping to see the enforcer plugin (or at least some of its rules) baked into core, for example BanDuplicatePomDependencyVersions DependencyConvergence RequireUpperBoundDeps I'm sure that enabling these rules by default will break thousan

Re: [DISCUSS] Next release should a pre Maven 4.0.0

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.

Re: [DISCUSS] Next release should a pre Maven 4.0.0

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

[DISCUSS] Next release should a pre Maven 4.0.0

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

Re: Maven issue with JDK16 - javac and javadoc

Yes, the problem is about javac with "no-fork + -Xdoclint" using no-fork is not a good option because it slows down a lot big multi module projects Enrico Il giorno gio 12 nov 2020 alle ore 13:55 Romain Manni-Bucau < rmannibu...@gmail.com> ha scritto: > @Graham I guess you can force the compile

Re: Maven issue with JDK16 - javac and javadoc

@Graham I guess you can force the compiler to fork and force doclint to none in javadoc plugin config (ensure to use a recent version). Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Gith

Re: Maven issue with JDK16 - javac and javadoc

On 12 Nov 2020, at 14:03, Enrico Olivelli wrote: > I have fallen into this issue about Maven + Maven Compiler Plugin + JDK16 > > This is the issue on JDK issue tracking > https://bugs.openjdk.java.net/browse/JDK-8253996 > > Basically -Xdoclint:missing does not work anymore when you run javac in

Re: Maven issue with JDK16 - javac and javadoc

+1, got some weirdness on j11 too. We should really have a way to ignore these errors, it is too impacting, in particular when javadoc are only deployed to make central or our nexus happy. Romain Manni-Bucau @rmannibucau | Blog

Maven issue with JDK16 - javac and javadoc

Hi folks, I have fallen into this issue about Maven + Maven Compiler Plugin + JDK16 This is the issue on JDK issue tracking https://bugs.openjdk.java.net/browse/JDK-8253996 Basically -Xdoclint:missing does not work anymore when you run javac inside the same JVM as Maven core, because the JVM lack