Re: warning: 'includeantruntime' was not set
On 08/19/2010 11:19 AM, Chet Hosey wrote: Perhaps the project tag could be given a behavior attribute Note that there is the antversion condition which lets you enforce a minimum version of Ant, but this is procedural rather than declarative so Ant cannot tell what version of Ant your script expects to be using and adjust its own behavior accordingly. I had long ago suggested a version attribute on project but the response was the new condition - more flexible for the user but unusable for this purpose. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
We have a policy of keeping stupid historical defaults. Peter On Wed, Aug 18, 2010 at 10:21 PM, Jesse Glick jesse.gl...@oracle.com wrote: On 08/18/2010 02:27 PM, Matt Benson wrote: I would still guess that more builds than not DON'T need to compile against Ant itself. Of course; at least an order of magnitude more. But those that do will be *broken* if your suggested change is made, whereas those that don't get a *warning* currently. My inclination was to err on the conservative side and retain compatibility even at the cost of a little inconvenience. Call a vote if you want to change the default and break compatibility. 1.8.0 and 1.8.1 have the warning, so a break in 1.8.2 would only affect those who ignored the warning for two prior releases. I don't know if Ant generally has a policy for fixing stupid historical defaults, like failonerror=false. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
+1 for giving up the policy of keeping stupid historical defaults. :-) Seriously, it doesn't make sense for this issue to keep it. But I doubt this will be realized. Karsten We have a policy of keeping stupid historical defaults. Peter On Wed, Aug 18, 2010 at 10:21 PM, Jesse Glick jesse.gl...@oracle.com wrote: On 08/18/2010 02:27 PM, Matt Benson wrote: I would still guess that more builds than not DON'T need to compile against Ant itself. Of course; at least an order of magnitude more. But those that do will be *broken* if your suggested change is made, whereas those that don't get a *warning* currently. My inclination was to err on the conservative side and retain compatibility even at the cost of a little inconvenience. Call a vote if you want to change the default and break compatibility. 1.8.0 and 1.8.1 have the warning, so a break in 1.8.2 would only affect those who ignored the warning for two prior releases. I don't know if Ant generally has a policy for fixing stupid historical defaults, like failonerror=false. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org ___ WEB.DE DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 ¿/mtl.!* http://web.de/DSL-Doppel-Flatrate/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
On Thu, Aug 19, 2010 at 5:16 AM, Karsten Wutzke kwut...@web.de wrote: +1 for giving up the policy of keeping stupid historical defaults. :-) Seriously, it doesn't make sense for this issue to keep it. But I doubt this will be realized. Karsten Perhaps the project tag could be given a behavior attribute that would allow change over time. With none given, Ant would use historical defaults. Other defaults could be used when it was specified. For example, setting project behavior to 1.8.2 or above would cause javac to default to includeantruntime=False. But with no behavior attribute, or behavior = 1.8.1, the historical defaults would apply. Optionally, a magic value of behavior=sane would cause Ant to use its own native defaults. This would mollify those willing to risk behavior changes across Ant upgrades to get reasonable defaults. Thoughts? -- Chet Hosey - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
Le 19 août 2010 à 17:19, Chet Hosey a écrit : On Thu, Aug 19, 2010 at 5:16 AM, Karsten Wutzke kwut...@web.de wrote: +1 for giving up the policy of keeping stupid historical defaults. :-) Seriously, it doesn't make sense for this issue to keep it. But I doubt this will be realized. Karsten Perhaps the project tag could be given a behavior attribute that would allow change over time. With none given, Ant would use historical defaults. Other defaults could be used when it was specified. For example, setting project behavior to 1.8.2 or above would cause javac to default to includeantruntime=False. But with no behavior attribute, or behavior = 1.8.1, the historical defaults would apply. Optionally, a magic value of behavior=sane would cause Ant to use its own native defaults. This would mollify those willing to risk behavior changes across Ant upgrades to get reasonable defaults. Thoughts? This is a very interesting idea. It can be similar to the ivy-module version in the ivy.xml. In project we would specify the version of Ant which is expected to parse correctly the build.xml. Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
warning: 'includeantruntime' was not set
Hello, I'm writing because I didn't receive any answer when asking the following on the users mailing list: Why does Ant warn me about this?: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable build Is it important? Who needs to know? I don't care. Why doesn't Ant just default to false and just omit warning me about this for every Ant build? I don't want adjust every build file that I have. There are probably other ways, but it's annoying anyhow. Karsten ___ WEB.DE DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 ¿/mtl.!* http://web.de/DSL-Doppel-Flatrate/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
On 2010-08-18, kwut...@web.de wrote: I'm writing because I didn't receive any answer when asking the following on the users mailing list: Why does Ant warn me about this?: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable build Because you are not setting the includeantruntime attribute ;-) Seriously, by not setting the attribute at all, your javac task gets your system CLASSPATH in addition to the one that you've specified explicitly which means it will be different accross different machines (or can be different) - hence the warning. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
On 08/18/2010 10:14 AM, kwut...@web.de wrote:
Why doesn't Ant just default to false and just omit warning me about this for
every Ant build?
That would be an incompatible change. Some old build scripts may be intentionally compiling sources against ant.jar (typically because they define Ant tasks), tools.jar
(who knows why), etc. They also ought to set includeantruntime=false but then explicitly add the desired classpath, e.g. pathelement location=${ant.core.lib}/. (The
warning will also go away if you set includeantruntime=true, but this will make your script be less portable.)
I agree that it is irritating to issue this warning so often, but the alternative of breaking compatibility even for a minority of existing scripts seems worse. There are
similar places in Ant where an old default was a bad choice but cannot now be changed compatibly.
(You could also define ANT_OPTS=-Dbuild.sysclasspath=ignore for yourself but
this will not help other people running your script.)
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
On Aug 18, 2010, at 11:15 AM, Jesse Glick wrote:
On 08/18/2010 10:14 AM, kwut...@web.de wrote:
Why doesn't Ant just default to false and just omit warning me about this
for every Ant build?
That would be an incompatible change. Some old build scripts may be
intentionally compiling sources against ant.jar (typically because they
define Ant tasks), tools.jar (who knows why), etc. They also ought to set
includeantruntime=false but then explicitly add the desired classpath, e.g.
pathelement location=${ant.core.lib}/. (The warning will also go away if
you set includeantruntime=true, but this will make your script be less
portable.)
I agree that it is irritating to issue this warning so often, but the
alternative of breaking compatibility even for a minority of existing scripts
seems worse. There are similar places in Ant where an old default was a bad
choice but cannot now be changed compatibly.
(You could also define ANT_OPTS=-Dbuild.sysclasspath=ignore for yourself but
this will not help other people running your script.)
Personally, I would vote that we break backward-compatibility on this issue,
and require those running such ancient buildfiles to declare build.sysclasspath
if they DO want the system classpath appended.
-Matt
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
Thanks Stefan and Jesse, I now understand that this change had to be made. Setting this per Ant installation is consequently the same as setting an env var, so I will bow down and change all my build files accordingly. Karsten -Ursprüngliche Nachricht- Von: Jesse Glick jesse.gl...@oracle.com Gesendet: 18.08.2010 18:15:32 An: dev@ant.apache.org Betreff: Re: warning: 'includeantruntime' was not set On 08/18/2010 10:14 AM, kwut...@web.de wrote: Why doesn't Ant just default to false and just omit warning me about this for every Ant build? That would be an incompatible change. Some old build scripts may be intentionally compiling sources against ant.jar (typically because they define Ant tasks), tools.jar (who knows why), etc. They also ought to set includeantruntime=false but then explicitly add the desired classpath, e.g. . (The warning will also go away if you set includeantruntime=true, but this will make your script be less portable.) I agree that it is irritating to issue this warning so often, but the alternative of breaking compatibility even for a minority of existing scripts seems worse. There are similar places in Ant where an old default was a bad choice but cannot now be changed compatibly. (You could also define ANT_OPTS=-Dbuild.sysclasspath=ignore for yourself but this will not help other people running your script.) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org ___ WEB.DE DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 ¿/mtl.!* http://web.de/DSL-Doppel-Flatrate/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
I forgot that I had this in mind, too! +1 for breaking backward compatibility and require those who need the sysclasspath explicitly. Karsten -Ursprüngliche Nachricht- Von: Matt Benson gudnabr...@gmail.com Gesendet: 18.08.2010 18:31:51 An: Ant Developers List dev@ant.apache.org Betreff: Re: warning: 'includeantruntime' was not set On Aug 18, 2010, at 11:15 AM, Jesse Glick wrote: On 08/18/2010 10:14 AM, kwut...@web.de wrote: Why doesn't Ant just default to false and just omit warning me about this for every Ant build? That would be an incompatible change. Some old build scripts may be intentionally compiling sources against ant.jar (typically because they define Ant tasks), tools.jar (who knows why), etc. They also ought to set includeantruntime=false but then explicitly add the desired classpath, e.g. . (The warning will also go away if you set includeantruntime=true, but this will make your script be less portable.) I agree that it is irritating to issue this warning so often, but the alternative of breaking compatibility even for a minority of existing scripts seems worse. There are similar places in Ant where an old default was a bad choice but cannot now be changed compatibly. (You could also define ANT_OPTS=-Dbuild.sysclasspath=ignore for yourself but this will not help other people running your script.) Personally, I would vote that we break backward-compatibility on this issue, and require those running such ancient buildfiles to declare build.sysclasspath if they DO want the system classpath appended. -Matt - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org ___ Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
On Wed, Aug 18, 2010 at 10:14 AM, kwut...@web.de wrote: Why does Ant warn me about this?: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable build Historically, Ant always included its own runtime in the classpath made available to the javac task. So any libraries included with Ant, and any libraries available to ant, are automatically in your build's classpath whether you like it or not. It was decided that this probably wasn't what most people wanted. So now there's an option for it. Is it important? Yes. It calls your attention to an issue that can make your builds to work in unexpected ways. For an example, see item #3 at http://blogs.sun.com/kto/entry/painful_ant_bite_a_generous. If you choose true, then at least you know that your build classpath will include the Ant runtime. If you choose false then you are accepting the fact that the build behavior will change between older versions and 1.8+. Who needs to know? I don't care. If you want your build file to have total control over your build, then you should care. Why doesn't Ant just default to false and just omit warning me about this for every Ant build? I don't want adjust every build file that I have. There are probably other ways, but it's annoying anyhow. As annoyed as you are to see this warning, you'd be even less happy if your builds broke entirely. Keeping this default behavior allows unmodified build files to work consistently between versions of Ant. -- Chet - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
On 08/18/2010 12:31 PM, Matt Benson wrote: require those running such ancient buildfiles Unfortunately they need not be so ancient. I have come across more than one build.xml from an actively developed project which just assumed that sources could be compiled against org.apache.tools.ant.** without doing anything. Of course fixing such a script is easy if you know what is wrong, but the authors (or new maintainers) may not know what to do when a new Ant release breaks their build. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
On Aug 18, 2010, at 12:56 PM, Jesse Glick wrote: On 08/18/2010 12:31 PM, Matt Benson wrote: require those running such ancient buildfiles Unfortunately they need not be so ancient. I have come across more than one build.xml from an actively developed project which just assumed that sources could be compiled against org.apache.tools.ant.** without doing anything. Of course fixing such a script is easy if you know what is wrong, but the authors (or new maintainers) may not know what to do when a new Ant release breaks their build. Okay, maybe ancient was a poor choice of words, but I would still guess that more builds than not DON'T need to compile against Ant itself. -Matt - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
I agree with that entirely. It will be less effort for a few to adopt the new Ant behavoir than annoy many. Furthermore, I believe many Ant newcomers will think Ant or their dev setup is broken given that warning. Karsten On Aug 18, 2010, at 12:56 PM, Jesse Glick wrote: On 08/18/2010 12:31 PM, Matt Benson wrote: require those running such ancient buildfiles Unfortunately they need not be so ancient. I have come across more than one build.xml from an actively developed project which just assumed that sources could be compiled against org.apache.tools.ant.** without doing anything. Of course fixing such a script is easy if you know what is wrong, but the authors (or new maintainers) may not know what to do when a new Ant release breaks their build. Okay, maybe ancient was a poor choice of words, but I would still guess that more builds than not DON'T need to compile against Ant itself. -Matt - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org ___ Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: warning: 'includeantruntime' was not set
On 08/18/2010 02:27 PM, Matt Benson wrote: I would still guess that more builds than not DON'T need to compile against Ant itself. Of course; at least an order of magnitude more. But those that do will be *broken* if your suggested change is made, whereas those that don't get a *warning* currently. My inclination was to err on the conservative side and retain compatibility even at the cost of a little inconvenience. Call a vote if you want to change the default and break compatibility. 1.8.0 and 1.8.1 have the warning, so a break in 1.8.2 would only affect those who ignored the warning for two prior releases. I don't know if Ant generally has a policy for fixing stupid historical defaults, like failonerror=false. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
