Return-Path: 
 <ant-dev-return-27501-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 30808 invoked from network); 8 Mar 2002 19:53:03 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 8 Mar 2002 19:53:03 -0000
Received: (qmail 4198 invoked by uid 97); 8 Mar 2002 19:53:03 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 4167 invoked by uid 97); 8 Mar 2002 19:53:03 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 4156 invoked from network); 8 Mar 2002 19:53:02 -0000
Message-ID: <E34FCACEE99E304599501FDF98450AA6D5E90F@LGCHEXCH004.ad.lgc.com>
From: Dominique Devienne <DDevienne@lgc.com>
To: "'Ant Developers List'" <ant-dev@jakarta.apache.org>
Subject: RE: [PROPOSE] task parameters that are only supplied when a prope
	rty is defined
Date: Fri, 8 Mar 2002 13:52:57 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

You're welcome. Trouble is, I'm brand new to ant-dev, I'm not a committer,
and none of the committers or people with influence about the direction of
ANT have said anything about this, so it does not augur well about this
proposal being ever considered...

You original problem was to avoid duplicating tasks (xml fragments really)
essentially, and there are many places where one is forced to duplicate
things. Consider two targets of mine, one that starts our application and
the other that runs the unit tests (<java> and <junit>). Both need quite of
few Java properties, but inside both targets I have to defines a bunch of
identical <sysproperty> or <jvmarg> sub-elements. The build properties can
be factored in a property file, but the Java properties to pass in to <java>
and <junit> cannot! All tasks that run a Java class should support some kind
of <propertyset> or <syspropertyset>.

Don't get me wrong, I love ANT, but it's sometime frustrating. A lot of
things that you take for granted using makefile are difficult to do in ant.
Yes, it takes a different mindset and approach, but still, like Erik says
sometimes, there's gotta be an easier way to do this and that.

--DD

 -----Original Message-----
From: 	Steve Cohen [mailto:SteveC@ignitesports.com] 
Sent:	Friday, March 08, 2002 12:17 PM
To:	Ant Developers List
Subject:	RE: [PROPOSE] task parameters that are only supplied when a
property is defined

Thank you for clearly expressing an implementation of my request.  I fully
support your recommended syntax.

-----Original Message-----
From: Dominique Devienne [mailto:DDevienne@lgc.com]
Sent: Friday, March 08, 2002 11:53 AM
To: 'Ant Developers List'
Subject: RE: [PROPOSE] task parameters that are only supplied when a
property is defined


Yes, it is more wordy, on purpose, so it follows ANT's Understandability
goal (Ant must be clearly understandible for a first time as well as a
veteran user), and the attribute names chosen for <attribute> were also
purposefully longish. I would just as well live with:

<attribute name="label" property="lbl" ignoreifnotset="true" />

Of course, I was thinking that ANT-core would take care of these <attribute>
sub-elements. --DD

 -----Original Message-----
From: 	Steve Cohen [mailto:SteveC@ignitesports.com] 
Sent:	Friday, March 08, 2002 11:36 AM
To:	Ant Developers List
Subject:	RE: [PROPOSE] task parameters that are only supplied when a
property is defined

That's a little (a lot?) more wordy, but I wouldn't mind it as long as ANT
handled it rather than each task.  I don't think we would want to rewrite
every task to handle this.  

The important thing is not to have to copy blocks of task code all over
scripts just to parameterize certain attributes.

-----Original Message-----
From: Dominique Devienne [mailto:DDevienne@lgc.com]
Sent: Friday, March 08, 2002 11:08 AM
To: 'Ant Developers List'
Subject: RE: [PROPOSE] task parameters that are only supplied when a
property is defined


Instead of this special syntax, how about being able to specify a task's
attributes through <attribute> sub-elements? The example from Steve thus
becomes:

  <stcheckout username="auser"
                     password="secret"
                     rootlocalfolder="C:\dev\buildtest\co">
    <attribute name="URL" value="${starteam-url}" />
    <attribute name="forced" value="true" />
    <attribute name="label" valuefromproperty="lbl"
ignoreattributeifpropertynotdefined="true" />
  </stcheckout>

One can use the simple name/value attributes of <attribute> to specify the
task attribute as always (using literals or properties), and one can have
more specific ways to use attribute as shown above (which works kind of like
<propertycopy>).

Of course, there are two drawbacks to this syntax:
1) What happens with the attribute is specified both as an attribute, and
through <attribute>? I'd say a build syntax error.
2) Some tasks may already have an attribute sub-element? Maybe it should be
<task-attribute> or <${taskname}-attribute>, <stcheckout-attribute> in this
case?

This, if nothing else, has the merit of being more explicit that $${lbl} or
$?{lbl} or whatever. Just my 2c. --DD

 -----Original Message-----
From: 	Steve Cohen [mailto:SteveC@ignitesports.com] 
Sent:	Friday, March 08, 2002 10:53 AM
To:	ant-dev@jakarta.apache.org
Subject:	[PROPOSE] task parameters that are only supplied when a
property is defined

I previously sent this idea in a message whose title may have hidden its
importance, but this is an idea I'd really like to see and I'd like the
developers to comment on it.

What if there were a convenient syntax within ant for specifying task
attributes based on properties 

such that

if the property were not set 
	the task code would never see the attribute?

In other words, for example, look at this call:
  <stcheckout URL="STARTEAM:49201/Aproject/AView"
     username="auser"
     password="secret"
     rootlocalfolder="C:\dev\buildtest\co"
     forced="true" 
     label = "${lbl}"  
  />

If the lbl property is defined, the task will get its value as the label
attribute.  But if the lbl property is not defined, the task will get the
text "${lbl}" and most likely fail.

I am proposing a new syntax that would allow a property to be specified with
a different meaning.  Let's say this syntax is two dollar signs instead of
one ($${property}).  (This may not be the optimal symbol for the ant parser,
but that is a detail - I am not wedded to any symbol).

Using this syntax, the above example becomes:

  <stcheckout URL="STARTEAM:49201/Aproject/AView"
     username="auser"
     password="secret"
     rootlocalfolder="C:\dev\buildtest\co"
     forced="true" 
     label = "$${lbl}"  
  />

My proposal is that this syntax be interpreted this way:

If the property lbl is defined, treat $${lbl} exactly as ${lbl} but
if the property lbl is not defined, do not even pass the label attribute to
the task.

It seems to me that this would allow for much more flexible scripts,
especially when more than one parameter of a task is optional and there are
different use cases for the task.  In the above example, to get the variable
functionality desired, I must include two blocks in my script, one with the
label attribute defined and the other without it, and put it some
conditionals to direct the processing to the right place.  This can get
clumsy, especially if there are several attributes to parameterize; the
combinatorial possiblilities could be large, making for scripts that are
harder to understand or maintain.





--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>