Return-Path: <donaldp@apache.org>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 75648 invoked from network); 11 Dec 2000 13:48:35 -0000
Received: from mail.alphalink.com.au (203.24.205.7)
  by locus.apache.org with SMTP; 11 Dec 2000 13:48:35 -0000
Received: from donalgar (d107-ps0-mel.alphalink.com.au [202.161.104.107])
	by mail.alphalink.com.au (8.9.3/8.9.3) with SMTP id AAA23837;
	Tue, 12 Dec 2000 00:48:33 +1100
Message-Id: <3.0.6.32.20001212004536.00993550@latcs2.cs.latrobe.edu.au>
X-Sender: pjdonald@latcs2.cs.latrobe.edu.au
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 12 Dec 2000 00:45:36 +1100
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: Re: [PROPOSAL] Optional Tasks
Cc: ant-dev@jakarta.apache.org
In-Reply-To: <Pine.LNX.4.21.0012120153080.30584-100000@marni.otago.ac.nz
 >
References: <B659DE25.B920%duncan@x180.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

At 02:08  12/12/00 +1300, Mariusz Nowostawski wrote:
>On Mon, 11 Dec 2000, James Duncan Davidson wrote:
>> IOW, you probably want something like
>> 
>> <ejb impl="com.foo.ant.ejb.EjbClass" name1="val1" name2="val2">
>>   ...
>> </ejb>
>> 
>> Where the ejb task is a shell that looks up the impl specified and then
sets
>> things on that. I think that would be the cleanest way to get to where you
>> want to go.

I would probably oppose that because in some cases it doesn't make sense.
For example if I wanted to use jikes to build ant rather than suns javac it
would involve changing the build file ... which would break it for everyone
else who doesn't use jikes. For some tasks it may make sense - thou I can't
think of one of the top of my head. 

I much prefer to see <foo-ejb .../> and <baah-ejb .... /> because it is
simple and it matches use case. It is conceptually much easier for users of
ant. It is unlikely that tasks that do different things (despite taking the
same parameters) are going to want to be interchanged. For tasks that do
identical things (but through different methods) then it makes sense for
them to have the same name (ie javac).

>I want to go there as well. But, I would rather see it like this: the
>abstract class plug in as task, with all the common attributes different
>implementations share, and then a particular implementation plug in its
>additional funcionality. 
>
><ejb name1="value1" name2="value2">
>   <weblogic name3="value3" />
></ejb>

The problem is that you end up with a plethora of tasks that on first
glance look compatable but in fact aren't. It would make build files
context sensitive. ie does the ejb task refer to weblogic one, the jboss
one, the openejb one etc. What happens if we include both weblogic and
openejb sub-elements ? etc

>Here I would go for:
>
><javac ... /> (default, i.e. modern, if not available, classic)
>
><javac .... > (all generic parameters)
>   <jikes pedantic="on" >  (all jikes specific options)
></javac>
>
><javac ...>
>  <mjavac > (all metamata specific stuff here)
></javac>
>
>Who has proposed that before? I am sure I saw it being proposed, but it
>never made its way to codebase, don't remember why?

Mainly because it does not solve the problem ... just moves it to a new
place. Instead of defining magic properties (ie
build.compiler.pedantic=true) you define magic sub-elements. However it is
non-trivial to validate subelements. ie Is subelement X a typo or does it
refer to a particular implementation?

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