Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dash-dev] Re: Athena OS X Local Build 
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

Back to the top