Introspection Change comments

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

I would like to get some feedback on a change I am considering. With the
current Introspection nested element support, the task's method
corresponding to the nested element is called before the nested element is
configured. I would like to add a mechanism to support the calling of this
method after the element is configured. This will only work for addXXX
style methods since for those methods the object creation can occur without
involving the task.

I have implemented this (the diff is attached), by checking for a method
addConfiguredXXX, rather than simply addXXX. The diff includes changes to
the Jar task to allow a manifest to be specified in the build file directly

    <jar jarfile="taskjar2.jar" basedir=".">
      <include name="src/**/*"/>
      <manifest>
        <attribute name="created-by" value="me"/>
        <section name="foobar">
          <attribute name="Sealed" value="True"/>
        </section>
      </manifest>
    </jar>

Now, my main concern is with the use of addConfigured. It is potentially a
compatibility issue if some custom task has a nested element
<configured...>. I guess that is pretty low risk. The alternative would be
to use a different prefix, such as putXXX() or configXXX(). That should be
backward compatible, although it may expose methods to the buildfile as
nested elements which were not intended.

So, what do you think? It makes some tasks easier to write if the element
is configured before it is added to the task. Certainly this was the case
for manifests. If you think this is worthwhile, what about the naming of
the methods eligible for this?

Let me know your thoughts?

Conor

Re: Introspection Change comments

[Peter Donald <do...@apache.org>]

I have NOOOOOOOOOOOOOOOOO idea how you jumped from naming convetion (ie 
setFoo() vs createFoo() addFoo()) to generic tasks ...

On Fri,  3 Aug 2001 23:30, Matthew Inger wrote:
> Peter,
>
> While i agree, ant should not be forced to implement everything
> make does, it would be nice to have the ability to have a generic
> "compile" task.  The reason for this is for apis like rmi (though I
> think there's an rmic task), idl, and jaxb, which do preprocessing of
> files, and then generate java code.  It would avoid having to write
> seperate tasks for each one as they come a long, making it easier
> to support new preprocessor type apis...
>
> just my $.02
>
> Peter Donald wrote:
> >On Fri,  3 Aug 2001 15:26, Stefan Bodewig wrote:
> >>On Thu, 2 Aug 2001, Peter Donald <do...@apache.org> wrote:
> >>>>We should talk about that in the
> >>>>context of Ant2, for now it would give us a major backwards
> >>>>compatibilty problem.
> >>>
> >>>I can not see that - where do you see the compatability problem?
> >>
> >>We already have built-in tasks that have attributes and nested
> >>elements of the same name (see javac with classpath).  Tasks may have
> >>chosen to do different things with them (javac does, but this is
> >>silly).
> >
> >but they are still differentiable .. you said so as much below ;) Which
> > means that there is not likely to be overlap (I would say extremely
> > unlikely).
> >
> >>>Attributes are restricted to primitive types + string and File at
> >>>the moment,
> >>
> >>Not true at all - attributes are restricted to types that have a
> >>constructor using a single String argument, while lements are
> >>restricted to types that have a no-arg constructor.  I'd guess it is
> >>not that uncommon for a class to support both types of constructors.
> >
> >oh ;)
> >
> >Cheers,
> >
> >Pete
> >
> >*-----------------------------------------------------*
> >
> >| "Faced with the choice between changing one's mind, |
> >| and proving that there is no need to do so - almost |
> >| everyone gets busy on the proof."                   |
> >|              - John Kenneth Galbraith               |
> >
> >*-----------------------------------------------------*

-- 
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Introspection Change comments

[Stefan Bodewig <bo...@apache.org>]

On Mon, 6 Aug 2001, Peter Donald <do...@apache.org> wrote:

> On Mon,  6 Aug 2001 15:28, Stefan Bodewig wrote:
>
>> Maybe you are advocation Path[] as the argument for setters of
>> nested elements?
> 
> I think so ;)

OK, I could live with that (in Ant2 when everybody would have to
rewrite custom tasks anyway).  We would lose the ability to leave the
Object creation to the task (the createXYZ case), though.

Stefan

Re: Introspection Change comments

[Peter Donald <do...@apache.org>]

