1) What is the interest of using a map file for the Integration build?
(I understand the tag for the stable and release builds but not for the
integration.)
Many projects choose to use `-forceContextQualifier -fetchTag HEAD` to
override the tags in the maps for their Nightly (unstable) builds and
override the qualifiers on their features/plugins w/ the build's
timestamp. Why? It's a convenient way of quickly verifying that the
latest in CVS will compile and test OK.
All other builds (I, M, S, R) ought to be built from tagged maps for
reproduceability and stability: only tagged & released code therefore
makes its way into an Integration, Maintenance, Stable or Release build.
Of course this is just a guideline; you may run your project any way you
see fit provided that you follow the Eclipse.org project rules and don't
violate IP policy. Not everyone likes maps; some prefer to always build
from trunk/HEAD and only tag AFTER a successful build. As with all
things, YMMV. :)
2) In all examples of build.properties I have seen, there are only
dependencies to stable builds but never to snapshot.
Isn't it a common practice or is it usually defined elsewhere or did I
miss them?
Here's one build job that depends on the output of another using
SNAPSHOT URLs from Hudson:
https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-m2t-xpand-0.7/ws/build/org.eclipse.xpand.releng/build.properties
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.m2t/org.eclipse.xpand.releng/build.properties?root=Modeling_Project&view=markup
As you can see, that build depends on MWE, and points directly at its
lastSuccessfulBuild:
https://build.eclipse.org/hudson/job/cbi-emft-mwe-0.7/lastSuccessfulBuild/artifact/snapshot/emft-mwe-SDK-incubation-N-Snapshot.zip
Cheers,
--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
_______________________________________________
dash-dev mailing list
dash-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/dash-dev
