Allow all local.properties flags to be overridden by environment

[advayDev1]

Fixes #360

BREAKING API CHANGE:
J2OBJC_HOME environment value will now override j2objc.home
in local.properties instead of the other way around.

[advayDev1]

@brunobowden ptal. please do #358 first

[brunobowden]

Is there a precedence for this precedence? E.g. that the JVM or other tools have similar behaviour?

I've tried searching online but didn't get a good answer for this. The only example I could find seemed to suggest that local properties took precedence over the environment. I'm think that a system that has gone through battle testing on this front would have sound reasons for doing it that way. We should be careful about doing something difference.

http://www.javacodegeeks.com/2012/02/properties-with-spring.html

4.1 Properties Search Precedence
By default, in Spring 3.1, local properties are search last, after all environment property sources, including properties files. This behavior can be overridden via the localOverride property of the PropertySourcesPlaceholderConfigurer, which can be set to true to allow local properties to override file properties.

In Spring 3.0 and before, the old PropertyPlaceholderConfigurer also attempted to look for properties both in the manually defined sources as well as in the System properties. The lookup precedence was also customizable via the systemPropertiesMode property of the configurer:
never – Never check system properties

fallback (default) – Check system properties if not resolvable in the specified properties files
override – Check system properties first, before trying the specified properties files. This allows system properties to override any other property source.

Finally, note that in case a property is defined in two or more files defined via @propertysource – the last definition will win and override the previous ones. This makes the exact property value hard to predict, so if overriding is important, the PropertySource API can be used instead.

[advayDev1]

So does Android I guess:
https://android.googlesource.com/platform/tools/build/+/master/gradle/src/main/groovy/com/android/build/gradle/internal/Sdk.groovy

alright, I'll swap the priority order back to properties overrides environment

[brunobowden]

Another issue we'll have for the future... is when build.gradle allows you
to specific the J2ObjC version, we'll likely want that to be the preferred
configuration system.

On Wed, Aug 19, 2015 at 11:08 AM Advay Mengle [email protected]
wrote:

So does Android I guess:

https://android.googlesource.com/platform/tools/build/+/master/gradle/src/main/groovy/com/android/build/gradle/internal/Sdk.groovy

alright, I'll swap the priority order back to properties overrides
environment

—
Reply to this email directly or view it on GitHub
#361 (comment)
.

[advayDev1]

ptal @brunobowden - put the order back to the way it was

[brunobowden]

Empty line afterwards

[advayDev1]

done

[brunobowden]

LGTM - it would be nice to add a test for Utils.groovy for loading a property from an environment variable.

[advayDev1]

filed a bug for mocking System.getenv - not sure how to at the moment

[brunobowden]

Just add a TODO for now.

Nice update from Travis:

[advayDev1]

Actually, it is baffling as it is a failure in JDK 8.0 only. JDK 7.0 is
working. Digging into it...

On Thu, Aug 20, 2015 at 10:20 AM Bruno Bowden [email protected]
wrote:

Just add a TODO for now.

Nice update from Travis:

[image: screen shot 2015-08-20 at 10 19 41 am]
https://cloud.githubusercontent.com/assets/679339/9390276/03c7074e-4725-11e5-8c2d-6687176c5bfd.png

—
Reply to this email directly or view it on GitHub
#361 (comment)
.

[madvayApiAccess]

well the tests are passing now. looks like we are flaky on JDK8 - i reran various commits on Travis over and over and JDK8 sometimes fails, sometimes passes.

i'm sending a PR to provide more info on such failures. right now it just tells you to look at the testreport.html which obviously we can't.

[brunobowden]

It would be helpful to have a more detailed record, including the
testreport.html. Can that be maintained for a brief period, e.g. 24 hours?

On Thu, Aug 20, 2015 at 11:08 AM madvay public repo API account <
[email protected]> wrote:

well the tests are passing now. looks like we are flaky on JDK8 - i reran
various commits on Travis over and over and JDK8 sometimes fails, sometimes
passes.

i'm sending a PR to provide more info on such failures. right now it just
tells you to look at the testreport.html which obviously we can't.

—
Reply to this email directly or view it on GitHub
#361 (comment)
.

[advayDev1]

We can't see the HTML file, but we can get the exception details:
http://mrhaki.blogspot.com/2013/05/gradle-goodness-show-more-information.html

see PR #373