Quantcast

warning: 'includeantruntime' was not set

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

warning: 'includeantruntime' was not set

Karsten Wutzke
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Stefan Bodewig
On 2010-08-18, <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Chet Hosey
In reply to this post by Karsten Wutzke
On Wed, Aug 18, 2010 at 10:14 AM,  <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Jesse Glick-2
In reply to this post by Karsten Wutzke
On 08/18/2010 10:14 AM, [hidden email] 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Matt Benson-2

On Aug 18, 2010, at 11:15 AM, Jesse Glick wrote:

> On 08/18/2010 10:14 AM, [hidden email] 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Karsten Wutzke
In reply to this post by Jesse Glick-2
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 <[hidden email]>
Gesendet: 18.08.2010 18:15:32
An: [hidden email]
Betreff: Re: warning: 'includeantruntime' was not set

>On 08/18/2010 10:14 AM, [hidden email] 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: [hidden email]
>For additional commands, e-mail: [hidden email]
>
___________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Karsten Wutzke
In reply to this post by Matt Benson-2
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 <[hidden email]>
Gesendet: 18.08.2010 18:31:51
An: Ant Developers List <[hidden email]>
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, [hidden email] 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
___________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Jesse Glick-2
In reply to this post by Matt Benson-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Matt Benson-2

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Karsten Wutzke
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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
___________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Jesse Glick-2
In reply to this post by Matt Benson-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Peter Reilly-2
We have a policy of keeping stupid historical defaults.

Peter


On Wed, Aug 18, 2010 at 10:21 PM, Jesse Glick <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Karsten Wutzke
+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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>
___________________________________________________________
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Chet Hosey-2
On Thu, Aug 19, 2010 at 5:16 AM, Karsten Wutzke <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Nicolas Lalevée

Le 19 août 2010 à 17:19, Chet Hosey a écrit :

> On Thu, Aug 19, 2010 at 5:16 AM, Karsten Wutzke <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

Jesse Glick-2
In reply to this post by Chet Hosey-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

rop
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

rop
This post has NOT been accepted by the mailing list yet.
In reply to this post by Jesse Glick-2
Im kinda novice on ant, but wouldnt it be more logical that the includeantruntime property goes on the [classpath] tag (inside [javac]), rather than directly on the [javac] tag?
rop
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: warning: 'includeantruntime' was not set

rop
This post has NOT been accepted by the mailing list yet.


2011/9/26 rop [via Ant] <[hidden email]>
Im kinda novice on ant, but wouldnt it be more logical that the includeantruntime property goes on the [classpath] tag (inside [javac]), rather than directly on the [javac] tag?


If you reply to this email, your message will be added to the discussion below:
http://ant.1045680.n5.nabble.com/warning-includeantruntime-was-not-set-tp2639463p4841599.html
To unsubscribe from warning: 'includeantruntime' was not set, click here.

Loading...