Note that there are some explanatory texts on larger screens.

plurals
  1. POBest practice for code modification during ant build
    text
    copied!<p>Admitted, this doesn't sound like a best practice altogether, but let me explain. During the build, we need to paste the build number and the system version into a class whose sole purpose is to contain these values and make them accessible.</p> <p>Our first idea was to use system properties, but due to the volatility of the deployment environment (an other way of saying "the sysadmins are doing weird unholy creepy things") we would like to have them hard-coded.</p> <p>Essentially I see 4 possibilities to achieve it in ant : </p> <ol> <li><p><strong>use <code>&lt;replace&gt;</code> on a token in the class</strong></p> <p>The problem with this approach is that the file is changed, so you have to replace the token back after compilation with a <code>&lt;replaceregexp&gt;</code>...sooo ugly, I don't want to touch source code with regex. Plus temporal dependencies.</p></li> <li><p><strong>copy the file, make replace on the copy, compile copy, delete copy</strong> </p> <p>One one has to mind the sequence - the original class has to be compiled first in order to be overwritten by the copy. Temporal dependencies are ugly too. </p></li> <li><p><strong>copy the file, replace the token on the original, compile, replace the stained original with the copy</strong></p> <p>Same temporal dependency issue unless embedded in the compile target. Which is ugly too, because all our build files use the same imported compile target. </p></li> <li><p><strong>create the file from scratch in the build script / store the file outside the source path</strong></p> <p>Is an improvement over the first three as there are no temporal dependencies, but the compiler/IDE is very unhappy as it is oblivious of the class. The red markers are disturbingly ugly.</p></li> </ol> <p>What are your thoughts on the alternatives? </p> <p>Are there any best practices for this?</p> <p>I sure hope I have missed a perfectly sane approach.</p> <p>Thank you</p> <p><strong>EDIT</strong> We ended up using the manifest to store the build number and system version in the <code>Implementation-Version</code> attribute, unsing <code>MyClass.class.getPackage().getImplementationVersion()</code>. I have found this solution was one of the answers to <a href="https://stackoverflow.com/questions/690419/build-and-version-numbering-for-java-projects-ant-cvs-hudson"> <strong>this thread</strong></a>, which was posted in the comment by andersoj</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload