gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Eric Pugh (JIRA)" <>
Subject [jira] Commented: (GUMP-158) Manage API changes in dependencies better
Date Fri, 02 Dec 2005 12:43:33 GMT
    [ ] 

David Eric Pugh commented on GUMP-158:

GUMP-105 is pretty much how I was thinking as well for #1.  It would really help the robustness
of Gump go up.  Is the version of gump running at based
on the 3.0 version?   

I was thinking about #2, and it would be relatively harder for Gump to figure out which dependency
had the issue with the API.  In the case of Turbine-2, it would have to figure out from a
compile error that commons-logging api had changed.  So, for that case, i think having it
defined as a fall back would be key. 

> Manage API changes in dependencies better
> -----------------------------------------
>          Key: GUMP-158
>          URL:
>      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
> 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