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"
(→List of current enhancement candidates) |
|||
| Line 1: | Line 1: | ||
== List of current enhancement candidates == | == List of current enhancement candidates == | ||
| + | * ''These initial candidate ideas were provided by Jim Sermersheim'' | ||
| + | ** 1) 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. | ||
| − | * | + | ** 2)Dependencies are versioned. 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. |
| − | * | + | ** 3) Single place for dependencies. 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. |
| − | * | + | ** 4) Any automated process should mirror manual processes. 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. |
| − | + | ||
| − | * 4) Any automated process should mirror manual processes. 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. | + | |
Revision as of 17:41, 22 October 2007
List of current enhancement candidates
- These initial candidate ideas were provided by Jim Sermersheim
- 1) 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.
- 2)Dependencies are versioned. 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.
- 3) Single place for dependencies. 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.
- 4) Any automated process should mirror manual processes. 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.