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.
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 == | ||
− | + | * 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