Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Build Enhancements"

(New page: 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 depende...)
 
 
(44 intermediate revisions by 5 users not shown)
Line 1: Line 1:
−
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.
+
{{#eclipseproject:technology.higgins}}
 +
== Nightly Builds ==
  
−
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.
+
* 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.
  
−
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.
+
== 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]
  
−
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.
+
== 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...
Retrieved from "https://wiki.eclipse.org/index.php?title=Build_Enhancements&oldid=247807"

This page was last modified 16:25, 25 April 2011 by Tom Carroll. Based on work by Tom Carroll, Paul Trevithick and Peter Kimlach and others.

Back to the top