RE: [higgins-dev] Some build requirements

[Brian Walker <BWalker@xxxxxxxxxxxxx>]

Fyi - I added Jim's candidate list to the Wiki page so we can add, update/edit as these ideas formulate:

http://wiki.eclipse.org/Future_automated_build_enhancement_candidate_list#List_of_current_enhancement_candidates


-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Brian Walker
Sent: Monday, October 22, 2007 2:24 PM
To: Higgins (Trust Framework) Project developer discussions
Subject: RE: [higgins-dev] Some build requirements

This is a good list Jim. Are there additional priority build enhancements others would see we need to address as well?

What about some inclusion of basic component or deployment level smoke/regression tests as part of automated nightly build process?


-----Original Message-----
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim
Sent: Monday, October 22, 2007 2:08 PM
To: higgins-dev@xxxxxxxxxxx
Subject: [higgins-dev] Some build requirements

To echo what Valery has pointed out and to follow up, I should have noted that this was a baby-step toward what I'd like the build process to look like.  Here are some attributes of the build process that I'd like to see (not sure if others share these views):

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.


>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 10/21/07 11:50 PM >>>
All,

The change outlined in this patch will add a target to build.xml called "fetch-subprojects".  If your build.properties file contains a line like this:
ensure.dependencies.version = HEAD

(where HEAD can be any cvs tag), then the fetch-subprojects target will use cvs to pull down all dependency projects (recursively) using the version specified in build.properties.

If ensure.dependencies.version is not set, then nothing happens for the fetch-subprojects target.

Anyone have issues with me adding this?

Jim



_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev