Drop expressions in repository URLs and manage version of Maven Install Plugin

[mthmulders]

Following the conversation in #84, here's a pull request that does the trivial changes:

• Replace expressions in URLs with their actual values.
• Pin versions of plugins

There's one more thing that must be done. If you would attempt to make a release, it would fail with

The maven-gpg-plugin is not supported by Maven 4. Verify if there is a compatible signing solution, add -Dmaven.experimental.buildconsumer=false or use Maven 3.

The Sign Maven Plugin looks like a candidate replacement. Its website says it works on Maven 3.6 and is ready for Maven 4 with Consumer POM.

Since the Sign Maven Plugin does not look like a drop-in replacement to me, and since it is not part of the ASF Maven project, I chose not to include it (yet) in this PR. If the Eclipse EE4J project decides to adopt that plugin, it could be part of this PR.

[ivargrimstad]

Thanks, @mthmulders!

[chkal]

LGTM. Although, I wonder if any project customizes sonatypeOssDistMgmtNexusUrl by changing the value via the command line for some reason.

[mthmulders]

Although, I wonder if any project customizes sonatypeOssDistMgmtNexusUrl by changing the value via the command line for some reason.

Interesting point. If they do, I think their path forward would be to add the corresponding <repository>, <pluginRepository>, or <snapshotRepository> elements to their project POM. But how can we make them aware of it?

[pzygielo]

Although, I wonder if any project customizes sonatypeOssDistMgmtNexusUrl by changing the value via the command line for some reason.

Interesting point. If they do, I think their path forward would be to add the corresponding <repository>, <pluginRepository>, or <snapshotRepository> elements to their project POM.

IMO - the actual definitions of repositories that are EF infrastructure dependent are the only reason to inherit from this parent... Why would one change sonatypeOssDistMgmtNexusUrl in such case?

But how can we make them aware of it?

Bump the version to 2?

[chkal]

IMO - the actual definitions of repositories that are EF infrastructure dependent are the only reason to inherit from this parent... Why would one change sonatypeOssDistMgmtNexusUrl in such case?

I'm not sure if anybody is actually changing the repository URL this way. I was just always wondering why the URL was a maven property and not simply inlined into the corresponding <repository> section. And my guess back then was that it would allow changing the repository URL via the command line. But any way: I'm not sure if anybody is doing this.

[pzygielo]

I was just always wondering why the URL was a maven property and not simply inlined into the corresponding <repository> section. And my guess back then was that it would allow changing the repository URL via the command line.

• My guess is that there was DRY idea behind Moved Nexus URLs to properties. #57.

[pzygielo]

Now - with maven 4 helpfully rejecting expressions in url - if sonatype changes host name or EF migrates to different service - update in 6 places will be needed. Good.

[ivargrimstad]

If no-one objects, I'll bump the version number to 2.0.0 and prepare a release after merging this.

[mthmulders]

We haven't yet addressed the issue of signing artifacts. I guess we should consider solving that before bumping to 2.0.0 and releasing.

[pzygielo]

We haven't yet addressed the issue of signing artifacts. I guess we should consider solving that before bumping to 2.0.0 and releasing.

There is also NEXUS-36533/MNG-7627.

It might take few more days before final maven 4 is published. Until then child projects can still use maven 3, and do some staging and releasing to confirm that removed property does not hurt them.

Signing and deploying issues can be solved separately and can result with new release(s).

However - the subject of this PR could be changed a bit as this is not complete maven 4 preparation we see.

[mthmulders]

However - the subject of this PR could be changed a bit as this is not complete maven 4 preparation we see.

How about "Drop expressions in repository URLs to prepare for Maven 4"?

[pzygielo]

How about "Drop expressions in repository URL and manage m-install-p"?

This Maven 4 part is not important IMO.

[lukasj]

Although, I wonder if any project customizes sonatypeOssDistMgmtNexusUrl by changing the value via the command line for some reason.

Interesting point. If they do, I think their path forward would be to add the corresponding <repository>, <pluginRepository>, or <snapshotRepository> elements to their project POM.

It's unlikely being about projects themselves but rather about organizations rebuilding projects from scratch and republishing them on their own infra to their own internal repository for whatever reason behind that (I can imagine security, various regulations etc). Being able to override the default repo through the simple command line property makes this easy to do. I doubt security policies of such organizations allows exposing names/ips of internal servers on the internet/public places.

[pzygielo]

It's unlikely being about projects themselves but rather about organizations rebuilding projects from scratch and republishing them on their own infra to their own internal repository for whatever reason behind that (I can imagine security, various regulations etc). Being able to override the default repo through the simple command line property makes this easy to do. I doubt security policies of such organizations allows exposing names/ips of internal servers on the internet/public places.

Nothing like that was mentioned when property was introduced. Such organizations will need to adapt for this. Switch to using different profile with custom repositories defined.

And - to allow to use property in repository definition again - to raise MNG for maven to do so. It's not up to this project.

[lukasj]

Nothing like that was mentioned when property was introduced. Such organizations will need to adapt for this. Switch to using different profile with custom repositories defined.

Probably nobody explicitly asked or it was obvious that the pattern used in various oss-parents used by Sonatype is being followed. JBBUILD-567 (behind this commit) may have some info too, but who knows, the issue is not public.

And - to allow to use property in repository definition again - to raise MNG for maven to do so. It's not up to this project.

Assuming the author of this PR is a maven committer, he can do it should he see the need for it.

[pzygielo]

There's one more thing that must be done. If you would attempt to make a release, it would fail with

The maven-gpg-plugin is not supported by Maven 4. Verify if there is a compatible signing solution, add -Dmaven.experimental.buildconsumer=false or use Maven 3.

I suppose it's no longer the case, as with currently managed plugin and with maven 4.0.0-beta-3 they seem to cooperate:

[INFO] --- gpg:3.1.0:sign (default-cli) @ project ---
[INFO] Signing 2 files with default secret key.

[mthmulders]

I suppose it's no longer the case, as with currently managed plugin and with maven 4.0.0-beta-3 they seem to cooperate:

[INFO] --- gpg:3.1.0:sign (default-cli) @ project ---
[INFO] Signing 2 files with default secret key.

Correct. That statement is roughly two years old. At the time of writing, there was no plan to make the Maven GPG Plugin work with Maven 4, but a lot has changed since.