Hmm.. chaging myproject.releng build.xml to replace:
<property file="build.properties" />
with:
<property file="build-local.properties" />
*doesn't* seem to work properly, i.e. it looks as though
build.properties is still somehow used and the new definitions for the
targets are not brought in from build-local.properties.
I should qualify this. Not *everything* you set in a custom
build.properties will be passed thru to launched Eclipse/AntRunner.
Bbasically, the properties that need to be customized by OS/server will
pass through, and everything else will be sourced from the
build.properties.
For the curious, here's the list of variables that become -Dflags to Ant
when starting the build from Eclipse (or from a shell script called by
Hudson):
projectid, buildTimestamp, buildType, version, forceContextQualifier,
fetchTag,
writableBuildRoot, downloadsDir, thirdPartyJarsDir, buildDir, build.steps
relengBuilderDir, relengCommonBuilderDir, relengBaseBuilderDir,
projRelengBranch, commonRelengBranch, basebuilderBranch,
JAVA_HOME, dependencyURLs, repositoryURLs, featureIDsToInstall,
pluginIDsToInstall, projectSetFiles,
localSourceCheckoutDir, localSourceCheckoutDirExcludes, noclean
And these are the variables that are stored in build.cfg as name=value
pairs, to be available from within the build / test processes:
projectid, topprojectName, projectName, subprojectName,
buildType, buildTimestamp, buildAlias, version, branch, build.steps
writableBuildRoot, thirdPartyJarsDir, downloadsDir,
buildDir, relengBuilderDir, relengBaseBuilderDir,
relengCommonBuilderDir, relengCommonScriptsDir,
localSourceCheckoutDir, localSourceCheckoutDirExcludes, noclean,
buildcfg, repositoryURLs, featureIDsToInstall, pluginIDsToInstall,
projectSetFiles
So, in practice, what I do is to make sure everything that will be
needed for all builds (Hudson, Windows, Mac, Linux, whatever) is set in
build.properties, then I copy/rename that file and change the
platform-specific settings in the renamed file.
Or, simpler, just work with build.properties and when you're satisfied
it works, copy and rename it to build.properties.example.whatever for
others to use.
My guess is that all of the Java
target entires are getting populated by default and then not overridden
by the other properties files.
JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
JAVA50_HOME=${JAVA_HOME}
JAVA50_64_HOME=${JAVA_HOME}
JAVA60_HOME=${JAVA_HOME}
JAVA60_64_HOME=${JAVA_HOME}
JAVA14_HOME=${JAVA_HOME}
JAVADOC_HOME=${JAVA_HOME}/bin
Yes, the above prolly won't work. You have to do this:
JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
JAVA50_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
JAVA50_64_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
JAVA60_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
JAVA60_64_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
JAVA14_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
JAVADOC_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/bin
Or try using another variable that doesn't get default-set in
server.properties, like ${MY_JAVA_HOME} instead of ${JAVA_HOME}:
MY_JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
JAVA_HOME=${MY_JAVA_HOME}
JAVA50_HOME=${MY_JAVA_HOME}
JAVA50_64_HOME=${MY_JAVA_HOME}
JAVA60_HOME=${MY_JAVA_HOME}
JAVA60_64_HOME=${MY_JAVA_HOME}
JAVA14_HOME=${MY_JAVA_HOME}
JAVADOC_HOME=${MY_JAVA_HOME}/bin
So it's sort of a bug. Or a feature. Depends on your perspective.
Patches welcome. :)
--
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
