"available" shouldn't actually load the class; just see if it's resolvable

[David Smiley <ds...@mitre.org>]

Hello.  Recently I got the uddi4j source and I rant it's ant build 
script.  It turns out that it would conditionally compile some extras if 
I have Apache's soap & axis projects on the classpath.  I checked this via:
     <available classname="org.apache.soap.messaging.Message"
                property="apache-soap.available" />
     <available classname="org.apache.axis.Constants"
                property="apache-axis.available" />
Okay, so I rant ant again but I used the -lib option to specify those 
two jars.  However, ant failed to set those two properties!  I did a lot 
of troubleshooting, trying everything, and then I tried the ant -debug 
option which revealed the problem.  Ant was trying to actually load the 
classes in question (instead of just seeing if they are available) 
which in turn caused it to load dependent classes --some of which were 
not on the classpath.

I don't think ant's "available" task should actually load the class. 
Just see if the class is available by doing a getResource or something 
like that.

~ David Smiley
   MITRE


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Re: "available" shouldn't actually load the class; just see if it's resolvable

[Conor MacNeill <co...@cortexebusiness.com.au>]

David Smiley wrote:
> 
> I suggest the name "load" instead since that is the java vernacular for 
> what's happening.
> 
> I also suggest that the next snapshot implementing this have it default 
> to "false" and we'll get a feel for wether this is a problem at that time.
> 

Unfortunately that would not be backward compatible. If you want new 
behaviour, it needs to be explicitly enabled, IMHO.

Conor

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Re: "available" shouldn't actually load the class; just see if it's resolvable

[David Smiley <ds...@mitre.org>]

Peter Reilly wrote:
> David Smiley wrote:
> 
>> Does anyone want to offer their opinion?  It should be an easy change 
>> and I think it would be very unlikely if this broke any existing builds.
> 
> 
> It will break some builds.
> Using the current method, the script knows that the class is present and 
> useable, and so it can be used later in the build.
> Peter
> 

I believe the primary use of "available" is to conditionally compile 
code against.  The class's follow-on dependancies don't need to be 
present for this common use-case.  My suggestion here is only a problem 
if (a) you really do want to load the class because you need to execute 
code spawned from ant, and (b) the follow-on dependancies if any are not 
available.

I'd also like to recommend that ant explain what follow-on class is 
preventing "available" from succeeding without having to enable ant's 
debug mode.

Dominique wrote:
> I think it's a reasonable request, but to keep the former behavior
> as-is, I'd simply add an initialize="true|false" attribute, to mirror's
> Java's Class#forName overload. The attribute would default to true, and
> you'd be able to set it explicitly to false. --DD

I suggest the name "load" instead since that is the java vernacular for 
what's happening.

I also suggest that the next snapshot implementing this have it default 
to "false" and we'll get a feel for wether this is a problem at that time.

~ David Smiley
   MITRE


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

Re: "available" shouldn't actually load the class; just see if it's resolvable

[Peter Reilly <pe...@apache.org>]

David Smiley wrote:

> Does anyone want to offer their opinion?  It should be an easy change 
> and I think it would be very unlikely if this broke any existing builds.

It will break some builds.
Using the current method, the script knows that the class is present and 
useable, and so it can be used later in the build.
Peter

>
> ~ Dave
>
> David Smiley wrote:
>
>> Hello.  Recently I got the uddi4j source and I rant it's ant build 
>> script.  It turns out that it would conditionally compile some extras 
>> if I have Apache's soap & axis projects on the classpath.  I checked 
>> this via:
>>     <available classname="org.apache.soap.messaging.Message"
>>                property="apache-soap.available" />
>>     <available classname="org.apache.axis.Constants"
>>                property="apache-axis.available" />
>> Okay, so I rant ant again but I used the -lib option to specify those 
>> two jars.  However, ant failed to set those two properties!  I did a 
>> lot of troubleshooting, trying everything, and then I tried the ant 
>> -debug option which revealed the problem.  Ant was trying to actually 
>> load the classes in question (instead of just seeing if they are 
>> available) which in turn caused it to load dependent classes --some 
>> of which were not on the classpath.
>>
>> I don't think ant's "available" task should actually load the class. 
>> Just see if the class is available by doing a getResource or 
>> something like that.
>>
>> ~ David Smiley
>>   MITRE
>
>
>
> ---------------------------------------------------------------------
> 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: "available" shouldn't actually load the class; just see if it's resolvable

[David Smiley <ds...@mitre.org>]

Does anyone want to offer their opinion?  It should be an easy change 
and I think it would be very unlikely if this broke any existing builds.

~ Dave

David Smiley wrote:
> Hello.  Recently I got the uddi4j source and I rant it's ant build 
> script.  It turns out that it would conditionally compile some extras if 
> I have Apache's soap & axis projects on the classpath.  I checked this via:
>     <available classname="org.apache.soap.messaging.Message"
>                property="apache-soap.available" />
>     <available classname="org.apache.axis.Constants"
>                property="apache-axis.available" />
> Okay, so I rant ant again but I used the -lib option to specify those 
> two jars.  However, ant failed to set those two properties!  I did a lot 
> of troubleshooting, trying everything, and then I tried the ant -debug 
> option which revealed the problem.  Ant was trying to actually load the 
> classes in question (instead of just seeing if they are available) which 
> in turn caused it to load dependent classes --some of which were not on 
> the classpath.
> 
> I don't think ant's "available" task should actually load the class. 
> Just see if the class is available by doing a getResource or something 
> like that.
> 
> ~ David Smiley
>   MITRE


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org