On Mon,  6 Aug 2001 15:28, Stefan Bodewig wrote:
> On Fri, 3 Aug 2001, Peter Donald <do...@apache.org> wrote:
> > On Fri,  3 Aug 2001 15:26, Stefan Bodewig wrote:
> >> We already have built-in tasks that have attributes and nested
> >> elements of the same name (see javac with classpath).  Tasks may
> >> have chosen to do different things with them (javac does, but this
> >> is silly).
> >
> > but they are still differentiable .. you said so as much below ;)
>
> I did?

I could be wrong but thats what it sounded like to me ;)

> If the method for nested <classpath> elements in <javac> becomes
> setClasspath(Path), how can it be distinguished from the attribute
> setter?

parameter type.

> Maybe you are advocation Path[] as the argument for setters of nested
> elements?

I think so ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Introspection Change comments

[Stefan Bodewig <bo...@apache.org>]

On Fri, 3 Aug 2001, Peter Donald <do...@apache.org> wrote:

> On Fri,  3 Aug 2001 15:26, Stefan Bodewig wrote:
>>
>> We already have built-in tasks that have attributes and nested
>> elements of the same name (see javac with classpath).  Tasks may
>> have chosen to do different things with them (javac does, but this
>> is silly).
> 
> but they are still differentiable .. you said so as much below ;)

I did?

If the method for nested <classpath> elements in <javac> becomes
setClasspath(Path), how can it be distinguished from the attribute
setter?

Maybe you are advocation Path[] as the argument for setters of nested
elements?

Stefan

Re: Introspection Change comments

[Matthew Inger <ma...@sedonacorp.com>]

Peter,

While i agree, ant should not be forced to implement everything
make does, it would be nice to have the ability to have a generic
"compile" task.  The reason for this is for apis like rmi (though I
think there's an rmic task), idl, and jaxb, which do preprocessing of
files, and then generate java code.  It would avoid having to write
seperate tasks for each one as they come a long, making it easier
to support new preprocessor type apis...

just my $.02


Peter Donald wrote:

>On Fri,  3 Aug 2001 15:26, Stefan Bodewig wrote:
>
>>On Thu, 2 Aug 2001, Peter Donald <do...@apache.org> wrote:
>>
>>>>We should talk about that in the
>>>>context of Ant2, for now it would give us a major backwards
>>>>compatibilty problem.
>>>>
>>>I can not see that - where do you see the compatability problem?
>>>
>>We already have built-in tasks that have attributes and nested
>>elements of the same name (see javac with classpath).  Tasks may have
>>chosen to do different things with them (javac does, but this is
>>silly).
>>
>
>but they are still differentiable .. you said so as much below ;) Which means 
>that there is not likely to be overlap (I would say extremely unlikely). 
>
>>>Attributes are restricted to primitive types + string and File at
>>>the moment,
>>>
>>Not true at all - attributes are restricted to types that have a
>>constructor using a single String argument, while lements are
>>restricted to types that have a no-arg constructor.  I'd guess it is
>>not that uncommon for a class to support both types of constructors.
>>
>
>oh ;)
>
>Cheers,
>
>Pete
>
>*-----------------------------------------------------*
>| "Faced with the choice between changing one's mind, |
>| and proving that there is no need to do so - almost |
>| everyone gets busy on the proof."                   |
>|              - John Kenneth Galbraith               |
>*-----------------------------------------------------*
>


-- 
Matt Inger (matt.inger@sedonacorp.com)
Sedona Corporation
455 S. Gulph Road, Suite 300
King of Prussia, PA 19406
(484) 679-2213
"Self-respect - the secure feeling that no one,
 as yet, is suspicious." -H.L. Mencken 

Re: Introspection Change comments

[Peter Donald <do...@apache.org>]

On Fri,  3 Aug 2001 15:26, Stefan Bodewig wrote:
> On Thu, 2 Aug 2001, Peter Donald <do...@apache.org> wrote:
> >> We should talk about that in the
> >> context of Ant2, for now it would give us a major backwards
> >> compatibilty problem.
> >
> > I can not see that - where do you see the compatability problem?
>
> We already have built-in tasks that have attributes and nested
> elements of the same name (see javac with classpath).  Tasks may have
> chosen to do different things with them (javac does, but this is
> silly).

but they are still differentiable .. you said so as much below ;) Which means 
that there is not likely to be overlap (I would say extremely unlikely). 

