You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Rhino <rh...@sympatico.ca> on 2011/10/31 17:55:13 UTC
General Concept Question
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?
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.
Is Ant refusing to compile/use the edited version of the constants file
because it is being edited during the build? I know that Ant variables
are immutable but I thought that it should be possible to edit a file
within a script and then used the edited version of the file later in
the script.
If, in fact, the files that Ant is using are also immutable, what is the
scope of that immutablility? 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?
I'm using Ant 1.8.2 in Eclipse 3.7 on Windows XP SP2.
--
Rhino
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: General Concept Question
Posted by Peter Reilly <pe...@gmail.com>.
the ant task javac will call the command line javac for files that
are changed. In your case ResumeFileGenerator.java has not
changed so only ResumeConstants.java will be compiled to ResumeConstants.class.
However, ResumeFileGenerator.class does not contain references to
ResumeConstants.class,
the constants have been compiled to byte code constants and so you get
the constants that were around when ResumeFileGenerator.class was originally
compiled. For your use-case, it would make more sense to create a
program.configs.property
resource and read in the resource. Alternatively provide a static
method to access the constant in
the generated file:
public class ResumeConstants {
private static final boolean FOO = true;
public static final boolean FOO() {
return FOO;
}
}
public ResumeFileGenerator {
if (ResumeConstants.FOO()) { /* otherwise, print nothing */
System.out.println("XXX");
}
Peter
On Tue, Nov 1, 2011 at 2:46 PM, Rhino <rh...@sympatico.ca> wrote:
>
>
> On 2011-11-01 01:42, Stefan Bodewig wrote:
>>
>> On 2011-10-31, Rhino wrote:
>>
>>> 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.
>>
>> By constants you mean "static final" variables?
>
> Yes.
>>
>> javac inlines static final primitives so in
>>
>> public class A {
>> public static final boolean FOO = true;
>> }
>> public class B {
>> public static boolean BAR = A.FOO;
>> }
>
> No. What I have is a Constants file that looks like this before the build
> script starts running:
>
> public class ResumeConstants {
>
> public static final boolean FOO = true;
> }
>
> That is referenced by another Java class that looks like this:
>
> public ResumeFileGenerator {
>
> if ResumeConstants.FOO { /* otherwise, print nothing */
> System.out.println("XXX");
> }
>
> My build script prompts the person running the script whether FOO should be
> true or false on this run. If it should be false, ResumeConstants is edited
> (and saved), then all the files are compiled, then ResumeFileGenerator runs.
> But ResumeFileGenerator behaves as if FOO is true, even though it has been
> changed to false. A display of FOO in ResumeFileGenerator shows it to be
> true, even though I know I set it to false.
>>
>> B won't even reference the A class after compilation and BAR is set to
>> true. If you later change the value in A and re-compile A but not B the
>> value in B will not change. You just re-compile B as well.
>>
>> This is a Java concept, not an Ant concept 8-)
>
> My Java is rusty too, I'm afraid. I'm not sure if your remark still applies
> now that I've clarified what's actually happening in the code?
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>> For additional commands, e-mail: user-help@ant.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: General Concept Question
Posted by Rhino <rh...@sympatico.ca>.
On 2011-11-01 01:42, Stefan Bodewig wrote:
> On 2011-10-31, Rhino wrote:
>
>> 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.
> By constants you mean "static final" variables?
Yes.
> javac inlines static final primitives so in
>
> public class A {
> public static final boolean FOO = true;
> }
> public class B {
> public static boolean BAR = A.FOO;
> }
No. What I have is a Constants file that looks like this before the
build script starts running:
public class ResumeConstants {
public static final boolean FOO = true;
}
That is referenced by another Java class that looks like this:
public ResumeFileGenerator {
if ResumeConstants.FOO { /* otherwise, print nothing */
System.out.println("XXX");
}
My build script prompts the person running the script whether FOO
should be true or false on this run. If it should be false,
ResumeConstants is edited (and saved), then all the files are compiled,
then ResumeFileGenerator runs. But ResumeFileGenerator behaves as if FOO
is true, even though it has been changed to false. A display of FOO in
ResumeFileGenerator shows it to be true, even though I know I set it to
false.
> B won't even reference the A class after compilation and BAR is set to
> true. If you later change the value in A and re-compile A but not B the
> value in B will not change. You just re-compile B as well.
>
> This is a Java concept, not an Ant concept 8-)
My Java is rusty too, I'm afraid. I'm not sure if your remark still
applies now that I've clarified what's actually happening in the code?
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: General Concept Question
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-10-31, Rhino wrote:
> 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.
By constants you mean "static final" variables?
javac inlines static final primitives so in
public class A {
public static final boolean FOO = true;
}
public class B {
public static boolean BAR = A.FOO;
}
B won't even reference the A class after compilation and BAR is set to
true. If you later change the value in A and re-compile A but not B the
value in B will not change. You just re-compile B as well.
This is a Java concept, not an Ant concept 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: General Concept Question
Posted by Rhino <rh...@sympatico.ca>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: General Concept Question
Posted by Rob Seegel <Ro...@comcast.net>.
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-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org