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
compiled.
- 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.
Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
