Well, we use the GRADLE_HOME variable. Our project structure is like this:
root
- build
- modules
- buildSrc
- other modules
- tools
- gradle
We have a "gradle.bat" (and "gradle" *nix script file) file in root
directory that sets GRADLE_HOME to tools\gradle. That's where getting
latest from the VCS server will put the currently used Gradle distribution.
This batch/script file also sets up JAVA_HOME and JAVA_OPTS and then calls
the "%GRADLE_HOME%/bin/gradle.bat" file (or appropriate replacement for
*nix). This makes it so that developers don't need to dig under
tools/gradle when running gradle.
So, we are at least one example of this theoretical person. What we would
do if you removed this environment variable is not clear to me, but I doubt
it would be a show stopper, just an inconvenience as we would have to find a
new solution.
John
On Wed, Jan 19, 2011 at 4:29 PM, Adam Murdoch <[email protected]> wrote:
>
> On 20/01/2011, at 7:19 AM, Peter Niederwieser wrote:
>
>
> I'm not against removing GRADLE_HOME if it's unnecessary, but I've never
> considered it a problem either.
>
>
> It occasionally causes grief when people upgrade and forget to change both
> the PATH and the GRADLE_HOME variable.
>
> I use a lot of tools that require a HOME
> variable. For each of them, I have the following in my .profile:
>
> export XYZ_HOME = /app/xyz
> export PATH=$PATH:$XYZ_HOME/bin
>
> I never touch this setup. To switch between versions, I just change the
> /app/xyz symlink. This way I don't have to source .profile after a change.
>
>
> To me, this is complexity we force on every user of Gradle, to support the
> option that someone might want to use the script from one version of Gradle
> to run the code from another version of Gradle. I don't think this is an
> actual use case. As in, I doubt anyone has ever wanted to do this.
>
> It also adds some complexity to Gradle, in that this needs implementing,
> testing, and it forms an implicit cross-version compatibility constraint on
> us.
>
> So, I think we should move the complexity to the (theoretical) person who
> wants this flexibility.
>
>
> --
> Adam Murdoch
> Gradle Developer
> http://www.gradle.org
> CTO, Gradle Inc. - Gradle Training, Support, Consulting
> http://www.gradle.biz
>
>
--
John Murph
Automated Logic Research Team