> > Attributes are restricted to primitive types + string and File at
> > the moment,
>
> Not true at all - attributes are restricted to types that have a
> constructor using a single String argument, while lements are
> restricted to types that have a no-arg constructor.  I'd guess it is
> not that uncommon for a class to support both types of constructors.

oh ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Introspection Change comments

[Stefan Bodewig <bo...@apache.org>]

On Thu, 2 Aug 2001, Peter Donald <do...@apache.org> wrote:

>> We should talk about that in the
>> context of Ant2, for now it would give us a major backwards
>> compatibilty problem.
> 
> I can not see that - where do you see the compatability problem?

We already have built-in tasks that have attributes and nested
elements of the same name (see javac with classpath).  Tasks may have
chosen to do different things with them (javac does, but this is
silly).

> Attributes are restricted to primitive types + string and File at
> the moment,

Not true at all - attributes are restricted to types that have a
constructor using a single String argument, while lements are
restricted to types that have a no-arg constructor.  I'd guess it is
not that uncommon for a class to support both types of constructors.

Stefan

Re: Introspection Change comments

[Peter Donald <do...@apache.org>]

On Wed,  1 Aug 2001 16:29, Stefan Bodewig wrote:
> On Wed, 1 Aug 2001, Peter Donald <do...@apache.org> wrote:
> > So if you were going to make this change I would like to see the
> > Introspector to use either
> >
> > void setMyVar( final MyType myVar );
> >
> > or
> >
> > void setMyVar( final MyType[] myVar );
> >
> > This would make Ant tasks more bean compliant and munge better with
> > the way most people write code.
>
> But at the same time blur the difference between attributes and
> elements - this may be good or not.  

oh well it was worth a try ;)

> We should talk about that in the
> context of Ant2, for now it would give us a major backwards
> compatibilty problem.

I can not see that - where do you see the compatability problem? Attributes 
are restricted to primitive types + string and File at the moment, elements 
can never be string or File. Thus you will always be able to determine which 
are attributes and which are not ...

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Introspection Change comments

[Stefan Bodewig <bo...@apache.org>]

On Wed, 1 Aug 2001, Peter Donald <do...@apache.org> wrote:

> So if you were going to make this change I would like to see the
> Introspector to use either
> 
> void setMyVar( final MyType myVar );
> 
> or
> 
> void setMyVar( final MyType[] myVar );
> 
> This would make Ant tasks more bean compliant and munge better with
> the way most people write code.

But at the same time blur the difference between attributes and
elements - this may be good or not.  We should talk about that in the
context of Ant2, for now it would give us a major backwards
compatibilty problem.

Stefan

Re: Introspection Change comments

[Peter Donald <do...@apache.org>]

On Wed,  1 Aug 2001 01:19, Conor MacNeill wrote:
> I would like to get some feedback on a change I am considering. With the
> current Introspection nested element support, the task's method
> corresponding to the nested element is called before the nested element is
> configured. I would like to add a mechanism to support the calling of this
> method after the element is configured. 

+1000 ;)

> So, what do you think? It makes some tasks easier to write if the element
> is configured before it is added to the task. Certainly this was the case
> for manifests. If you think this is worthwhile, what about the naming of
> the methods eligible for this?
>
> Let me know your thoughts?

If you recall ages ago the idea of using stright Bean properties (or a subset 
of) was floated (I think by Costin in about Dec?). So if you were going to 
make this change I would like to see the Introspector to use either

void setMyVar( final MyType myVar );

or

void setMyVar( final MyType[] myVar );

This would make Ant tasks more bean compliant and munge better with the way 
most people write code. Like/Dislike ?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Re: Introspection Change comments

[Stefan Bodewig <bo...@apache.org>]

On Wed, 1 Aug 2001, Conor MacNeill <co...@cortexebusiness.com.au>
wrote:

> I have implemented this (the diff is attached), by checking for a
> method addConfiguredXXX, rather than simply addXXX.

+1

> Now, my main concern is with the use of addConfigured. It is
> potentially a compatibility issue if some custom task has a nested
> element <configured...>.

You'd run the same risk for each and every naming convention you could
come up with.  Add a warning to WHATSNEW and that's it.

> So, what do you think? It makes some tasks easier to write if the
> element is configured before it is added to the task.

It certainly does, the current system has been there as addX and
createX have been supposed to be as close as possible, I can't
remember why ...

Stefan