Uploaded image for project: 'Gump'
  1. Gump
  2. GUMP-158

Manage API changes in dependencies better

    XMLWordPrintableJSON

Details

    • New Feature
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None
    • None

    Description

      I really appreciate how Gump helps a system like Turbine validate all it's dependencies. Turbine has many many dependencies, and Gump makes it simple to make sure they all work together.

      However, with so many dependencies, actually trying to get a clean build is very difficult. Not so much because of the Turbine code being incompatible, but because of the dependency tree. Turbine fails to build most commonly due to:
      1) A low level dependency like Ant failing
      2) An API change between a released project and it's CVS HEAD

      When #1 occurs, it knocks out the Gump build for hundreads of projects. If it is low enough, it may sit and not be fixed for a couple days, meaning that when it does get fixed, the next build takes in both that change, and all the other changes that occurred during the intervening period, increasing the chance of a build failure.

      When #2 occurs, the build just fails and fails until a released version comes out, and then Turbine updates to that version and everything is well. However, with lots of dependencies, #2 can occur frequently, and for long periods of time. An example is the API change between Commons Logging 1.0.4 and 1.1-dev. Turbine will fail until 1.1 is released.

      Both of these issues I think could be managed by preserving the build artifacts of previous builds, and using them when CVS HEAD fails. The CVS HEAD build failing is great information, especially for the producers of components that are reused. But for consumers of components, it doesn't help them much. So, I'd like to see Gump do a build with CVS HEAD. Then, if that fails, I'd like to see it rollback to older versions of the artifacts that had previously worked for a project. Alternatively, give me the option of specifing that in the metadata. This would help especially for #2. I know commons-logging will fail until it is released, so let me specify that if the build fails, try again, but fall back to commons-logging-1.0.4.

      Attachments

        Activity

          People

            Unassigned Unassigned
            dep4b David Eric Pugh
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated: