gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Matèrne (JIRA) <gene...@gump.apache.org>
Subject [jira] Commented: (GUMP-158) Manage API changes in dependencies better
Date Fri, 02 Dec 2005 05:44:34 GMT
    [ http://issues.apache.org/jira/browse/GUMP-158?page=comments#action_12359121 ] 

Jan Matèrne commented on GUMP-158:
----------------------------------

For #1 see http://issues.apache.org/jira/browse/GUMP-105

> Manage API changes in dependencies better
> -----------------------------------------
>
>          Key: GUMP-158
>          URL: http://issues.apache.org/jira/browse/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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message