ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Seegel <>
Subject Re: General Concept Question
Date Tue, 01 Nov 2011 11:52:05 GMT
Just to be sure I understand here... you have one or more source files 
where some of the values get replaced by the build prior to building the 
Java code, right? I suspect that this might be more of an  Eclipse issue 
than an Ant issue.

On 10/31/11 12:55 PM, Rhino wrote:
>  Is there a fundamental concept in Ant that says, in effect, a file 
> should not be edited during a build because only the original version 
> will ever be seen by the tasks in the build?
No - but a general rule of thumb I try to follow when doing something 
like this:

   - Never modify a file in the src directory when doing a build
   - If you should modify a file, then modify a copy of it leaving the 
original intact under the src directory.

Modifying source files in the src (or src/main/java ) leaves you 
vulnerable to accidental check-ins/commits in version control. I find 
it's always better to stage this sort of substitution to a working 
directory. Where substitutions and follow-on steps might be done. Such 
as the one you're trying to do. If I'm doing something like this, I 
usually override existing copied files in my staging area, or I provide 
something to check which configuration I'm building. Often, I will have 
various *.cfg files I create that define a particular configuration. 
It's basically a property file.

I'm personally not a fan of burying changes like you suggest directly 
into the code. I tend to prefer putting settings like you describe into 
property files, that get included into a jar/war/ear/whatever, and read 
them into the class that needs them at runtime. Regardless, what you're 
doing should be possible.
> I have an Ant script that changes the value of some constants in a 
> constants file that is used later by a Java program. The edits are 
> pretty trivial in nature - three booleans get set to false instead of 
> their normal value of true - and then the Java program which uses them 
> is supposed to change its behavior according to the new values of the 
> booleans. But even though I am sure the edits are being done and that 
> the .java files are only compiled after the edits have been completed, 
> the Java program continues to see the booleans as true, even when they 
> are not.
Here are things I'd check...

-  Are you certain Eclipse is not trying to build your workspace before 
your ant script runs?

By default, when you invoke an Ant script within Eclipse for the first 
time, Eclipse creates a Ant runtime configuration for you, and this 
configuration is set to build the project/workspace prior to running the 
build script. This will potentially create a situation where Eclipse 
compiles your code, and then once the script is run, your build may not 
do all expected tasks because it appears your code has already been 

- Do you have Build Automatically enabled in Eclipse while you're doing 
your build?
> If, in fact, the files that Ant is using are also immutable, what is 
> the scope of that immutablility?
They are not. Though you can run into File locking on some platforms 
when executing tasks in parallel. Most people running relatively simple 
builds probably won't encounter this.
> I'm wondering if I could make two scripts - one to edit the constants 
> file and one to use the edited constants file - both initiated by some 
> kind of Master script that runs the editing script first, then the 
> script that uses the edited file. Or is there a better approach?
If it helps you to make your build more readable and maintainable by 
breaking into smaller files, then why not? However, it's most likely 
unnecessary to do what you want to do.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message