Open silbinarywolf opened 6 years ago
If your intent is for the build.properties to be standardised across the project, then I'd rather just commit build.properties directly, and have buildfile refer to something like mysite/build/build.properties
Originally, build.properties could be configured per-developer, though I suspect over time this has become a less utilised capability, so is likely better served as a project specific thing
I dont disagree with the above. That is a nicer solution and it means we can make the build properties varied on a per-project level.
The issue I have currently is that build.properties gets created in the build
module folder for no good reason. I'm assuming we used to just commit the entire build module into a repo.
If you want me to do a PR for making build.properties.sample be copied to mysite/build/build.properties, I can do so :)
Yeah, if you can take a look at it that'd be ace.
@nyeholt Is it fine if the mysite/build/build.properties
file inherits everything from build/build.properties.sample
?
That way the per-project configuration can simply contain the additional changes / deviations. I reckon it will make it easier to reason about how much it deviates from the base. (and the lack of its existence could just mean... only use the .sample?)
As discussed, we wont do any inheritance considering issues previously hit with configs not applying as expected / etc.
Gives us to less to think about and will probably be less error-prone.
@nyeholt any update on this one?
The problem For some reason, the
build.properties.sample
file will copy itself tobuild.properties
within the same folder. This caused me to hit an issue where I:build.properties
, which only gets generated when you first spin up the project. Keep in mind this file is generated within thebuild
module folder so it is not committed up.The solution Just use
build.properties.sample
within buildfile.xml and remove all references tobuild.properties.