Maven Release Plugin
  1. Maven Release Plugin
  2. MRELEASE-220

Add property to keep released versions for dependencies

    Details

    • Type: Improvement Improvement
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0-beta-4
    • Fix Version/s: None
    • Component/s: prepare
    • Labels:
      None
    • Number of attachments :
      0

      Description

      When I release a project with many modules with internal dependencies.
      I would like those dependencies to keep the released version rather than the next development version.

      ie: I only release some modules at a time (those that were changed only since last release).
      So when my webapp is released, I want it to become SNAPSHOT again(as it is done already) but want the internal dependencies to keep the released version.
      I want to update them manually whenever I change one.

        Activity

        Hide
        Daniel Beland added a comment -

        Setting the updateDependencies flag to false doesn't change the dependencies at all:
        I have a small project with modules:

        [INFO] Reactor build order:
        [INFO] Test parent POM
        [INFO] Test Common lib
        [INFO] Test Module 1 lib
        [INFO] Test Module 2 lib
        [INFO] Test Webapp

        With all modules inheriting from the Parent POM (at the root)
        Module 1 and Module 2 both has Common lib as a dependency
        Webapp has Common, Module 1 and Module 2 has dependencies.
        Everything is 1.0-SNAPSHOT

        I start the release:prepare and enter the new versions.
        the pom.xml.tag files are fine.
        But I would expect the pom.xml.next files to:
        -Have the version set to the next development version --> OK
        -Have the parent version set to the parent next version --> OK
        -Have the dependencies keep the tagged version --> KO, it keeps the SNAPSHOT version before the release

        [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-6:prepare' -->
        [DEBUG] (f) addSchema = true
        [DEBUG] (f) autoVersionSubmodules = false
        [DEBUG] (s) basedir = c:\eclipse\workspace\test-m2
        [DEBUG] (f) commitByProject = false
        [DEBUG] (f) dryRun = true
        [DEBUG] (f) generateReleasePoms = false
        [DEBUG] (f) preparationGoals = clean verify
        [DEBUG] (f) project = org.apache.maven.project.MavenProject@e9eb54c7
        [DEBUG] (f) reactorProjects = [org.apache.maven.project.MavenProject@e9eb54c7, org.apache.maven.project.MavenProject@e6f1aaf9, org.apache.maven.project.MavenProject@4f8f9b35, org.apache.maven.project.MavenProject@14217d54, org.apache.maven.project.MavenProject@fc355cf0]
        [DEBUG] (f) resume = true
        [DEBUG] (f) scmCommentPrefix = [maven-release-plugin]
        [DEBUG] (f) settings = org.apache.maven.settings.Settings@12884e0
        [DEBUG] (f) updateDependencies = false
        [DEBUG] (f) useEditMode = false
        [DEBUG] – end configuration –

        Show
        Daniel Beland added a comment - Setting the updateDependencies flag to false doesn't change the dependencies at all: I have a small project with modules: [INFO] Reactor build order: [INFO] Test parent POM [INFO] Test Common lib [INFO] Test Module 1 lib [INFO] Test Module 2 lib [INFO] Test Webapp With all modules inheriting from the Parent POM (at the root) Module 1 and Module 2 both has Common lib as a dependency Webapp has Common, Module 1 and Module 2 has dependencies. Everything is 1.0-SNAPSHOT I start the release:prepare and enter the new versions. the pom.xml.tag files are fine. But I would expect the pom.xml.next files to: -Have the version set to the next development version --> OK -Have the parent version set to the parent next version --> OK -Have the dependencies keep the tagged version --> KO, it keeps the SNAPSHOT version before the release [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-release-plugin:2.0-beta-6:prepare' --> [DEBUG] (f) addSchema = true [DEBUG] (f) autoVersionSubmodules = false [DEBUG] (s) basedir = c:\eclipse\workspace\test-m2 [DEBUG] (f) commitByProject = false [DEBUG] (f) dryRun = true [DEBUG] (f) generateReleasePoms = false [DEBUG] (f) preparationGoals = clean verify [DEBUG] (f) project = org.apache.maven.project.MavenProject@e9eb54c7 [DEBUG] (f) reactorProjects = [org.apache.maven.project.MavenProject@e9eb54c7, org.apache.maven.project.MavenProject@e6f1aaf9, org.apache.maven.project.MavenProject@4f8f9b35, org.apache.maven.project.MavenProject@14217d54, org.apache.maven.project.MavenProject@fc355cf0] [DEBUG] (f) resume = true [DEBUG] (f) scmCommentPrefix = [maven-release-plugin] [DEBUG] (f) settings = org.apache.maven.settings.Settings@12884e0 [DEBUG] (f) updateDependencies = false [DEBUG] (f) useEditMode = false [DEBUG] – end configuration –
        Hide
        Brian Fox added a comment -

        beta-5 is already released. sheduling for next rev.

        Show
        Brian Fox added a comment - beta-5 is already released. sheduling for next rev.
        Hide
        Dennis Lundberg added a comment -

        Is this still valid for the released 2.0-beta-7 version?

        Otherwise attaching a sample project would be very helpful.

        Show
        Dennis Lundberg added a comment - Is this still valid for the released 2.0-beta-7 version? Otherwise attaching a sample project would be very helpful.
        Hide
        Dennis Lundberg added a comment -

        Remove Fix Version, since there has been no response from users.

        Show
        Dennis Lundberg added a comment - Remove Fix Version, since there has been no response from users.
        Hide
        Daniel Beland added a comment -

        I tested it with 2.0-beta-8 and it works fine when performing a real release.

        However, when testing with -DdryRun=true the dependencies are not updated in the file pom.xml.next.
        in pom.xml.releaseBackup the dependencies have version 1.0-SNAPSHOT
        in pom.xml.tag they have version 1.0 (as specified)
        in pom.xml.next they have version 1.0-SNAPSHOT while I would expect 1.0

        So this the behavior I described in my previous comment, I probably didn't try a real release at the time and just a dryRun.

        Should we close this issue and I open a new one for the dryRun bug?

        Show
        Daniel Beland added a comment - I tested it with 2.0-beta-8 and it works fine when performing a real release. However, when testing with -DdryRun=true the dependencies are not updated in the file pom.xml.next. in pom.xml.releaseBackup the dependencies have version 1.0-SNAPSHOT in pom.xml.tag they have version 1.0 (as specified) in pom.xml.next they have version 1.0-SNAPSHOT while I would expect 1.0 So this the behavior I described in my previous comment, I probably didn't try a real release at the time and just a dryRun. Should we close this issue and I open a new one for the dryRun bug?
        Hide
        Peter Liljenberg added a comment -

        I've just tested this with 2.0-beta-8 and I don't think it works.
        I have 2 projects:

        proj1
        proj2

        proj2 dependes on proj1.
        If I have a SNAPSHOT dependency in proj2 to proj1 and executes:

        mvn release:prepare -DupdateDependencies=false
        mvn release:perform

        The resulting pom for proj2 will look like this after the release:
        ...
        <dependency>
        <groupId>nu.sunfire</groupId>
        <artifactId>proj1</artifactId>
        <version>1.1-SNAPSHOT</version>
        </dependency>
        ...
        I would expect the version to be 1.0....
        During the prepare work, I get the question of which the next development version for proj1 should be, and nothing but a SNAPSHOT version can be entered?

        Show
        Peter Liljenberg added a comment - I've just tested this with 2.0-beta-8 and I don't think it works. I have 2 projects: proj1 proj2 proj2 dependes on proj1. If I have a SNAPSHOT dependency in proj2 to proj1 and executes: mvn release:prepare -DupdateDependencies=false mvn release:perform The resulting pom for proj2 will look like this after the release: ... <dependency> <groupId>nu.sunfire</groupId> <artifactId>proj1</artifactId> <version>1.1-SNAPSHOT</version> </dependency> ... I would expect the version to be 1.0.... During the prepare work, I get the question of which the next development version for proj1 should be, and nothing but a SNAPSHOT version can be entered?
        Hide
        Peter Liljenberg added a comment -

        After digging into the code it looks like the actual bug is in ReleaseManager rather than the plugin itself:

        //MRELEASE-220
        if ( mappedVersion != null && mappedVersion.endsWith( "SNAPSHOT" ) &&
        !dependencyVersion.endsWith( "SNAPSHOT" ) && !releaseDescriptor.isUpdateDependencies() )

        { return; }

        Shouldn't we check the dependencyVersion here?
        if ( !dependencyVersion.endsWith( "SNAPSHOT" ) && !releaseDescriptor.isUpdateDependencies() )
        { return; }
        Show
        Peter Liljenberg added a comment - After digging into the code it looks like the actual bug is in ReleaseManager rather than the plugin itself: // MRELEASE-220 if ( mappedVersion != null && mappedVersion.endsWith( "SNAPSHOT" ) && !dependencyVersion.endsWith( "SNAPSHOT" ) && !releaseDescriptor.isUpdateDependencies() ) { return; } Shouldn't we check the dependencyVersion here? if ( !dependencyVersion.endsWith( "SNAPSHOT" ) && !releaseDescriptor.isUpdateDependencies() ) { return; }
        Hide
        Peter Liljenberg added a comment -

        The "fix" that I proposed seems to be working on my test projects. Don't have enough data to guarantee that it is the correct fix, but if someone else can verify that it works for them I think a new version with the fix applied would be nice.

        Show
        Peter Liljenberg added a comment - The "fix" that I proposed seems to be working on my test projects. Don't have enough data to guarantee that it is the correct fix, but if someone else can verify that it works for them I think a new version with the fix applied would be nice.

          People

          • Assignee:
            Emmanuel Venisse
            Reporter:
            Daniel Beland
          • Votes:
            9 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated: