gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Eric Pugh (JIRA)" <>
Subject [jira] Created: (GUMP-158) Manage API changes in dependencies better
Date Thu, 01 Dec 2005 14:55:30 GMT
Manage API changes in dependencies better

         Key: GUMP-158
     Project: Gump
        Type: New Feature
    Reporter: David Eric Pugh

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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message