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 Thu, 24 May 2001 07:15:50 GMT
At 05:09 AM 5/24/01 +0100, Jose Alberto Fernandez wrote:
>> More than likely you will have to go through strings (or strings
>> referencing properties). Again to keep everything maintainable and
>> low-coupling.
>>
>
>And error prone. Maybe I am from an old school but Ithink strong typing is
>good.
>All these do-it-with-strings remins me of untyped languages which they may
>be low copling but they can hide simple bugs preatty good.

I prefer it but the problem is we will not be able to support it. If you
look at the evolution of certain classes the types while remaining
relatively the same from xml point of view often change implementation wise
and with the addition of BeanInfo like constructs this will become even
more problematic for  people who want to directly access task attributes.

>> >> deployment != loading
>> >>
>> >still, why should I be mocking around with P4 is I use CVS.
>> Why should I be
>> >locking at weblogic if I use websphere, etc, etc.
>>
>> So you would prefer that all tasks be explicitly imported? I
>> wouldn't mind
>> that (actually I would like it) but I thought most other
>> people didn't like
>> that ;)
>>
>
>Not all tasks, but all libraries. In particular, if you think that not all
>installations will have all libraries. Like with the "import" statement in
>Java, explicitly mentioning dependencies is best.

I agree - wanna convince everyone else ? ;)

>> namespaces.
>
>How are you going to assign the name spaces? I hope the writer of the
>buildfile has a say on what names to use.

Haven't been discussed enough but my assumption is something like.

Namepsace+default prefix defined by library writer however library user can
overide prefix (but not namespace).

>EJB jars specify dependencies in the XML descriptor. As Sun puts it,
>Class-Path is not really for high level dependency specification but low
>level JVM security. When you have a container be EJB, Servlet, etc. The
>point is that Class-Path is to close to a particular layout of the file
>system to be any good for an open framework and multiple implementations.

not really - it 

>So, it is not that they ignore it, it is enforced by the JVM, in reality it
>is just not used. Look at TOMCAT and the way war files are structured. They
>do not use Class-Path at the TOMCAT level.

actually they do ;) (Or at least some of the jars in my wars do). The wars
themselves may not use Class-Path: etc but that is because they are a
deployment archive rather than a component archive (like the jars in lib
directory). Our task libraries are component archives and should probably
use the same mechanism.

>I think the same applies to ANT. If it is installed in a multiuser system
>(yes, those still exist) 

almost all my installations of ant (except those for apache projects) are
multiuser ;)

>one does not want to have the same set of libraries
>for every project of every one, without any alternative but each person
>installing and maintining its own copy of ANT.

right - though I am not sure what your point is here. Either method will
work in this case whether jars are sucked from ~/antlib/,
/usr/local/ant/lib or ./antlib/ this should all work fine.


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