ANT Contrib

On Wed, 26 Jan 2005, Curt Arnold <carnold@...> wrote:

> I'm not using VerifyDesign, but it seems that doing:
> 
>          <taskdef
>             resource="net/sf/antcontrib/antcontrib.properties"/>
> 
> requires BCEL to be on the classpath.

Yes, that's how <taskdef> works in Ant < 1.6.

If you can live with Ant >= 1.6.0, you could simply add
onerror="ignore" to your <taskdef>.

We should probably include that in the docs.

Stefan

On Jan 26, 2005, at 1:47 AM, Stefan Bodewig wrote:

> On Wed, 26 Jan 2005, Curt Arnold <carnold@...> wrote:
>
>> I'm not using VerifyDesign, but it seems that doing:
>>
>>          <taskdef
>>             resource="net/sf/antcontrib/antcontrib.properties"/>
>>
>> requires BCEL to be on the classpath.
>
> Yes, that's how <taskdef> works in Ant < 1.6.
>
> If you can live with Ant >= 1.6.0, you could simply add
> onerror="ignore" to your <taskdef>.
>
> We should probably include that in the docs.
>
> Stefan
>


Unfortunately, it would have the effect of breaking every build file 
that used ant-contrib until BCEL was included in their classpath.  I 
think we really need to avoid adding a run-time dependency on BCEL 
unless the BCEL dependent tasks are being used.

I could see a couple of ways to address the problem.  One would be to 
add distinct taskdef and antlib resources for the BCEL dependent tasks. 
  Another would be to separate the task definition from the 
implementation and have the VerifyDesign task only attempt to load 
VerifyDesignImpl when executed.

On Wed, 26 Jan 2005, Curt Arnold <carnold@...> wrote:
> On Jan 26, 2005, at 1:47 AM, Stefan Bodewig wrote:
> 

>> If you can live with Ant >= 1.6.0, you could simply add
>> onerror="ignore" to your <taskdef>.
>>
> 
> Unfortunately, it would have the effect of breaking every build file
> that used ant-contrib until BCEL was included in their classpath.

True.

So the most simple solustion is what Matt suggest.  Remove the tasks
that require Ant 1.6+ or BCEL from the properties file and only add
them to antlib.xml.

Document that Ant 1.6 users should either use namespace and Ant
auto-detection or point the resource attribute to antlib.xml.

> Another would be to separate the task definition from the
> implementation and have the VerifyDesign task only attempt to load
> VerifyDesignImpl when executed.

This has merits of its own.  For example if you wanted to base your
implementation on ASM <http://asm.objectweb.org/> instead of BCEL.

Stefan

On Jan 27, 2005, at 2:18 AM, Stefan Bodewig wrote:

> On Wed, 26 Jan 2005, Curt Arnold <carnold@...> wrote:
>> On Jan 26, 2005, at 1:47 AM, Stefan Bodewig wrote:
>>
>
>>> If you can live with Ant >= 1.6.0, you could simply add
>>> onerror="ignore" to your <taskdef>.
>>>
>>
>> Unfortunately, it would have the effect of breaking every build file
>> that used ant-contrib until BCEL was included in their classpath.
>
> True.

> So the most simple solustion is what Matt suggest.  Remove the tasks
> that require Ant 1.6+ or BCEL from the properties file and only add
> them to antlib.xml.
>
> Document that Ant 1.6 users should either use namespace and Ant
> auto-detection or point the resource attribute to antlib.xml.
>
>> Another would be to separate the task definition from the
>> implementation and have the VerifyDesign task only attempt to load
>> VerifyDesignImpl when executed.
>
> This has merits of its own.  For example if you wanted to base your
> implementation on ASM <http://asm.objectweb.org/> instead of BCEL.
>

Matt Inger separated out the BCEL dependent code into 
VerifyDesignDelegate on the 26th.  So the immediate problem that I 
reported is likely resolved.

I think the minimum requirement is that the taskdef resource not throw 
a ClassNotFoundException with Ant 1.5.  There is a Gump build of Ant 
1.5, so it shouldn't be too hard to configure an Gump project to check 
the compatibility.  I think that is likely desirable that tasks that 
require 1.6 to execute, but not to load, still appear in the taskdef 
resource.  That would allow the same build file to be able to execute 
on both 1.5 and 1.6 as long as none of the 1.6 dependent tasks were 
executed.

Several tasks depend on 1.6.2 to compile, I don't know their run-time 
behavior.  It is possible that we might want to add an ant-160 Gump 
build and do the same thing with it.