Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Build Enhancements"
| (36 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | {{#eclipseproject:technology.higgins}} |
| − | + | == Nightly Builds == | |
| − | * No regeneration of build.xml after changing a project's dependencies. | + | |
| + | * Add "build" links\icons on [[Components]] page that allows authorized individuals to kick off a build of desired components. [Tom] | ||
| + | * 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. | ** 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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | == Eclipse Developer Builds == | |
| − | == | + | *Configure target in build.xml that would fetch the dependencies for a project. For any given component: |
| − | * [ | + | ** Pull down dependencies and build in IDE (recursively). |
| + | ** Pull in all required 3rd party unapproved libs [Alexandra] | ||
| + | |||
| + | == Non-Eclipse Developer Builds == | ||
| + | * tbd others... | ||
| + | |||
| + | [[Category:Higgins 1.x Developer Info]] | ||
Latest revision as of 16:25, 25 April 2011
{{#eclipseproject:technology.higgins}}
Nightly Builds
- Add "build" links\icons on Components page that allows authorized individuals to kick off a build of desired components. [Tom]
- 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.
Eclipse Developer Builds
- Configure target in build.xml that would fetch the dependencies for a project. For any given component:
- Pull down dependencies and build in IDE (recursively).
- Pull in all required 3rd party unapproved libs [Alexandra]
Non-Eclipse Developer Builds
- tbd others...