You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by "David Eric Pugh (JIRA)" <ge...@gump.apache.org> on 2005/12/01 15:55:30 UTC
[jira] Created: (GUMP-158) Manage API changes in dependencies better
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
[jira] Commented: (GUMP-158) Manage API changes in dependencies better
Posted by "Jan Matèrne (JIRA)" <ge...@gump.apache.org>.
[ 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
[jira] Commented: (GUMP-158) Manage API changes in dependencies better
Posted by "David Eric Pugh (JIRA)" <ge...@gump.apache.org>.
[ http://issues.apache.org/jira/browse/GUMP-158?page=comments#action_12359151 ]
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 http://vmgump.apache.org/gump/public 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: 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