ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [DISC] details of task library concept
Date Wed, 23 May 2001 04:22:18 GMT
At 12:12 AM 5/23/01 +0100, Jose Alberto Fernandez wrote:
>If someone does not want its task to be subclassed then it should declare it
>final. Otherwise, there is no way to stoping anyone from subclassing any
>class of any sort in the Java programming language. This is a feature of the
>language. It is best to embrase it than to try to build a wal around it that
>it can be jumped anyway.

umm? There is also no way of stopiing someone writing out

doX( 1 );
doX( 2 );
doX( 3 );
...
doX( 1000 );

instead of 

for( int i = 0; i < 100; i++ ) 
{
  doX( i );
}

However they generally don't do that. Make something painful to do and it
won't be done.

>>I would
>> consider the
>> current behavior of <taskdef> questionable--if you mean to
>> share classes, you
>> should declare it, and ideally the author of the original
>> class should have
>> permitted it. Wasn't there some proposal for referencing
>> classloader IDs to
>> explicitly permit reuse of classes? Or you could explicitly
>> list the name of
>> the other task library as a code dependency.
>>
>
>This is not the Java way of doing things. And I definetly thing the worst
>thing we can do is trying to fight against the features of the language.

Class-Path: manifest entry is the "java-way" and yet it does just that.

>So, how do I refer in the jar Class-Path to a jars and derectories relative
>to my build directory? 

you don't

>Or are you telling me that <tasks> in libraries
>cannot use anything that resides on my projects directory structure?

yup.

>This is exactly why I want to be able to pass property information to the
>task library.
>So that they can take local info from the build into account. I think it is
>a good question to ask whether to allow passing/inheriting any property, or
>whether we can come up with a particular subset that makes sense. My example
>is for being able to pass a classpath for project specific stuff, but one
>could say we could have a <classpath> parameter added to <tasklib> to
>acheive the same. Are there other interesting properties.

task/data/other libraries should not be "configured" in this way. I expect
javac to behave the same regardless of whether where I run it.

>My point on the description issue is that I do not think ANT should force
>people to use some particular documentation mechanism or standard. Not
>JavaHelp, nor HTML nor anything else. That should be upto the task writer to
>decide how it should be provided.

why not. Javadocs works well, is relatively universal and I think java is
better off with it. Much like ant will be better off with antdoc.



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               |
*-----------------------------------------------------*


Mime
View raw message