Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Build Enhancements"

(Enhancements to the nightly Higgins build process)
Line 1: Line 1:
 
== Enhancements to the nightly Higgins build process ==
 
== Enhancements to the nightly Higgins build process ==
''Most of these initial candidate ideas were provided by Jim Sermersheim:''
+
* No regeneration of build.xml after changing a project's dependencies. [Jim]
* No regeneration of build.xml after changing a project's dependencies.  
+
 
** Each project's build should ideally do whatever it takes to work before and after changes to that project's dependency list.
 
** Each project's build should ideally do whatever it takes to work before and after changes to that project's dependency list.
* Dependencies are versioned.  
+
* Dependencies are versioned. [Jim]
 
** We should be able at worst to cause a build to use a specified CVS tag for all dependencies, and ideally, we should be able to specify a cvs tag for each dependency.
 
** We should be able at worst to cause a build to use a specified CVS tag for all dependencies, and ideally, we should be able to specify a cvs tag for each dependency.
* Single place for dependencies.  
+
* Single place for dependencies. [Jim]
 
** Right now, we've decided to list them in manifest.mf.  Because this file doesn't allow us to control its contents, we're restricted from doing things like #2 above.  Moreover, it sounds like build.properties must also in some cases be updated with dependencies when there's a need to differentiate between build libs and runtime libs.  I think we should be updating our own dependencies.xml file, and that should be used to auto-gen, or update the manifest.mf as appropriate.
 
** Right now, we've decided to list them in manifest.mf.  Because this file doesn't allow us to control its contents, we're restricted from doing things like #2 above.  Moreover, it sounds like build.properties must also in some cases be updated with dependencies when there's a need to differentiate between build libs and runtime libs.  I think we should be updating our own dependencies.xml file, and that should be used to auto-gen, or update the manifest.mf as appropriate.
*Any automated process should mirror manual processes.  
+
*Any automated process should mirror manual processes. [Jim]
 
**If I pull down a project into a fresh work area and run it's build (which  automates the process of gathering dependencies), the result should look the same as if I had manually gathered all those dependencies.  Also, the fetched dependencies should remain in place and be usable at a later time.
 
**If I pull down a project into a fresh work area and run it's build (which  automates the process of gathering dependencies), the result should look the same as if I had manually gathered all those dependencies.  Also, the fetched dependencies should remain in place and be usable at a later time.
*Option: tag all components just before building
+
*Option: tag all components just before building [Paul]
 
** This is an optional part of the nightly build process
 
** This is an optional part of the nightly build process
 
** If build succeeds, and if the tagging was enabled, and if it was a candidate stable build, then having the source tagged will make it easy for us to check out this tag, and create a branch so that further tweaks to the stable build can be done on this branch.
 
** If build succeeds, and if the tagging was enabled, and if it was a candidate stable build, then having the source tagged will make it easy for us to check out this tag, and create a branch so that further tweaks to the stable build can be done on this branch.
Line 15: Line 14:
 
** The script needs to operate as a committer --not an anonymous user
 
** The script needs to operate as a committer --not an anonymous user
  
 
 
== Links ==
 
== Links ==
 
* [http://eclipse.org/higgins Higgins Home]
 
* [http://eclipse.org/higgins Higgins Home]

Revision as of 22:55, 24 October 2007

Enhancements to the nightly Higgins build process

  • No regeneration of build.xml after changing a project's dependencies. [Jim]
    • Each project's build should ideally do whatever it takes to work before and after changes to that project's dependency list.
  • Dependencies are versioned. [Jim]
    • We should be able at worst to cause a build to use a specified CVS tag for all dependencies, and ideally, we should be able to specify a cvs tag for each dependency.
  • Single place for dependencies. [Jim]
    • Right now, we've decided to list them in manifest.mf. Because this file doesn't allow us to control its contents, we're restricted from doing things like #2 above. Moreover, it sounds like build.properties must also in some cases be updated with dependencies when there's a need to differentiate between build libs and runtime libs. I think we should be updating our own dependencies.xml file, and that should be used to auto-gen, or update the manifest.mf as appropriate.
  • Any automated process should mirror manual processes. [Jim]
    • If I pull down a project into a fresh work area and run it's build (which automates the process of gathering dependencies), the result should look the same as if I had manually gathered all those dependencies. Also, the fetched dependencies should remain in place and be usable at a later time.
  • Option: tag all components just before building [Paul]
    • This is an optional part of the nightly build process
    • If build succeeds, and if the tagging was enabled, and if it was a candidate stable build, then having the source tagged will make it easy for us to check out this tag, and create a branch so that further tweaks to the stable build can be done on this branch.
    • In order to generated the latest build on a stable build branch, we'll also need to be able to specify the branch for the script to use when checking out the code
    • The script needs to operate as a committer --not an anonymous user

Links

Back to the top