Re: The use of AssertJ assertions

not sure to understand the problem of dependency update? nothing is urgent for updating a test dependency, security issue maybe but that's a test dependency so less important than a runtime one. On Tue, 22 Jul 2025 at 04:22, Matthias Bünger wrote: > > It doesn't change the effort. It even adds on

Re: The use of AssertJ assertions

+1. AssertJ or Hamcrest provide more helpful error messages. I would not consider it mandatory to use it, but it's a good option to have it. I'm happy that we leave the option to use raw JUnit assertions or AssertJ. On Mon, 21 Jul 2025 at 16:39, Guillaume Nodet wrote: > > When failing, AssertJ pr

Re: [DISCUSS] Maveniverse: the fruits are ripe

Great idea. Not sure to understand what you mean by LAN cache omitted (leaving the code outside?). I On Tue, 22 Jul 2025 at 19:23, Tamás Cservenák wrote: > > Howdy, > > I'd like to start a discussion about ingesting some Maveniverse "skunk > works" projects into Maven project, as they seems utter

Re: [DISCUSS] Maveniverse: the fruits are ripe

I love the idea of bringing some great tools to ASF: happy of this discussion each one will require a separate in-depth evaluation of what it would mean to have some part available as default in Maven CLI distribution vs what would remain as a plugin or stil remain an extension I personally stu

Re: [DISCUSS] Maven 4.0 Namespace Strategy - Breaking Change Timing Discussion

wow, it feels strange to have that discussion in 2025 after 20 years of practice :) it's what we promote through Modello for years https://codehaus-plexus.github.io/modello/modello.html and what we do for each and every descriptor we write changing the practice for POM = the most sensitive pla

Re: Communicate around OSSRH end of life, maven-deploy-plugin and central-publishing-maven-plugin ?

one first step we could try could be adding a "deployToBundle" parameter to the deploy plugin, that would trigger an "at end" behaviour that would build a zip with all the deferred files, instead of copying each file separately then see how just sending the bundle to the target (file: or https:

Re: [DISCUSS] Maveniverse: the fruits are ripe

Hi Tamás, On 22.07.2025 at 11:22, you wrote: Mimir - is currently an extension and provides global cache (solves same problem as split repository, but is not as invasive and is hence, fully compatible even in Maven3 land). It can be made part of resolver and could be always present (and configur

Re: [DISCUSS] Maven 4.0 Namespace Strategy - Breaking Change Timing Discussion

Hello I have no strong expertise in that area, so my question is probably naive. If the XML namespace should not follow the model version, should "http://maven.apache.org/POM/4.0.0"; by changed to "http://maven.apache.org/POM"; for making that clear? If yes, since it would be a breaking chang

Re: [DISCUSS] Maven 4.0 Namespace Strategy - Breaking Change Timing Discussion

Maybe send to the user list? Gary On Tue, Jul 22, 2025, 08:47 Guillaume Nodet wrote: > Hi all, > > I'm writing to initiate a discussion about an important decision regarding > Maven 4.0's namespace strategy. We have two competing approaches > represented by different pull requests, and the *pri

Re: [DISCUSS] Maven 4.0 Namespace Strategy - Breaking Change Timing Discussion

Personal opinion (as a maintainer of several maven based oss projects, including some maven plugins): I think elharos approach is preferable and don't think we should wait until 5.0 to address this. Regards, Per On Tue, 22 Jul 2025 at 14:48, Guillaume Nodet wrote: > Hi all, > > I'm writing to i

[DISCUSS] Maven 4.0 Namespace Strategy - Breaking Change Timing Discussion

Hi all, I'm writing to initiate a discussion about an important decision regarding Maven 4.0's namespace strategy. We have two competing approaches represented by different pull requests, and the *primary question is about timing and acceptable breakage* for this release cycle. Background As we a

Re: Communicate around OSSRH end of life, maven-deploy-plugin and central-publishing-maven-plugin ?

It CAN be deployed as a single zip but it does not have to be. The downside of deploying each module separately is that if one deployment fails then you end up with a "partial" deploy (from the point of view of the whole project) but I think you only end up in this situation in the beginning when y

Re: Communicate around OSSRH end of life, maven-deploy-plugin and central-publishing-maven-plugin ?

And I think that's exactly the problem as the deployment needs to be a single zip file IIUC. Guillaume Le mar. 22 juil. 2025 à 12:28, Per Nyfelt a écrit : > > Hi Tamas, > > I think it would work. Each part is zipped up and deployed e.g. assuming > you have a multimodule project like this: > Aggr

Re: [DISCUSS] Maveniverse: the fruits are ripe

Hi all, as the big majority of Maven users has no clue about extensions or how to configure plugins, I think every OOTB / build-in improvement is great. Matthias Am 22.07.2025 um 11:22 schrieb Tamás Cservenák: Howdy, I'd like to start a discussion about ingesting some Maveniverse "skunk wor

Re: Communicate around OSSRH end of life, maven-deploy-plugin and central-publishing-maven-plugin ?

Hi Tamas, I think it would work. Each part is zipped up and deployed e.g. assuming you have a multimodule project like this: Aggregator - common - subA (depends on common) - subB (depends on common) Deploying all of this would mean 4 zip files are created and published 1. The aggregator

Re: [DISCUSS] Maveniverse: the fruits are ripe

sounds good to integrate it, also happy if it hits maven 3 at some point Romain Manni-Bucau @rmannibucau | .NET Blog | Blog | Old Blog | Github

[DISCUSS] Maveniverse: the fruits are ripe

Howdy, I'd like to start a discussion about ingesting some Maveniverse "skunk works" projects into Maven project, as they seems utterly useful and wanted (and are proven): Mimir - is currently an extension and provides global cache (solves same problem as split repository, but is not as invasive

Re: Communicate around OSSRH end of life, maven-deploy-plugin and central-publishing-maven-plugin ?

Per, You cannot publish to central using plugin bound to lifecycle as it will be invoked in every module/subproject... Portal needs "at end; all artifacts" kind of operation and Maveniverse Njord does that without interference to your build. Maven4 has improved lifecycle with "after:all" but Mave

Re: Communicate around OSSRH end of life, maven-deploy-plugin and central-publishing-maven-plugin ?

Hi, How about adding a deployToCentral (or similar) goal to the maven-deploy-plugin that uses the new API so that this is supported "natively"? I would be willing to implement it if you think it's a good idea. Regards Per On Tue, 22 Jul 2025 at 10:39, Jon Harper wrote: > Hi Hervé, > thanks for

Re: Communicate around OSSRH end of life, maven-deploy-plugin and central-publishing-maven-plugin ?

Hi Jon, That one is "transitional" solution and Sonatype itself states they hope will be used by projects while transitioning only. I'd not consider it as final solution. T On Tue, Jul 22, 2025, 10:39 Jon Harper wrote: > Hi Hervé, > thanks for looking into it. Did you try the sonatype compatib

Re: Communicate around OSSRH end of life, maven-deploy-plugin and central-publishing-maven-plugin ?

Hi Hervé, thanks for looking into it. Did you try the sonatype compatibility service ? https://central.sonatype.org/publish/publish-portal-ossrh-staging-api Also, while the governance and roadmap of central-publishing-maven-plugin is not open, the code itself is OSS (uses the apache license v2 as