Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-Id: <3.0.6.32.20010524134936.00ae8100@mail.alphalink.com.au>
Date: Thu, 24 May 2001 13:49:36 +1000
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: RE: [DISC] details of task library concept
Cc: <ant-dev@jakarta.apache.org>
In-Reply-To: <005801c0e400$e76a7320$697b883e@viquity.com>
References: <3.0.6.32.20010524125016.00f09530@mail.alphalink.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 04:23 AM 5/24/01 +0100, Jose Alberto Fernandez wrote:
>Well, since this is the first time I heard of having a TOM and how it is
>suppose to work (your vision) it will all ddepend on the details.

Look through the archives - it has been called among other things
* TOM (Task Object Model)
* Task DOM
* TaskData
* TaskProxy
* Configuration

all the proposals except frANTic also include it.

>> >Others need to manufacture or fill-in parameter types to
>> pass to other
>> >classes and those parmameters have different custom types (not just
>> >strings).
>>
>> That is nothing that can't be done with proposed solution.
>>
>
>The question os how easy will all that be. Are going to have typed
>attributes as we have today or are you thinking on moving away from that due
>to TOM?
>
>If we keep them, which I hope we will since I like the use of strong typing
>as oppose to loose interfaces, can I pass my file attribute to another task
>requiring files, or do I need to go through strings due to this TOM.

More than likely you will have to go through strings (or strings
referencing properties). Again to keep everything maintainable and
low-coupling.

>A pattern I use alot, is for out tasks to extend the <java> task. With that,
>we only need to add attributes reflecting the different options and you can
>quickly have a task that interfaces a command-line tool.
>
>Will I be able to do that or will I need to write only delegation patterns.
>The advantage of extending is that you get for free all the features of
><java>: fork, -Doptions, etc, etc. Which they are needed in many cases or
>for certain runs.

Me too - not sure how to handle this specifically. In a sense having all
the extra features for "free" is a bad thing as it can complicate derived
tasks. We may have to define some inheritance friendly abstract tasks in
framework to get around some of these issues or we may not.

>> 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 ;)

>> Thats not something I would ever wish on anybody. Having just
>> gone through
>> .so hell and having much expereince with .dll and .jar hell I
>> would pity
>> anyone who has to do this for anything great size.
>>
>
>So how are you going to resolve having the same task name being used by two
>different .tsk files? A classloader is not going to help you with that.

namespaces.

>Yet another feature that does not exists, with a syntax different from XML.
>What does having this in the manifest entry gives you that having it in the
>XML descriptor does not.

It is closer to standard Java syntax and it can be sucked in without having
to read descriptor which means certain operations are easier to perform
(getting all resources with same name etc) before get to descriptor. We can
also build it into classLoader to get around the various issues that arise
when doing things in a SecurityManager.

>BTW, ejbs do not use Class-Path for dependencies they use XML. so I am not
>comming up with something never heard before. We do I need to maintain two
>files when I can do with just one.

They don't - didn't know that. So ejb jars ignore Class-Path manifest entry
and get all classpath data from their descriptors? Seems to go against most
of the other APIs - kinda odd choice for them I guess.

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