Usage ${parameter} in <pluginRepository> and <repository>is prohibited in Maven 4

[sudo-mkdir]

Affected version

4.0.0-rc-4

Bug description

I'm not sure if that can consider as a bug or rather a discussion.

Use case and example

Because in various CICD pipelines we're pushing artifacts to different repos, or the company decides to change nexus url, so we only switch it in CICD pipeline, rather than in the code itself due to many repositories.
Currently in all our maven projects we have

<properties>
  <repository.id>Nexus Repository</repository.id>
  <repository.url>https://nexus.acme.com</repository.url>
</properties>

   <pluginRepositories>
      <pluginRepository>
         <id>${repository.id}</id>
         <url>${repository.url}</url>
      </pluginRepository>

as well as

  <repository>
   <id>${staging.repository.id}</id>
    <url>${staging.repository.url}</url>
 </repository>

Behavior

Maven 3

Maven 3 properly resolved ID as well as URL and we can override those during CICD pipeline

Maven 4

Print's out error
[ERROR] Maven model problem: 'pluginRepositories.pluginRepository.[${repository.id}].url' contains an unsupported expression (only expressions starting with 'project.basedir' or 'project.rootDirectory' are supported)

---

Is this working as designed? Where I can find additional doc regarding this change?

[cstamas]

As the error says, otherwise your build is not reproducible. All the repositories needs to be known beforehand, before build is about to start, otherwise you may end up with different build outputs.

Let's turn it around: what are you trying to achieve?

[sudo-mkdir]

@cstamas Thanks for your response.
In our case we have around 100 git repositories, let say 50 of them has more or less active work. From time to time company migrates from one nexus instance to another. With the last migration, we've decided to parametrize URL and IDs and pass them during CICD pipeline. So now, we have only one place we need to switch in case of the migration.

I'll need to dive more into concept of reproducible builds, but quoting https://maven.apache.org/guides/mini/guide-reproducible-builds.html

A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.

Build environment may be the same, but environment variables may change, right? :)

[gnodet]

@cstamas Thanks for your response. In our case we have around 100 git repositories, let say 50 of them has more or less active work. From time to time company migrates from one nexus instance to another. With the last migration, we've decided to parametrize URL and IDs and pass them during CICD pipeline. So now, we have only one place we need to switch in case of the migration.

I'll need to dive more into concept of reproducible builds, but quoting https://maven.apache.org/guides/mini/guide-reproducible-builds.html

A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.

Build environment may be the same, but environment variables may change, right? :)

What if you move the repositories definitions in settings ? That would become environment specific, and would allow the projects to build. Though, that would not allow them to be actually built without the correct settings. Not sure which one wins when the same repository id is used in the project and in settings, I think (hope) it's settings. Which would mean, you can also put the repo in the project, and override it in settings if you migrate the repository url.

[cstamas]

Build environment may be the same, but environment variables may change, right? :)

Right, they may change, but should not be undefined sry lapsus, is defined in your case, but expression is not allowd.

@gnodet what if we check only the fact that repo ID and URL "have value" (are successfully interpolated, there are no placeholder leftovers -- all of them had values)?

[gnodet]

Fixed by #11140 and #11210, at least for the URL part.