Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MRELEASE-1109] Snapshot detection and support for versions like ${revision}${sha1}${changelist} #202

Open
wants to merge 17 commits into
base: master
Choose a base branch
from

Conversation

mkolesnikov
Copy link
Contributor

Following this checklist to help us incorporate your
contribution quickly and easily:

  • Make sure there is a JIRA issue filed
    for the change (usually before you start working on it). Trivial changes like typos do not
    require a JIRA issue. Your pull request should address just this issue, without
    pulling in other changes.
  • Each commit in the pull request should have a meaningful subject line and body.
  • Format the pull request title like [MRELEASE-XXX] - Fixes bug in ApproximateQuantiles,
    where you replace MRELEASE-XXX with the appropriate JIRA issue. Best practice
    is to use the JIRA issue title in the pull request title and in the first line of the
    commit message.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Run mvn clean verify -Prun-its to make sure basic checks pass. A more thorough check will
    be performed on your pull request automatically.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

Mikhail Kolesnikov and others added 4 commits November 29, 2023 19:47
…snapshot_detection

# Conflicts:
#	maven-release-manager/src/test/resources/projects/rewrite-for-release/pom-with-parent-and-cifriendly-expressions/expected-pom.xml
…h `replace`. Added more tests after using this version for a while in a real project.
# Conflicts:
#	maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
#	maven-release-manager/src/main/java/org/apache/maven/shared/release/transform/jdom2/JDomModel.java
#	maven-release-manager/src/test/resources/projects/rewrite-for-release/pom-with-parent-and-cifriendly-expressions/expected-pom.xml
@michael-o michael-o self-requested a review June 3, 2024 18:23
// try to rewrite property if CI friendly expression is used
String ciFriendlyPropertyName = extractPropertyFromExpression(versionElement);
if (properties != null) {
String sha1 = properties.getProperty(SHA_1, System.getProperty(SHA_1, ""));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was System.getProperty() used before? We tend not to rely on system properties, but only on Maven properties.

@cstamas @slawekjaranowski

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sha1 property for CI is usually passed from a command-line. This class is an extract of everything related to CI Friendly. See, the usage of this method, it's used in JDomModel which does not have Maven project reference.
The goal of CiFriendlyVersion is a small clean up without a big refactoring.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll revert it back to System those properties do not exist in MavenProject because the current maven version for this plugin defined as <mavenVersion>3.2.5</mavenVersion> but you've put a link to the changes made 2 months ago.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is not correct. The class has been modified long time ago by me. Check its history. I can find the JIRA, if you want. The release of Maven Release will upgrade to 3.6.3 anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the change: https://issues.apache.org/jira/browse/MNG-7658. Model properties do get overwritten with the user properties. It is expected to work properly.

Copy link
Contributor Author

@mkolesnikov mkolesnikov Jun 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it does not with the current dependencies defined in this project :) Just run the integration test and you will see it maven-release-plugin/src/it/projects/prepare/ci-friendly-multi-module

Then the huge problem is the current dependencies defined in the pom.xml. It's just dependency hell that does not work if everything is set up as it's defined.
First of all, mavenVersion=3.2.5, the project even does not compile with maven-3.2.5 binary, it is immediately failed by maven-enforce-plugin and requires 3.6.3 version.
Then if you try to bump mavenVersion to 3.6.3 and the binary to the same version, it fails again.

Taking all this dependency incompatibility issues, please do not refer to the recent changes, they just don't work.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's pause this until Maven Release is updated to 3.6.3. I will work in this soon.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I will update the PR later, it will be nice if you notice me in this thread as soon as you finish maven version upgrade.

version,
versionElement.getTextNormalize(),
(JDomProperties) getProperties(),
mavenProject.getProperties());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cstamas @slawekjaranowski @gnodet Do you guys know from the top of your heads whether this contains merged props (model + user) or model only?

Copy link
Contributor Author

@mkolesnikov mkolesnikov Jun 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code reverted back to using System.getProperty as it's the only way to get sha1 value from mavenOpts, see the integration test.

Copy link

@basil basil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested this in https://issues.apache.org/jira/browse/MRELEASE-1151?focusedCommentId=17864766&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17864766, and with one exception, this PR resolves MRELEASE-1151. I think #201 should not have been released without also including this PR. I would recommend that the next release either include this PR or revert #201.

The exception is as follows. With the changes from this PR, <version> was left untouched (<version>${revision}${changelist}</version>) as expected, <revision> was left untouched (2.466) as expected, and <changelist>-SNAPSHOT</changelist> was changed to <changelist></changelist>, which results in the (correct) interpolated version of 2.466. The only issue I had was that this then failed my Spotless checks when running the preparation goals:

Failed to execute goal com.diffplug.spotless:spotless-maven-plugin:2.43.0:check (default) on project simple-maven-project-with-tests: The following files had format violations:
    pom.xml
        @@ -25,7 +25,7 @@
         ····</distributionManagement>
         ····<properties>
         ········<revision>1.40</revision>
        -········<changelist></changelist>
        +········<changelist·/>
         ········<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
         ········<maven.compiler.source>17</maven.compiler.source>
         ········<maven.compiler.target>17</maven.compiler.target>
Run 'mvn spotless:apply' to fix these violations.

Since the Jenkins project took its Spotless configuration from the Maven project, I would expect this to be an issue for the Maven project's releases as well, should this PR be released in its current form. In any case, this can be easily dealt with by skipping Spotless during the preparation phase with -Dspotless.check.skip.

@basil basil mentioned this pull request Jul 10, 2024
7 tasks
@@ -31,6 +31,8 @@

<properties>
<revision>1.0</revision>
<sha1>.123</sha1>
<changelist></changelist>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be nice if this PR would instead produce <changelist />, as that is the coding style used in Maven's own POM (which has, e.g. <relativePath />).

@olamy olamy added the bug label Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants