[MNG-4173] Remove automatic version resolution for POM plugins

[jira-importer]

Benjamin Bentmann opened MNG-4173 and commented

Maven 3.x will no longer try to automatically find the version for plugins specified in the POM, i.e. the effective POM must declare a version for each plugin used for the sake of reproducible builds. Omitting the plugin version will raise in error.

---

Affects: 3.0-alpha-3

Issue Links:

• MNG-4205 Remove support for plugin metaversions RELEASE and LATEST

• MNG-3358 Require explicit plugin versions
  ("supercedes")

Remote Links:

• Page
  

3 votes, 8 watchers

[jira-importer]

Benjamin Bentmann commented

Done in r774327.

[jira-importer]

Benjamin Bentmann commented

Post-poned to 3.1.

[jira-importer]

Benson Margulies commented

This will break a lot of builds. Arguably it should come in a box, like 4.0, that has many better reasons for breaking a lot of builds.

[jira-importer]

Zoltan Farkas commented

Would it be possible to have this available as a option before 4.0? The option default would be backwards compatible... so that it would have less of an impact.

I find it very important to have reproducible builds...

see: http://stackoverflow.com/questions/25983852/maven-javadoc-plugin-breaks-mvn-releaseperform for detail...

[jira-importer]

Elliotte Rusty Harold commented

This is done, right?

[jira-importer]

Ran Biron commented

Any chance someone can answer https://stackoverflow.com/questions/60179420/set-specific-maven-dependency-to-latest-release-during-local-development ? 

Summary:  local developer build (as opposed to CI builds) on a multi-module maven project sometime need to use released components without rebuilding them. however, having the pom.xml modified on developer can lead to merge conflicts (on pull) or accidentally overriding the correct SNAPSHOT version in SCM (by including the file on push).

Version scanning is extremely slow and requires connectivity (can't use .m2 cache), especially when there are many versions to go through

How should we proceed?

[jira-importer]

Michael Osipov commented

I think this is not fixed because it has been backed out many years ago.

[jira-importer]

Ran Biron commented

Michael Osipov backed out as in not going to be done - latest / release are going to continue to be supported?

[jira-importer]

Michael Osipov commented

I do not understand your question. Can you rephrase? As far as I understand the discussion the issue was implemented, but was then considered as a breaking change and should come back in 4.0.0. What did you understand?

[jira-importer]

Ran Biron commented

Michael Osipov I didn't realize the "come back in 4.0.0.".

Then I reiterate my original question:

I have a multi-module project committed to git. All modules have snapshot version in the SCM.

Each release:

1. I use the version plugin to update the snapshot version to a new number (1.0.0-snapshot, 2.0.0.-snapshot and so on).
2. I create a branch and use the version plugin to update the branch to the release version number (1.0.0, 2.0.0 and so on).

One of the modules requires considerable time and tooling to compile and build and I would like to use the latest released version instead of building from the local source code.

Some non-solutions:

1. commit the pom with release version - this will break CI flow, release flow and would confuse the people who actually develop this module as they would only use the cached release version.
2. modify the pom locally - this will create a modified file on my local machine which eventually, by developer error, will be committed, leading to much confusion and breaking of flows.
3. using a profile that changes the dependency to RELEASE version - this worked so far but in 4.0.0 model will stop working.
4. ???

 

[jira-importer]

Alan Czajkowski commented

Ran Biron based on what you've said here and in StackOverflow, your "problem" is begging for the "solution" to be: pull out the "annoying" module into its own repo/build/project, independent of the main multi-module project

[jira-importer]

Ran Biron commented

Alan Czajkowski that's a non solution. are you seriously telling me to change the entire project structure because maven can't look an artifact tagged release? besides, I'd still have to change tagging every time I release that other project instead of relying on snapshots.

[jira-importer]

Alan Czajkowski commented

Ran Biron you're asking for the build to have inconsitency (developer build must be different from CI build) ... this is terrible in practice, you end up with situations where the developer says "I don't know why it's broken in CI, works on my machine", you should strive to make your builds as consistent as possible across all use-cases, I know many people in the industry are doing short-cuts (NPM is notorious for this, and they're paying the price), but in the end all of these short-cuts lead to pain

[jira-importer]

Michael Osipov commented

Alan Czajkowski Very wise words!

[jira-importer]

Ran Biron commented

Alan Czajkowski I think that's a very "ivory tower" approach. You're right that it might cause issues and that maybe there will be an eventuality where a developer will complain. However, the use case I provided is real and exists right now. The effects of not "taking the shortcut" are significant and will require workarounds in source control management and release process to maintain developer productivity.