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?
No
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
ResumeConstants.)
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.
--
Rhino
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
