ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rhino <>
Subject Re: General Concept Question
Date Thu, 17 Nov 2011 14:17:52 GMT

This is a (very) belated reply to Rob's remarks but hopefully he or 
others will still be able to help.... (Sorry, I got sidetracked on other 
things for a while).

On 2011-11-01 07:52, Rob Seegel wrote:
> 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?
See my reply to Stefan Bodewig for (perhaps) a clearer explanation of 
what the code is actually doing.
> 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'm not sure WHICH code you're talking about when you say "directly into 
the code". Originally, I was changing those booleans directly in the 
ResumeConstants file prior to the build but I thought it would be more 
elegant to have the Ant script prompt the user each time to see what the 
values of the three booleans should be on this run. Basically, rather 
than doing it directly in the JAVA code, I thought I'd let Ant do the 
job. But this might be portrayed as doing it directly in the ANT code 
instead of the Java code.
>> 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 compiled.
Remind me how I can determine if Eclipse is rebuilding my workspace 
before the script runs? I just checked and "Build Automatically" is not 
checked under the Project menu, which answers your next question, but 
I'm not sure how to determine the answer to THIS question.
> - 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.
I found a simple way to ensure that the edits of my boolean switches ARE 
respected by my classes: I deleted the class files that used the boolean 
switches just before running the compile step. (When I ran the build 
with -verbose on, I found that javac was not recompiling the files so I 
forced the recompile by deleting all class files that used 

I'm guessing that this is a bad thing to do though, right? Earlier in 
your reply, you mention accidental check-ins and commits in version 
control. Now, I have to tell you that this is just a one man shop and 
I'm not really doing version control in the formal way that you are 
describing so I feel I can get away away with this approach for now. But 
I expect an observer would criticize me for an unprofessional setup if 
he/she knew that I wasn't doing proper version control.

Unfortunately, I don't really know that much about it. I've been a one 
man shop for quite a while. But I'd like to redress this and institute a 
proper version control system, ideally, something that works well with 
Eclipse. I actually installed Subversion at one point but never really 
got fluent with it. Is that a good tool for this job? If not, can you 
suggest better ones? Also, can anyone point me to tutorials that would 
help me get the whole general framework of a modern version control 
system established and working? For instance, I've never been clear on 
when you should make a new branch and when a given change to the code is 
too minor to bother with that.


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

View raw message