[BUILD-255] Maven version check during release is cumbersome Created: 11/Apr/17  Updated: 05/May/17  Resolved: 26/Apr/17

Status: Closed
Project: Build
Component/s: None
Affects Version/s: None
Fix Version/s: POMs 33

Type: Improvement Priority: Neutral
Reporter: Maxime Michel Assignee: Maxime Michel
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to BUILD-130 Upgrade to Maven 3.x Closed
Template:
Acceptance criteria:
Empty
Date of First Response:
Sprint: Basel 93
Story Points: 3

 Description   

The check might have been useful at some point, but what I'm seeing these days is that it's terribly cumbersome:

  • it's only done when you're actually performing the release, meaning you can lose a lot of time preparing it, for nothing
  • the versions required by Maven are not easily installed with either brew or apt

mmuehlebach and I think either of the following should be done:

  • remove the check completely
  • enforce the check on all release steps
  • let Jenkins do the release so we don't have to worry about correct local setups (longer story, but worth thinking about)


 Comments   
Comment by Mikaël Geljić [ 12/Apr/17 ]
<profile>
  <!-- a profile used when performing a release -->
  <id>release-perform-profile</id>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <configuration>
          <rules>
            <requireMavenVersion>
              <version>[3.2.3]</version>
            </requireMavenVersion>
          </rules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

This profile is only used upon release:perform... by design of the release plugin*.
Default otherwise is a maven 3 open range: [3,)

Options:

  1. Use an open range for the release profile: [3.2.3,)
    • 3.2.3 is our minimum required version because 3.2.2 suffered problems with imported dependencyManagements (same as maven 2 did), will try to link issue.
  2. And/or apply this profile to both prepare and perform goals, by using similar "hack" to what we did for the staging profile (passing the profile in arguments).

Moving ticket to BUILD if I may

Comment by Maxime Michel [ 13/Apr/17 ]

Thanks for the details! I personally wouldn't go for 2. because I consider that things should run smoothly with current Maven versions. The corner case in which somebody ends up stuck in the middle of a module release while using a Maven version from mid-2014 (3.2.2), or older, isn't likely to happen. And if does, then I'd argue it's that person's responsability to upgrade, which is a simple task anyway (simpler and more elegant than a downgrade at least).

Comment by Mikaël Geljić [ 13/Apr/17 ]

Absolutely, I actually didn't mean options as mutually exclusive, but the open range seems more sensible first.

Generated at Sun Feb 11 23:40:12 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.