Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-4930

Align SNAPSHOT release version numbers between various Rice Build artifacts

    Details

    • Similar issues:
      KULRICE-12969Include updating the rice SNAPSHOTS versions in .idea/artifacts/*.xml as part of the release process
      KULRICE-12939Include .idea/artifacts xml files updating as part of release process
      KULRICE-4579Create a Rice 1.0.3 Milestone release for use by KS 1.1 Development
      KULRICE-12997Test git with nightly release process
      KULRICE-11807Nightly build is failing due to missing artifacts
      KULRICE-10638Rice is pulling in multiple versions of the commons-chain artifact
      KULRICE-7713Release new kuali commons-beanutils
      KULRICE-4945Write RFC on Updated Release Plan for Rice
      KULRICE-7052Improve and automate collaboration options for downstream projects
      KULRICE-1566Missing source in latest (1/25) rice-kns SNAPSHOT update

      Description

      The Kuali Coeus project has asked that we establish a consistent versioning between maven SNAPSHOT artifacts generated from the same SVN r#.

      For example, at present, the rice-api-1.0.3.1-SNAPSHOT is at version -4 (rice-api-1.0.3.1-20101124.204003-4.jar), whereas the rice-impl-1.0.3.1-SNAPSHOT is at version -3 (rice-impl-1.0.3.1-20101124.204003-3.jar). The KC team find this impedes their ability to target a specific release of the Kuali Rice code.

      We would like to find a mechanism by which KC can effectively target the artifacts generated from a particular SVN r#, while still maintaining the automation of our build process.

        Activity

        Hide
        Sam Wilson (Inactive) added a comment -

        I see a number of options for addressing this request:

        1) Adjust the KC and Rice POM files to target specific dependency versions. (My preference)

        Right now the KC POM file only references two Rice dependencies directly: rice-impl and rice-web. It uses a single property to reference these two dependencies ($

        {rice.version}

        ). This could be changed to use two different version numbers: $

        {rice-impl.version}

        and $

        {rice-web.version}

        . ** Based on the Rice project's work with Version Compatibility, this may actually be a necessary change in the future, regardless. Coincident with this change, the Rice POM files should be updated so that they reference other Rice modules via appropriate version numbers instead of using the $

        {project.version}

        macro. This will likely also need to change as part of the Version compatibility project. **

        In addition, we would need to use something like the Maven Versions Plugin http://mojo.codehaus.org/versions-maven-plugin/ to ensure that specific SNAPSHOT dependency versions are referenced between the various Rice component artifacts. This would eliminate the KC (or other client projects) from needing to reference each individual sub-module.

        The big downside to this approach is that it won't be readily apparent from

        2) Establish a DAILY build of Rice

        We could add an additional build job to the Rice CI environment that would build all rice modules on a daily basis. The Rice modules would be labeled with a version number like "rice-[module]-1.0.3.1-DAILY-20101124". In this manner, the dependent projects would be able to pinpoint a specific, unified set of Rice artifacts to use within their projects.

        There are multiple downsides to this approach:

        **) We would need to maintain DAILY builds as well as SNAPSHOT builds. This will require more space, more processing and more documentation as well as maintenance effort.
        **) The DAILY builds would be incompatible with the built-in Maven SNAPSHOT mechanism, meaning we would potentially lose some functionality.
        **) Custom build steps will need to be implemented to set the appropriate VERSION on all the artifacts. This will likely require a customized plugin, though we might be able to use this one: http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html
        **) Client projects that target a specific DAILY release will need to ensure they update their POM files frequently so that they stay in sync with the branch of rice they are targeting. Failing to do so will introduce schedule risk as integration testing will be delayed. In an agile development environment, this can be very difficult to manage. This would apply to targeting specific SNAPSHOT versions as well, but in this case, projects would need to always manually update their DAILY release version.
        **) At the moment, this is a custom build requirement needed to support the KC project. Other projects depending on Rice haven't expressed this need. To what extent should Rice establish custom build procedures for each client project?
        **) This approach may be made moot by the version compatibility and modularity projects.

        – Please let me know if you can identify any alternative implementation ideas.
        – Also, feedback on the above two approaches would be greatly appreciated.

        Show
        Sam Wilson (Inactive) added a comment - I see a number of options for addressing this request: 1) Adjust the KC and Rice POM files to target specific dependency versions. (My preference) Right now the KC POM file only references two Rice dependencies directly: rice-impl and rice-web. It uses a single property to reference these two dependencies ($ {rice.version} ). This could be changed to use two different version numbers: $ {rice-impl.version} and $ {rice-web.version} . ** Based on the Rice project's work with Version Compatibility, this may actually be a necessary change in the future, regardless. Coincident with this change, the Rice POM files should be updated so that they reference other Rice modules via appropriate version numbers instead of using the $ {project.version} macro. This will likely also need to change as part of the Version compatibility project. ** In addition, we would need to use something like the Maven Versions Plugin http://mojo.codehaus.org/versions-maven-plugin/ to ensure that specific SNAPSHOT dependency versions are referenced between the various Rice component artifacts. This would eliminate the KC (or other client projects) from needing to reference each individual sub-module. The big downside to this approach is that it won't be readily apparent from 2) Establish a DAILY build of Rice We could add an additional build job to the Rice CI environment that would build all rice modules on a daily basis. The Rice modules would be labeled with a version number like "rice- [module] -1.0.3.1-DAILY-20101124". In this manner, the dependent projects would be able to pinpoint a specific, unified set of Rice artifacts to use within their projects. There are multiple downsides to this approach: **) We would need to maintain DAILY builds as well as SNAPSHOT builds. This will require more space, more processing and more documentation as well as maintenance effort. **) The DAILY builds would be incompatible with the built-in Maven SNAPSHOT mechanism, meaning we would potentially lose some functionality. **) Custom build steps will need to be implemented to set the appropriate VERSION on all the artifacts. This will likely require a customized plugin, though we might be able to use this one: http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html **) Client projects that target a specific DAILY release will need to ensure they update their POM files frequently so that they stay in sync with the branch of rice they are targeting. Failing to do so will introduce schedule risk as integration testing will be delayed. In an agile development environment, this can be very difficult to manage. This would apply to targeting specific SNAPSHOT versions as well, but in this case, projects would need to always manually update their DAILY release version. **) At the moment, this is a custom build requirement needed to support the KC project. Other projects depending on Rice haven't expressed this need. To what extent should Rice establish custom build procedures for each client project? **) This approach may be made moot by the version compatibility and modularity projects. – Please let me know if you can identify any alternative implementation ideas. – Also, feedback on the above two approaches would be greatly appreciated.
        Hide
        Eric Westfall added a comment -

        I'm not sure if I'm fulling answering the question here, but my preference might be a hybrid of what you are suggesting. I would propose that we have a daily build of Rice which produces a snapshot (assuming all tests pass and the build is successful, once we put pure unit tests where they belong and isolate integration tests this should be much easier). I'm a little confused about how our snapshots builds are getting out of sync like this, but I was under the impression that if you execute a snapshot deploy, it should deploy a consistent version of all of the module snapshots to the repo.

        Aside from the above for daily/dev builds, I would propose that the Rice team be in the habit of pushing out milestone builds periodically whenever major functionality is completed or close to complete. Ideally a milestone build will pass all integration tests as well though i don' think that would be strictly required. Is this inline or opposed to anything you are thinking here Sam? To this end, I would suspect/hope that KC would be primarily using our milestone builds as opposed to daily builds.

        Show
        Eric Westfall added a comment - I'm not sure if I'm fulling answering the question here, but my preference might be a hybrid of what you are suggesting. I would propose that we have a daily build of Rice which produces a snapshot (assuming all tests pass and the build is successful, once we put pure unit tests where they belong and isolate integration tests this should be much easier). I'm a little confused about how our snapshots builds are getting out of sync like this, but I was under the impression that if you execute a snapshot deploy, it should deploy a consistent version of all of the module snapshots to the repo. Aside from the above for daily/dev builds, I would propose that the Rice team be in the habit of pushing out milestone builds periodically whenever major functionality is completed or close to complete. Ideally a milestone build will pass all integration tests as well though i don' think that would be strictly required. Is this inline or opposed to anything you are thinking here Sam? To this end, I would suspect/hope that KC would be primarily using our milestone builds as opposed to daily builds.
        Hide
        Chitra Chandran added a comment -

        Sam / Eric,

        To resolve the naming inconsistency with the snapshot builds, can you use
        <build>
        .......
        <finalName>$

        {project.artifactId}

        -$

        {project.version}

        -r$

        {buildNumber}

        </finalName>
        ....
        </build>

        instead of configuring the buildnumber-maven-plugin to use timestamp?

        This way, we have the SVN revision number in the artifact name itself and we can resolve the naming issue also.
        (Since Rice changes might come with possible database or external config changes, we would like to depend on a specific revision that can be tested locally before upgrading KC to use the next version.)

        Regarding the milestone releases, it would be great to have those. But we still would like the flexibility of pulling Snapshot builds if the gap between two milestones is longer than we anticipate.
        One more thing: when we were deploying rice on our own, we use to deploy the source and javadoc artifacts as well. Not all KC developers have rice in their local workspace and it was convenient for us to directly link to the source JARs. Can we have those deployed as well?

        thanks,
        Chitra

        Show
        Chitra Chandran added a comment - Sam / Eric, To resolve the naming inconsistency with the snapshot builds, can you use <build> ....... <finalName>$ {project.artifactId} -$ {project.version} -r$ {buildNumber} </finalName> .... </build> instead of configuring the buildnumber-maven-plugin to use timestamp? This way, we have the SVN revision number in the artifact name itself and we can resolve the naming issue also. (Since Rice changes might come with possible database or external config changes, we would like to depend on a specific revision that can be tested locally before upgrading KC to use the next version.) Regarding the milestone releases, it would be great to have those. But we still would like the flexibility of pulling Snapshot builds if the gap between two milestones is longer than we anticipate. One more thing: when we were deploying rice on our own, we use to deploy the source and javadoc artifacts as well. Not all KC developers have rice in their local workspace and it was convenient for us to directly link to the source JARs. Can we have those deployed as well? thanks, Chitra
        Hide
        Sam Wilson (Inactive) added a comment -

        Hi Chitra,

        So, I've been playing around with your suggestion. Unfortunately, there are two issues with that approach:

        1) The <finalName> tag is ignored by the repository. It only affects the name of the file in the target/ directory. When the file is deployed, it follows the standard naming convention.
        2) Modifying the <finalName> tag also does not affect the actual version of the file with respect to Maven's dependency resolution mechanism. For that, we would need to use a classifier.

        I'll hopefully have some more info soon.

        Sam

        Show
        Sam Wilson (Inactive) added a comment - Hi Chitra, So, I've been playing around with your suggestion. Unfortunately, there are two issues with that approach: 1) The <finalName> tag is ignored by the repository. It only affects the name of the file in the target/ directory. When the file is deployed, it follows the standard naming convention. 2) Modifying the <finalName> tag also does not affect the actual version of the file with respect to Maven's dependency resolution mechanism. For that, we would need to use a classifier. I'll hopefully have some more info soon. Sam
        Hide
        Sam Wilson (Inactive) added a comment -

        So,

        Another thing I have determined is that SNAPSHOT releases are not locked within maven reactor builds.

        What does that mean?

        When you build a project like rice, where there are a number of submodules based on a shared parent, it is referred to as a "reactor" build. When you use the maven release plugin it is smart enough to ensure that all the reactor projects have their version numbers updated properly. Unfortunately the deploy and install plugins aren't as intelligent. When they publish SNAPSHOT releases they don't lock the reactor dependencies to the current build, they leave them as -SNAPSHOT, which means if you tie yourself to one part of the reactor build, your transitive dependencies to other parts of the reactor build won't be bound.

        What I am looking into now are the following two things, and I ultimately think the second will happen regardless of the first.

        1) Projects like KC that want to bind themselves to a particular SNAPSHOT release should use the versions plugin on their own POM files to lock-snapshots/unlock-snapshots on their own schedule. I'm looking at how this works in practice, especially with respect to transitive dependencies.

        2) We should adopt a milestone release plan. At the moment, however, this is driven by KC and not by Rice or the other dependent projects at Rice. I believe we'll need to find a release plan that works for multiple projects, not just KC, in order for it to scale properly. Ultimately, I believe that Rice will want to have a milestone release policy that is general enough to support multiple projects. This is something beyond just me, though, and really needs to be worked out at a higher level between Rice, KC, KFS, KS, &c.

        Should have some more info about 1 shortly.

        Show
        Sam Wilson (Inactive) added a comment - So, Another thing I have determined is that SNAPSHOT releases are not locked within maven reactor builds. What does that mean? When you build a project like rice, where there are a number of submodules based on a shared parent, it is referred to as a "reactor" build. When you use the maven release plugin it is smart enough to ensure that all the reactor projects have their version numbers updated properly. Unfortunately the deploy and install plugins aren't as intelligent. When they publish SNAPSHOT releases they don't lock the reactor dependencies to the current build, they leave them as -SNAPSHOT, which means if you tie yourself to one part of the reactor build, your transitive dependencies to other parts of the reactor build won't be bound. What I am looking into now are the following two things, and I ultimately think the second will happen regardless of the first. 1) Projects like KC that want to bind themselves to a particular SNAPSHOT release should use the versions plugin on their own POM files to lock-snapshots/unlock-snapshots on their own schedule. I'm looking at how this works in practice, especially with respect to transitive dependencies. 2) We should adopt a milestone release plan. At the moment, however, this is driven by KC and not by Rice or the other dependent projects at Rice. I believe we'll need to find a release plan that works for multiple projects, not just KC, in order for it to scale properly. Ultimately, I believe that Rice will want to have a milestone release policy that is general enough to support multiple projects. This is something beyond just me, though, and really needs to be worked out at a higher level between Rice, KC, KFS, KS, &c. Should have some more info about 1 shortly.
        Hide
        Travis Schneeberger added a comment -

        Sam,

        In regards to 2) towards the end KC's last release I was releasing rice milestones on KC's schedule and letting the other project teams aware of the new milestones. The milestone were not named specifically for KC and were being used by other project teams. The milestone's were being created by me (KC team) which isn't great. I think that this worked fairly well for all the teams involved so I don't think this will be much of an issue to get a milestone process coordinated between the project teams.

        Show
        Travis Schneeberger added a comment - Sam, In regards to 2) towards the end KC's last release I was releasing rice milestones on KC's schedule and letting the other project teams aware of the new milestones. The milestone were not named specifically for KC and were being used by other project teams. The milestone's were being created by me (KC team) which isn't great. I think that this worked fairly well for all the teams involved so I don't think this will be much of an issue to get a milestone process coordinated between the project teams.
        Hide
        Sam Wilson (Inactive) added a comment -

        I did some further review on Friday with the codehaus Versions plugin.

        It does not handle locking snapshots in a transitive manner. I think, as a result, it would not meet the needs of the Coeus or other projects.

        I do still believe that Rice-dependent projects will need to make effective use of our SNAPSHOTS as needed. However, for cases where they would like to lock-down their development, we need to establish a milestone release process.

        To what Travis has indicated, I believe this responsibility fell to the KC project as a result of Rice not having a dedicated CM for a bit there. I've setup a meeting internal to Rice to discuss what we can do to establish an appropriate milestone release plan.

        For now, I would recommend pulling from the SNAPSHOTS. They only get updated when all the unit tests pass successfully.

        Show
        Sam Wilson (Inactive) added a comment - I did some further review on Friday with the codehaus Versions plugin. It does not handle locking snapshots in a transitive manner. I think, as a result, it would not meet the needs of the Coeus or other projects. I do still believe that Rice-dependent projects will need to make effective use of our SNAPSHOTS as needed. However, for cases where they would like to lock-down their development, we need to establish a milestone release process. To what Travis has indicated, I believe this responsibility fell to the KC project as a result of Rice not having a dedicated CM for a bit there. I've setup a meeting internal to Rice to discuss what we can do to establish an appropriate milestone release plan. For now, I would recommend pulling from the SNAPSHOTS. They only get updated when all the unit tests pass successfully.
        Hide
        Sam Wilson (Inactive) added a comment -

        Added sub-task RICEINFR-35 to address writing the updated release plan for rice to incorporate milestone releases.

        Show
        Sam Wilson (Inactive) added a comment - Added sub-task RICEINFR-35 to address writing the updated release plan for rice to incorporate milestone releases.
        Hide
        Jessica Coltrin (Inactive) added a comment -

        Spoke with Jeff and this is a non-issue. He doesn't think this is the right approach. Instead, we've created on-demand version milestone builds to meet KC needs.

        Show
        Jessica Coltrin (Inactive) added a comment - Spoke with Jeff and this is a non-issue. He doesn't think this is the right approach. Instead, we've created on-demand version milestone builds to meet KC needs.

          People

          • Assignee:
            Sam Wilson (Inactive)
            Reporter:
            Sam Wilson (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel