Source modifying before compile

(Alexey Plotnikov) #1

I can not find. Is this good practice? I have file with some static final properties, like:

public static final String VERSION = "1.0";
public static final boolean DEBUG = true;

I want, next: 1) have buildDebug task which before compile modifies and sets DEBUG to true 2) have buildRelease task which before compile modifies and sets DEBUG to false So, after compile, class files will include or exclude some code in if (DEBUG) conditions 3) everytime before compile, field VERSION in must sets from variable version in build.gradle

(Chris Marks) #2

A lot of this depends on the context in which you are using this. For the version, typically you externalize this to a properties file, then have a class that reads in the properties file. The properties file is easier to change than modifying source code. For the debug flag, is this to enable debug logging, or is it to enable other functionality. If logging, typically you handle this using the logging level of the logging framework you are using, then use that frameworks’ functions to determine if the level is enabled (ex: LOG.isDebugEnabled() in log4j or slf4j). If for other functionality, again using an externalized properties file would be better to deal with. Modifying source code is not usually something a build system like Gradle should do.

(Alexey Plotnikov) #3
  1. for VERSION, i agree, i can use with property
version = 1.0

and package this file into war file, and during initial context i can read this file for version initialization 2) you are right about DEBUG, but you don’t know all my variables :). I’ll explane. I have another variable

public static final boolean WOA = true;

what’s mean - “WITHOUT AUTHORIZATION”. So, my application, can works without authorization(functionality conditions), but than i build my application via properties file, my class files will contains conditions

if (WOA) {

But i don’t want it!!! For production, i want have classes without condition above.