[JIRA] Updated: (CC-265) Project Dependency Management

"Mohd Sharif Idrisi (JIRA)" <[email protected]> Sat, 2 Jul 2011 02:46:00 -0500 (CDT)
Newsgroups gmane.comp.java.cruise-control.devel
Message-ID <1902266457.1309592760744.JavaMail.jira@chidmzhosting02.thoughtworks.com>
     [ http://jira.public.thoughtworks.org/browse/CC-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mohd Sharif Idrisi updated CC-265:
----------------------------------


Please implement this for Linux also.

> Project Dependency Management
> -----------------------------
>
>                 Key: CC-265
>                 URL: http://jira.public.thoughtworks.org/browse/CC-265
>             Project: CruiseControl
>          Issue Type: New Feature
>          Components: Core Application
>    Affects Versions: 2.3
>            Reporter: Micah Spears
>            Priority: Major
>         Attachments: buildqueue.txt, src.patch, test.patch
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Dependency management on large projects is one of the biggest problems developers face.  Typically, developers work in a top-down fashion building and incorporating dependencies.  This is where build tools such as Ant come into play.  If a developer is working on module A that has dependencies B and C, then B and C are built in a top-down fashion before A is built.  The flip side of the dependency graph involves a bottom-up dependant build.  If modules B or C are built, then A should be built as well to prevent regression.  Bottom-up builds are never incorporated into [Ant] build scripts as we are discussing temporal coupling, not static coupling.
> The current approach is to use the <buildstatus> plugin. Unfortunately, the <buildstatus> plugin only supports one-way dependency management because it lacks build revocation when a dependency fails.  In addition, the <buildstatus> plugin is not synchronized with the build queue so the build order is not guaranteed. For example
>       A -> B, C
>       B fails so A's build privileges are revoked
>       C succeeds which notifies A but A is still waiting on B
> In this simple example, the <buildstatus> plugin would happily build A which is not what we would except or want to happen in a development environment. 
> This set of patches provides full bottom-up project dependency management functionality to CC and fixes some minor issues relating to event management and the log plugin. The supported features are
>   1.) If a dependency builds successfully, then its root (optimal) dependents are notified to [forcibly] build.  This process continues until the entire bottom-up dependency tree is traversed.
>   
>   2.) A dependent will not succeed in requesting to build if the dependent has broken dependencies.  A dependent with broken dependencies will only build if it is forced.
>   
>   3.) Circular dependencies are detected at startup to prevent infinite build loops.
>  
>   4.) At CC startup, all projects that have no dependencies will be forced to build.  This maintains the current CC behavior while supporting dependencies.
>   5.) The dependency management is thread-safe across the projects by integrating into the build queue.
> An example configuration is:
>   <project name="Common" buildafterfailed="false">
>     ...
>   </project>
>  
>   <project name="Domain" buildafterfailed="false">
>     <dependencies>
>       <dependency project="Common"/>
>     </dependencies>
>     ...    
>   </project>
>  
>   <project name="ServiceA" buildafterfailed="false">
>     <dependencies>
>       <dependency project="Common"/> <!-- This dependency is optional as Domain depends on Common i.e. Common is inclusive  -->
>       <dependency project="Domain"/>
>     </dependencies>
>     ...    
>   </project>
>   <project name="ServiceB" buildafterfailed="false">
>     <dependencies>
>       <dependency project="Domain"/>
>       <dependency project="ServiceA"/>
>     </dependencies>
>     ...    
>   </project>
> This set of patches was submitted to the dev mailing list a while back.  Hopefully, the CC committers will take another look after considering user requests such as http://jira.public.thoughtworks.org/browse/CC-261

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.public.thoughtworks.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2