DO NOT REPLY [Bug 24592] New: - support @input for the exec task

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24592

support @input for the exec task

   Summary: support @input for the exec task
   Product: Ant
   Version: 1.5.2
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The exec task should support the input redirection.
In other words, I'd like to redirect stdin of the new process
to a file that I specify through the exec task.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24596] New: - Problem using ant

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24596

Problem using ant

   Summary: Problem using ant
   Product: Ant
   Version: 1.6Beta
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


# ant
Invalid implementation version between Ant core and Ant optional tasks.
 core: 1.6
 optional: 1.5.1

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24596] - Problem using ant

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24596

Problem using ant

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 07:57 ---
Hi Pierre,
the names of ant jar files have changed between 1.5 and 1.6.
In ant1.6beta2 and later, the former optional.jar is split into
ant-nodeps.jar, ant-oro.jar, ant-weblogic.jar, ...
You need to delete $ANT_HOME/lib/optional.jar which is probably left-over from
ant 1.5 and you will be fine. I stumbled on the same problem too.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24592] - support @input for the exec task

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24592

support @input for the exec task

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |1.6



--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 08:01 ---
ant 1.6 has these 2 attributes in the exec task.

input   : A file from which the executed command's standard input is taken. This
attribute is mutually exclusive with the inputstring attribute. 
inputstring :   A string which serves as the input stream for the executed
command. This attribute is mutually exclusive with the input attribute. 

See this link : http://ant.apache.org/manual-1.6beta/CoreTasks/exec.html

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: Namespace support in ant 1.6

[Antoine Levy-Lambert]

>Von: peter reilly [mailto:[EMAIL PROTECTED]
>Gesendet: Montag, 10. November 2003 19:21
>An: Ant Developers List
>Betreff: Namespace support in ant 1.6


>Hi,
>I would like to get some movement on the outstanding issues
>of ant 1.6.

+1

>One of the outstanding issues is what namespace to use
>for nested elements of tasks. (Discovered by introspection
>rules).

>The choices are:
>  a) Use the default ant namespace, this is the current rule.
>  b) Use the namespace of the enclosing task or type.
>  c) Allow either - let the build script author choose.

>Using the if task from ant-contrib and assuming an
>project tag of as an example:

Do  and  in your example come from ant core ? I guess so, but
 comes from ant-contrib, no ?
I would have expected your examples a and  b to be like this :

Choice a)


   
  
  
   
   
  both conditions are true
   



Choice b)


   
  
  
   
   
  both conditions are true
   



Cheers,

Antoine


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: Namespace support in ant 1.6

[peter reilly]

On Tuesday 11 November 2003 08:57, Antoine Levy-Lambert wrote:
> >Von: peter reilly [mailto:[EMAIL PROTECTED]
> >Gesendet: Montag, 10. November 2003 19:21
> >An: Ant Developers List
> >Betreff: Namespace support in ant 1.6
> >
> >
> >Hi,
> >I would like to get some movement on the outstanding issues
> >of ant 1.6.
>
> +1
>
> >One of the outstanding issues is what namespace to use
> >for nested elements of tasks. (Discovered by introspection
> >rules).
> >
> >The choices are:
> >  a) Use the default ant namespace, this is the current rule.
> >  b) Use the namespace of the enclosing task or type.
> >  c) Allow either - let the build script author choose.
> >
> >Using the if task from ant-contrib and assuming an
> >project tag of  >as an example:
>
> Do  and  in your example come from ant core ? I guess so, but
>  comes from ant-contrib, no ?

The  and  come from 
org.apache.tools.ant.taskdefs.condition.ConditionBase
which is extended by
net.sf.antcontrib.logic.IfTask,
thus, as seen by introspection, they come
from the IfTask class, hence the "antcontrib" prefix.

Of course, in ant1.7 when roles get sorted out,
 and  will be taskdef'ed elements as well as hardcoded
methods of ConditionBase.

Peter

> I would have expected your examples a and  b to be like this :
>
> Choice a)
>
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
>
>
> Choice b)
>
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
>
>
> Cheers,
>
> Antoine
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

AW: AW: Namespace support in ant 1.6

[Antoine Lévy-Lambert]

Which of the 3 solutions you propose is the best in terms of preparing the
transition to 1.7 and roles ?

And the easiest to understand for users ?

How can we formulate the rules in terms of when an xml prefix such as
antcontrib: is required ? When is it optional ?

On the details side, I did not understand why you did not prefix with
antcontrib the  tag in your original example a ?

And in the example b, I did not understand either why you prefixed with
antcontrib: the  tag.

Also, do you mean that everything in this regard would be more clear as soon
as we have roles ?

Cheers,

Antoine

-Ursprüngliche Nachricht-
Von: peter reilly [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 11. November 2003 10:15
An: Ant Developers List
Betreff: Re: AW: Namespace support in ant 1.6


On Tuesday 11 November 2003 08:57, Antoine Levy-Lambert wrote:
> >Von: peter reilly [mailto:[EMAIL PROTECTED]
> >Gesendet: Montag, 10. November 2003 19:21
> >An: Ant Developers List
> >Betreff: Namespace support in ant 1.6
> >
> >
> >Hi,
> >I would like to get some movement on the outstanding issues
> >of ant 1.6.
>
> +1
>
> >One of the outstanding issues is what namespace to use
> >for nested elements of tasks. (Discovered by introspection
> >rules).
> >
> >The choices are:
> >  a) Use the default ant namespace, this is the current rule.
> >  b) Use the namespace of the enclosing task or type.
> >  c) Allow either - let the build script author choose.
> >
> >Using the if task from ant-contrib and assuming an
> >project tag of  >as an example:
>
> Do  and  in your example come from ant core ? I guess so,
but
>  comes from ant-contrib, no ?

The  and  come from
org.apache.tools.ant.taskdefs.condition.ConditionBase
which is extended by
net.sf.antcontrib.logic.IfTask,
thus, as seen by introspection, they come
from the IfTask class, hence the "antcontrib" prefix.

Of course, in ant1.7 when roles get sorted out,
 and  will be taskdef'ed elements as well as hardcoded
methods of ConditionBase.

Peter

> I would have expected your examples a and  b to be like this :
>
> Choice a)
>
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
>
>
> Choice b)
>
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
>
>
> Cheers,
>
> Antoine
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Namespace support in ant 1.6

[Stefan Bodewig]

On Mon, 10 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

> I would like to get some movement on the outstanding issues
> if ant 1.6.

This is appreciated a lot by me.  Thanks for going ahead, I appologize
for letting the ball drop - I've been too busy with real-life and
real-life work.

> One of the outstanding issues is what namespace to use
> for nested elements of tasks.

Yep, the other one AFAICT is macrodef and I'll try to get the ball
rolling for this in a separate thread (unless you beat me).

> (Discovered by introspection rules).
> 
> The choices are:
>   a) Use the default ant namespace, this is the current rule.
>   b) Use the namespace of the enclosing task or type.
>   c) Allow either - let the build script author choose.

My take is that we should go with maximum XML tool support here.
Assume an Ant library ships with an XML Schema definition of the
tasks/types it contains - to make this work, nested elements that
belong to an antlib will have to be prefixed by the namespace of the
antlib.

The default namespace belongs to whatever is the default namespace of
the document (or the element if you locally define a default
namespace).  So in addition to (b) from your choices (which gets my
vote), default namespace doesn't implicitly mean Ant core either -
only if Ant core is associated with the local default namespace.

> Choice b)
> 
> 
>
>   
>   
>
>
>   both conditions are true
>
> 

could be simplified via


   
  
  
   
   
  both conditions are true
   


Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ant-type attribute (was Re: antlibs/namespaces)

[Stefan Bodewig]

On Thu, 6 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> On Thursday 06 November 2003 10:02, Stefan Bodewig wrote:
>> On Wed, 5 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

>> > well there is an undocumented attribute ant-type
>>
>> we really should document it.
> Yes...
> 
> Note that when this feature was first disussed it was pointed out
> that ant-type does not work for Type create() methods
> - like  in javac.

True.

> It was assumed that one could add new methods -
> add(Type..)  to get around this problem, and make
> add have a lower priorirty than
> create().

I never assumed that 8-)

You can't replace all of the current createXYZ methods as some of them
would return things that Ant's core wasn't able to create at all
(inner classes for example) - or do special things like the Path
creating methods that join all subelements.

I'd prefer to document the limitation and probably live with
explicitly noting that ant-type won't work for the nested elements
that are affected.

We'll also have to explain why


  


won't work as expected (because  unlike  doesn't know
anything about ZipFileSet and ZipFileSet is no drop-in replacement for
FileSet).

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: antlibs/namespaces

[Stefan Bodewig]

On Thu, 6 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

> One oddity is that the implementation of elements is now
> exposed.

Yes, I see you've "fixed" the specific  case by now, but it
remains a little strange.  But then again it doesn't, as the version
which uses addTask is open for polymorphism while the addSequential is
not - as far as Ant's intorspection rules are concerned.

We'll have to explain which elements are open for polymorphism and
which are not in the future a lot.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AW: AW: Namespace support in ant 1.6

[peter reilly]

On Tuesday 11 November 2003 09:33, Antoine Lévy-Lambert wrote:
> Which of the 3 solutions you propose is the best in terms of preparing the
> transition to 1.7 and roles ?
The third.
>
> And the easiest to understand for users ?
The first. (I think). The second for people that want
to write xml syntax grammers for their tasks/types.
The third will allow build files to be written without
worrying too much about the issues. (like we do at
the moment for the case of elements and attributes)

> How can we formulate the rules in terms of when an xml prefix such as
> antcontrib: is required ? When is it optional ?

Not easy, the prefix depends on the implementation of the element- whether
it is implemented by addName() or by a typedef.

>
> On the details side, I did not understand why you did not prefix with
> antcontrib the  tag in your original example a ?

The  is not prefixed since it is implemented by an addThen()
method. Note that the antelope implementation of  implemented 
as a task, and so in that case it would be  in all cases.

> And in the example b, I did not understand either why you prefixed with
> antcontrib: the  tag.

The b) rule is that nested elements inherit the namespace uri of their
parent unless the nested element is a typedef'ed element.

>
> Also, do you mean that everything in this regard would be more clear as
> soon as we have roles ?

I am not sure.
Peter

>
> Cheers,
>
> Antoine
>
> -Ursprüngliche Nachricht-
> Von: peter reilly [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 11. November 2003 10:15
> An: Ant Developers List
> Betreff: Re: AW: Namespace support in ant 1.6
>
> On Tuesday 11 November 2003 08:57, Antoine Levy-Lambert wrote:
> > >Von: peter reilly [mailto:[EMAIL PROTECTED]
> > >Gesendet: Montag, 10. November 2003 19:21
> > >An: Ant Developers List
> > >Betreff: Namespace support in ant 1.6
> > >
> > >
> > >Hi,
> > >I would like to get some movement on the outstanding issues
> > >of ant 1.6.
> >
> > +1
> >
> > >One of the outstanding issues is what namespace to use
> > >for nested elements of tasks. (Discovered by introspection
> > >rules).
> > >
> > >The choices are:
> > >  a) Use the default ant namespace, this is the current rule.
> > >  b) Use the namespace of the enclosing task or type.
> > >  c) Allow either - let the build script author choose.
> > >
> > >Using the if task from ant-contrib and assuming an
> > >project tag of  > >as an example:
> >
> > Do  and  in your example come from ant core ? I guess so,
>
> but
>
> >  comes from ant-contrib, no ?
>
> The  and  come from
> org.apache.tools.ant.taskdefs.condition.ConditionBase
> which is extended by
> net.sf.antcontrib.logic.IfTask,
> thus, as seen by introspection, they come
> from the IfTask class, hence the "antcontrib" prefix.
>
> Of course, in ant1.7 when roles get sorted out,
>  and  will be taskdef'ed elements as well as hardcoded
> methods of ConditionBase.
>
> Peter
>
> > I would have expected your examples a and  b to be like this :
> >
> > Choice a)
> >
> > 
> >
> >   
> >   
> >
> >
> >   both conditions are true
> >
> > 
> >
> >
> > Choice b)
> >
> > 
> >
> >   
> >   
> >
> >
> >   both conditions are true
> >
> > 
> >
> >
> > Cheers,
> >
> > Antoine
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Namespace support in ant 1.6

[Jim Fuller]

I'll just wade in here with my 2p.

I agree that with the number of Ant based variants...maven, jelly etc... . and 
people embedding Ant inside their own applications that their is a need to 
avoid collision using namespacein addition this will also allow intermixing 
of Ant with other xml vocabularies ( XSLT, etc.. ) that may process prior or 
after Ant processing, though in the example provided e.g. antcontrib ( or the 
proposes  stuff library its more akin to the binding a function to a 
namespace as within xslt.

a few random and possibly not applicable comments;


-

3rd party libraries that extend Ant e.g. antcontrib depends on Ant, they are 
not standalone xml vocabularies with its own processor...I see a mixing of 
using namespaces for avoiding collision versus using namespaces to 'bind' 
functionality a potential source of problems. 

What are the benefits ? XSLT has already gone through many of these type of 
issues...and my exp with the EXSLT effort suggests that you might want to come 
up with some clear use cases...otherwise users will just see namespaces as 
additional effort for little return.
 
-

I would suggest at least inheriting part of the URI to promote sanity with 3rd 
party libraries;

note I add a mythical top level root element, as there might be a need of 
something like this as a general container element for ant...but this applies 
to  as well.




 
this allows ant.apache.org to control the valid 3rd party namespaces, though of 
course the Ant developer / hacker would be allowed to determine completely 
seperate variants as proposed...as follows;





but once again this to me smacks of using namespace to bind functionality

-

as with all xml namespaces there is the issue of the default namespaces not 
applying to attribute names. That is
unprefixed attributes have no explicit namespace, though they are assumed to be 
in the namespace of the element containing them. This means that choice A 
really is not an option; too much ambiguity with respect to attributes may 
cause problems.

to address these as clearly as possible one would prefix all elements and 
attributes;





   
  
  
   
   
  both conditions are true
   




admittedly most would argue that its alright to get away with not prefixing the 
attributes if the elements were prefixed.

as u can see adding namespaces significantly reduces the readability of the 
markup...not to mention adds the burden of typing more...which is irrevelent if 
one is using an editor. So as much as I would like to be able to manipulate 
markup that uses 3rd party libraries ( such as antcontrib ), its probably 
important to allow users to just define a standard namespace for collision 
aspects. I think that the antlib effort needs to address these issues as well.

-

I would propose, to implement a set of conventions;

- namespace aware Ant processing switch to turn on and off namespace processing

- if namespace aware processing is on to include a switch for letting ant embed 
3rd party libraries or to enable namespace processing of said 3rd party 
libraries...or use some clear uri naming schema to indicate choice

- http URI should be used for identifying different ant namespaces, it gives 
clear readable information and points to at the very least a domain ( 
ant.apache.org ) that user can put into browser, maybe even define a RDDL 
document

- if function binding is to be used with namespaces, e.g. as suggested with 
antlib, then I would suggest a bit of refactoring and just copy what XSLT does 
with binding for java function binding

- what happens when certain functionality gets folded back into Ant...having 
the ability to explicitly state namespace is a good abstraction...though not 
sure about the internals of Ant of handling this... at the least its important 
to embed version information into the namespace uri e.g. 
http:/ant.apache.org/ant/v1 or http:/ant.apache.org/ant/2003

- if you are to gain the benefits of namespaces and are looking at using XML 
Schema in the future, I would suggest some considerable modeling with xml 
schema... to ensure what is being proposed across Ant with respect to 
namespaces jigs up with what is natural within XML Schema, though I am a 
relaxng man myself

sorry about the random nature of this posting, also some of the points maybe 
ill informed or not relevent though I can see some definate parallels with what 
Ant wants to do and what XSLT has been through.

cheers, Jim Fuller
This e-mail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient please contact the sender immediately. Any 
disclosure, copying, distribution or any 

Re: antlibs/namespaces

[peter reilly]

On Tuesday 11 November 2003 10:01, Stefan Bodewig wrote:
> On Thu, 6 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > One oddity is that the implementation of elements is now
> > exposed.
>
> Yes, I see you've "fixed" the specific  case by now, but it

The reason I fixed this is that in this case the sequential is not
polymorphic. It was originally (in MacroDef) meant to be an addSequential
and not a addTask(). The problem was to get access to the UnknownElements
to allow them to modified by macroinstance.

Actully looking at it, I think that it should be implemetned by
MacroDef#createSequential.

> remains a little strange.  But then again it doesn't, as the version
> which uses addTask is open for polymorphism while the addSequential is
> not - as far as Ant's intorspection rules are concerned.
>
> We'll have to explain which elements are open for polymorphism and
> which are not in the future a lot.
Yep, that is for sure.
Peter
>
> Stefan
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs MacroDef.java

[peterreilly]

peterreilly2003/11/11 04:01:26

  Modified:src/main/org/apache/tools/ant/taskdefs MacroDef.java
  Log:
  Implement the sequential element of macrodef by a createSequential and
  not a addTask()
  
  Revision  ChangesPath
  1.12  +72 -18ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java
  
  Index: MacroDef.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- MacroDef.java 31 Oct 2003 09:51:24 -  1.11
  +++ MacroDef.java 11 Nov 2003 12:01:26 -  1.12
  @@ -64,20 +64,19 @@
   import org.apache.tools.ant.ComponentHelper;
   import org.apache.tools.ant.Project;
   import org.apache.tools.ant.ProjectHelper;
  +import org.apache.tools.ant.RuntimeConfigurable;
   import org.apache.tools.ant.Task;
   import org.apache.tools.ant.TaskContainer;
   import org.apache.tools.ant.UnknownElement;
   
  -import org.apache.tools.ant.types.EnumeratedAttribute;
  -
   /**
* Describe class MacroDef here.
*
* @author Peter Reilly
* @since Ant 1.6
*/
  -public class MacroDef extends AntlibDefinition implements TaskContainer {
  -private UnknownElement nestedTask;
  +public class MacroDef extends AntlibDefinition  {
  +private NestedSequential nestedSequential;
   private String name;
   private List   attributes = new ArrayList();
   private Mapelements = new HashMap();
  @@ -91,26 +90,81 @@
   }
   
   /**
  - * Add a nested task to ExtendType
  - * @param nestedTask  Nested task/type to extend
  + * This is the sequential nested element of the macrodef.
  + *
  + * @return a sequential element to be configured.
*/
  -public void addTask(Task nestedTask) {
  -if (this.nestedTask != null) {
  +public NestedSequential createSequential() {
  +if (this.nestedSequential != null) {
   throw new BuildException("Only one sequential allowed");
   }
  -UnknownElement ue = (UnknownElement) nestedTask;
  -if (!ue.getNamespace().equals("")
  -|| !ue.getTag().equals("sequential")) {
  -throw new BuildException("Unsupported tag " + ue.getQName());
  +this.nestedSequential = new NestedSequential();
  +return this.nestedSequential;
  +}
  +
  +/**
  + * The class corresponding to the sequential nested element.
  + * This is a simple task container.
  + */
  +public static class NestedSequential implements TaskContainer {
  +private List nested = new ArrayList();
  +
  +/**
  + * Add a task or type to the container.
  + *
  + * @param task an unknown element.
  + */
  +public void addTask(Task task) {
  +nested.add(task);
  +}
  +
  +/**
  + * @return the list of unknown elements
  + */
  +public List getNested() {
  +return nested;
  +}
  +
  +/**
  + * A compare function to compare this with another
  + * NestedSequential.
  + * It calls similar on the nested unknown elements.
  + *
  + * @param other the nested sequential to compare with.
  + * @return true if they are similar, false otherwise
  + */
  +public boolean similar(NestedSequential other) {
  +if (nested.size() != other.nested.size()) {
  +return false;
  +}
  +for (int i = 0; i < nested.size(); ++i) {
  +UnknownElement me = (UnknownElement) nested.get(i);
  +UnknownElement o = (UnknownElement) other.nested.get(i);
  +if (!me.similar(o)) {
  +return false;
  +}
  +}
  +return true;
   }
  -this.nestedTask = ue;
   }
   
   /**
  - * @return the nested task
  + * Convert the nested sequential to an unknown element
  + * @return the nested sequential as an unknown element.
*/
   public UnknownElement getNestedTask() {
  -return nestedTask;
  +UnknownElement ret = new UnknownElement("sequential");
  +ret.setTaskName("sequential");
  +ret.setNamespace("");
  +ret.setQName("sequential");
  +new RuntimeConfigurable(ret, "sequential");
  +for (int i = 0; i < nestedSequential.getNested().size(); ++i) {
  +UnknownElement e =
  +(UnknownElement) nestedSequential.getNested().get(i);
  +ret.addChild(e);
  +ret.getWrapper().addChild(e.getWrapper());
  +}
  +return ret;
   }
   
   /**
  @@ -188,8 +242,8 @@
*
*/
   public void execute() {
  -if (nestedTask == null) {
  -throw new Bui

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs MacroDef.java

[peterreilly]

peterreilly2003/11/11 04:02:09

  Modified:src/main/org/apache/tools/ant/taskdefs Tag: ANT_16_BRANCH
MacroDef.java
  Log:
  Sync with HEAD
  
  Revision  ChangesPath
  No   revision
  No   revision
  1.7.2.5   +72 -18ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java
  
  Index: MacroDef.java
  ===
  RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/MacroDef.java,v
  retrieving revision 1.7.2.4
  retrieving revision 1.7.2.5
  diff -u -r1.7.2.4 -r1.7.2.5
  --- MacroDef.java 31 Oct 2003 09:56:42 -  1.7.2.4
  +++ MacroDef.java 11 Nov 2003 12:02:09 -  1.7.2.5
  @@ -64,20 +64,19 @@
   import org.apache.tools.ant.ComponentHelper;
   import org.apache.tools.ant.Project;
   import org.apache.tools.ant.ProjectHelper;
  +import org.apache.tools.ant.RuntimeConfigurable;
   import org.apache.tools.ant.Task;
   import org.apache.tools.ant.TaskContainer;
   import org.apache.tools.ant.UnknownElement;
   
  -import org.apache.tools.ant.types.EnumeratedAttribute;
  -
   /**
* Describe class MacroDef here.
*
* @author Peter Reilly
* @since Ant 1.6
*/
  -public class MacroDef extends AntlibDefinition implements TaskContainer {
  -private UnknownElement nestedTask;
  +public class MacroDef extends AntlibDefinition  {
  +private NestedSequential nestedSequential;
   private String name;
   private List   attributes = new ArrayList();
   private Mapelements = new HashMap();
  @@ -91,26 +90,81 @@
   }
   
   /**
  - * Add a nested task to ExtendType
  - * @param nestedTask  Nested task/type to extend
  + * This is the sequential nested element of the macrodef.
  + *
  + * @return a sequential element to be configured.
*/
  -public void addTask(Task nestedTask) {
  -if (this.nestedTask != null) {
  +public NestedSequential createSequential() {
  +if (this.nestedSequential != null) {
   throw new BuildException("Only one sequential allowed");
   }
  -UnknownElement ue = (UnknownElement) nestedTask;
  -if (!ue.getNamespace().equals("")
  -|| !ue.getTag().equals("sequential")) {
  -throw new BuildException("Unsupported tag " + ue.getQName());
  +this.nestedSequential = new NestedSequential();
  +return this.nestedSequential;
  +}
  +
  +/**
  + * The class corresponding to the sequential nested element.
  + * This is a simple task container.
  + */
  +public static class NestedSequential implements TaskContainer {
  +private List nested = new ArrayList();
  +
  +/**
  + * Add a task or type to the container.
  + *
  + * @param task an unknown element.
  + */
  +public void addTask(Task task) {
  +nested.add(task);
  +}
  +
  +/**
  + * @return the list of unknown elements
  + */
  +public List getNested() {
  +return nested;
  +}
  +
  +/**
  + * A compare function to compare this with another
  + * NestedSequential.
  + * It calls similar on the nested unknown elements.
  + *
  + * @param other the nested sequential to compare with.
  + * @return true if they are similar, false otherwise
  + */
  +public boolean similar(NestedSequential other) {
  +if (nested.size() != other.nested.size()) {
  +return false;
  +}
  +for (int i = 0; i < nested.size(); ++i) {
  +UnknownElement me = (UnknownElement) nested.get(i);
  +UnknownElement o = (UnknownElement) other.nested.get(i);
  +if (!me.similar(o)) {
  +return false;
  +}
  +}
  +return true;
   }
  -this.nestedTask = ue;
   }
   
   /**
  - * @return the nested task
  + * Convert the nested sequential to an unknown element
  + * @return the nested sequential as an unknown element.
*/
   public UnknownElement getNestedTask() {
  -return nestedTask;
  +UnknownElement ret = new UnknownElement("sequential");
  +ret.setTaskName("sequential");
  +ret.setNamespace("");
  +ret.setQName("sequential");
  +new RuntimeConfigurable(ret, "sequential");
  +for (int i = 0; i < nestedSequential.getNested().size(); ++i) {
  +UnknownElement e =
  +(UnknownElement) nestedSequential.getNested().get(i);
  +ret.addChild(e);
  +ret.getWrapper().addChild(e.getWrapper());
  +}
  +return ret;
   }
   
   /**
  @@ -188,8 +242,8 @@
*
*/
   public void execute() {
  -if 

[VOTE] macrodef - do attributes as properties or substitutions

[Stefan Bodewig]

Hi,

I don't think that another discussion thread will lead us anywhere.
Instead of trying to summarize what has been discussed, let me point
to the archives (I hope the list is complete):









I'd like to keep this particular vote focussed on property versus
textual substitution.  I am aware that the vote won't be complete
after that as we'll still have issues to decide upon (scope+extent or
notation, depending on this vote's outcome), but let's get this one
here straight first.

Actually, I'm not 100% sure about the rules we have to apply since
we've already shipped betas with the code, so strictly speaking a
decision we are considering a code change which would require (lazy)
consensus of the committers as opposed to a new idea that would
require a majority only.  Let's see where we get from here and whether
we'll have to actually decide that at all 8-)

Stefan

OK, how do we want to implement  attributes:

[ ] as textual substitution
[ ] as "real" Ant properties

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] macrodef - do attributes as properties or substitutions

[peter reilly]

On Tuesday 11 November 2003 12:22, Stefan Bodewig wrote:
> Stefan
>
> OK, how do we want to implement  attributes:
>
> [ ] as textual substitution
> [X] as "real" Ant properties

Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] macrodef - do attributes as properties or substitution s

[Jan . Materne]

> OK, how do we want to implement  attributes:
 
  [ ] as textual substitution
  [X] as "real" Ant properties


Jan

AW: [VOTE] macrodef - do attributes as properties or substitutions

[Antoine Levy-Lambert]

On Tuesday 11 November 2003 12:22, Stefan Bodewig wrote:
> Stefan
>
> OK, how do we want to implement  attributes:
>
> [ ] as textual substitution
> [X] as "real" Ant properties

Antoine



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Namespace support in ant 1.6

[Jose Alberto Fernandez]

I think the right thing, technically, is to use (b),
however due to the way conditions where defined (using class extension)
and due to the fact that  extends condition, this makes for a very
ugly result. Is there a way to redefine antcontrib's  to make it
show a syntax like (c) eventhough is using (b) rules?

I guess I do not want to just provide our own implementation, but to
prove that we can offer a way for third parties to reshuffle their
code a little, and gain having nice NS syntax.

Ideas?

Jose Alberto

> -Original Message-
> From: peter reilly [mailto:[EMAIL PROTECTED] 
> Sent: 10 November 2003 18:21
> To: Ant Developers List
> Subject: Namespace support in ant 1.6
> 
> 
> Hi,
> I would like to get some movement on the outstanding issues
> if ant 1.6.
> 
> One of the outstanding issues is what namespace to use
> for nested elements of tasks. (Discovered by introspection rules).
> 
> The choices are:
>   a) Use the default ant namespace, this is the current rule.
>   b) Use the namespace of the enclosing task or type.
>   c) Allow either - let the build script author choose.
> 
> Using the if task from ant-contrib and assuming an
> project tag of  as an example:
> 
> Choice a)
> 
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
> 
> Choice b)
> 
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
> 
> 
> Choice c)
> 
> (one could use a) or b) or this)
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
> 
> 
> Peter
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Namespace support in ant 1.6

[Stefan Bodewig]

On Tue, 11 Nov 2003, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:

> Is there a way to redefine antcontrib's  to make it show a
> syntax like (c) eventhough is using (b) rules?

Not as long as Ant doesn't typedef  - and Ant can't do that unless
we have a way to associate different classes with  depending on
the context (is it the condition or the selector?).

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Namespace support in ant 1.6

[peter reilly]

On Tuesday 11 November 2003 14:39, Jose Alberto Fernandez wrote:
> I think the right thing, technically, is to use (b),
> however due to the way conditions where defined (using class extension)
> and due to the fact that  extends condition, this makes for a very
> ugly result. Is there a way to redefine antcontrib's  to make it
> show a syntax like (c) eventhough is using (b) rules?

The simplest way is to introduce roles.
Then the conditions would be simple typedefs.
Roles would needed to distinguish between, for example
 as a condition and  as a file selector.

The role feature (based on your original role work)
consists of specifing the context in which the typedef is
valid for.
So




would define two ant types, one of which may be used as a condition
and the other may be used as a selector.

I have also being thinking of another possiblity, have
a attribute on the typedef specifing that there are multiple
definitions for this name





Ant will then use the best matching "or" for the context.
or perhaps:

 
   
   


Ant would then use the first class that is valid for the context.

Peter
>
> I guess I do not want to just provide our own implementation, but to
> prove that we can offer a way for third parties to reshuffle their
> code a little, and gain having nice NS syntax.
>
> Ideas?
>
> Jose Alberto
>
> > -Original Message-
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> > Sent: 10 November 2003 18:21
> > To: Ant Developers List
> > Subject: Namespace support in ant 1.6
> >
> >
> > Hi,
> > I would like to get some movement on the outstanding issues
> > if ant 1.6.
> >
> > One of the outstanding issues is what namespace to use
> > for nested elements of tasks. (Discovered by introspection rules).
> >
> > The choices are:
> >   a) Use the default ant namespace, this is the current rule.
> >   b) Use the namespace of the enclosing task or type.
> >   c) Allow either - let the build script author choose.
> >
> > Using the if task from ant-contrib and assuming an
> > project tag of  > as an example:
> >
> > Choice a)
> >
> > 
> >
> >   
> >   
> >
> >
> >   both conditions are true
> >
> > 
> >
> > Choice b)
> >
> > 
> >
> >   
> >   
> >
> >
> >   both conditions are true
> >
> > 
> >
> >
> > Choice c)
> >
> > (one could use a) or b) or this)
> > 
> >
> >   
> >   
> >
> >
> >   both conditions are true
> >
> > 
> >
> >
> > Peter
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Beta3?

[Dominique Devienne]

I've started using Ant 1.6 beta1 for many things at work, but I cannot
start forcing all projects to use it, 'cause I want to use namespaces
and the Ant namespace name changed, but no beta has this change yet...

So I'm feeling kind of stuck. I know active discussions are going on to
try to get 1.6 out the door, but unless this is going to pan out really
soon, I'd really appreciate the release of a Beta3 in the mean time.

Thanks, --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Namespace support in ant 1.6

[Stefan Bodewig]

On Tue, 11 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:

> The simplest way is to introduce roles.

Sure - but then we are way out of Ant 1.6 land.  At least if we take
the released betas as an indication of what 1.6 was supposed to be.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Beta3?

[Stefan Bodewig]

On Tue, 11 Nov 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:

> I'd really appreciate the release of a Beta3 in the mean time.

IMHO we shouldn't increase confusion by releasing beta3 before we know
what the details of 1.6-final are going to be.  I'd very much prefer
to get the few remaining issues sorted out now and release beta3 as
soon after that as possible.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Beta3?

[Dominique Devienne]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> 
> On Tue, 11 Nov 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> 
> > I'd really appreciate the release of a Beta3 in the mean time.
> 
> IMHO we shouldn't increase confusion by releasing beta3 before we know
> what the details of 1.6-final are going to be.  I'd very much prefer
> to get the few remaining issues sorted out now and release beta3 as
> soon after that as possible.

Sigh. Sure, I understand. I haven't caught up with the namespace discussion,
but it seems to me from 30,000 feet that anything that contradicts the XML
namespace rules would not be good... If that means NS prefixing all nested
elements of NS prefixed custom task/type, so be it.

Any convenience added which is not XML compatible is just asking for
trouble IMHO. --DD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

OK, how do we want to implement  attributes:

[X] as textual substitution
[ ] as "real" Ant properties

I know I am not a committer, but ...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] macrodef - do attributes as properties or substitution s

[Dominique Devienne]

> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> OK, how do we want to implement  attributes:
> 
> [X] as textual substitution
> [ ] as "real" Ant properties

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] macrodef - do attributes as properties or substitutions

[Steve Cohen]

I don't have a vote but if I did, I'd be
 [X] as textual substitution
 [ ] as "real" Ant properties 

-Original Message-
From: Dominique Devienne [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 11, 2003 10:14 AM
To: 'Ant Developers List'
Subject: RE: [VOTE] macrodef - do attributes as properties or
substitutions


> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> OK, how do we want to implement  attributes:
> 
> [X] as textual substitution
> [ ] as "real" Ant properties

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Namespace support in ant 1.6

[Jose Alberto Fernandez]

> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> On Tuesday 11 November 2003 14:39, Jose Alberto Fernandez wrote:
> > I think the right thing, technically, is to use (b),
> > however due to the way conditions where defined (using class 
> > extension) and due to the fact that  extends condition, 
> this makes 
> > for a very ugly result. Is there a way to redefine 
> antcontrib's  
> > to make it show a syntax like (c) eventhough is using (b) rules?
> 
> The simplest way is to introduce roles.
> Then the conditions would be simple typedefs.
> Roles would needed to distinguish between, for example
>  as a condition and  as a file selector.
> 
> The role feature (based on your original role work)
> consists of specifing the context in which the typedef is
> valid for.
> So
>   classname="org.apache.tools.ant.taskdefs.condition.Or"
>role="org.apache.tools.ant.taskdefs.condition.Condition"/>
> 
>   classname="org.apache.tools.ant.types.selectors.OrSelector"
>  role="org.apache.tools.ant.types.selectors.FileSelector"/>
> 
> would define two ant types, one of which may be used as a 
> condition and the other may be used as a selector.
> 

Well, as you may suspect, this is the one I prefer :-)
The reason being that the two definitions above may be in separate
3rd party antlibs and hence they are not aware of each other.

> I have also being thinking of another possiblity, have
> a attribute on the typedef specifing that there are multiple 
> definitions for this name
> 
>   classname="org.apache.tools.ant.taskdefs.condition.Or" />
> 
>   
> classname="org.apache.tools.ant.types.selectors.OrSelector" />
> 
> Ant will then use the best matching "or" for the context.

This would mean that all antlibs need to agree on allowing multiple
names
before it can be used at all.

> or perhaps:
> 
>  
>
>
> 
> 
> Ant would then use the first class that is valid for the context.
> 

This would disallow having definitions across antlibs. Which I would
prefer to avoid.

I know that these shortcommings would be mitigated by using NameSpaces,
but yet
I still want to be able to lump all my antlibs into the default
namespace and
use them without namespace stuff.

Jose Alberto

> Peter
> >
> > I guess I do not want to just provide our own 
> implementation, but to 
> > prove that we can offer a way for third parties to reshuffle their 
> > code a little, and gain having nice NS syntax.
> >
> > Ideas?
> >
> > Jose Alberto
> >
> > > -Original Message-
> > > From: peter reilly [mailto:[EMAIL PROTECTED]
> > > Sent: 10 November 2003 18:21
> > > To: Ant Developers List
> > > Subject: Namespace support in ant 1.6
> > >
> > >
> > > Hi,
> > > I would like to get some movement on the outstanding 
> issues if ant 
> > > 1.6.
> > >
> > > One of the outstanding issues is what namespace to use
> > > for nested elements of tasks. (Discovered by introspection rules).
> > >
> > > The choices are:
> > >   a) Use the default ant namespace, this is the current rule.
> > >   b) Use the namespace of the enclosing task or type.
> > >   c) Allow either - let the build script author choose.
> > >
> > > Using the if task from ant-contrib and assuming an
> > > project tag of  xmlns:antcontrib="antlib:net.sf.antcontrib"
> > > as an example:
> > >
> > > Choice a)
> > >
> > > 
> > >
> > >   
> > >   
> > >
> > >
> > >   both conditions are true
> > >
> > > 
> > >
> > > Choice b)
> > >
> > > 
> > >
> > >   
> > >   
> > >
> > >
> > >   both conditions are true
> > >
> > > 
> > >
> > >
> > > Choice c)
> > >
> > > (one could use a) or b) or this)
> > > 
> > >
> > >   
> > >   
> > >
> > >
> > >   both conditions are true
> > >
> > > 
> > >
> > >
> > > Peter
> > >
> > > 
> 
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH] to whatsnew for 1.6

[Shatzer, Larry]

I noticed that a change that I submitted (and then was accepted) was never
added into the WHATSNEW file. (the addition of reallyquiet attribute to
).

Attached is the patch to add that.

-- Larry

Index: WHATSNEW
===
RCS file: /home/cvspublic/ant/WHATSNEW,v
retrieving revision 1.503.2.11
diff -u -r1.503.2.11 WHATSNEW
--- WHATSNEW6 Nov 2003 21:26:19 -   1.503.2.11
+++ WHATSNEW11 Nov 2003 16:46:28 -
@@ -212,6 +212,9 @@
   are resolved at a later stage. This causes some
   differences especially for user defined task containers.
 
+* The  task now accepts the attribute 'reallyquiet', which is synonymous
+  with -Q on the command line.
+
 Fixed bugs:
 ---
 * Filter readers were not handling line endings properly.  Bugzilla

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Namespace support in ant 1.6

[Knut Wannheden]

Regarding XML namespaces...

Something else that would interest me is how namespaced attributes will be
handled.  IMHO they should be allowed and ignored.  But will a task
implementation have the ability to query them?

Cheers,

--knut

"peter reilly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
> I would like to get some movement on the outstanding issues
> if ant 1.6.
>
> One of the outstanding issues is what namespace to use
> for nested elements of tasks. (Discovered by introspection
> rules).
>
> The choices are:
>   a) Use the default ant namespace, this is the current rule.
>   b) Use the namespace of the enclosing task or type.
>   c) Allow either - let the build script author choose.
>
> Using the if task from ant-contrib and assuming an
> project tag of  as an example:
>
> Choice a)
>
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
>
> Choice b)
>
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
>
>
> Choice c)
>
> (one could use a) or b) or this)
> 
>
>   
>   
>
>
>   both conditions are true
>
> 
>
>
> Peter




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Namespace support in ant 1.6

[peter reilly]

On Tuesday 11 November 2003 16:49, Knut Wannheden wrote:
> Regarding XML namespaces...
>
> Something else that would interest me is how namespaced attributes will be
> handled.  IMHO they should be allowed and ignored.  But will a task
> implementation have the ability to query them?

Opps,
at the moment the namespace for attributes is completely ignored.

Peter
>
> Cheers,
>
> --knut
>
> "peter reilly" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> > Hi,
> > I would like to get some movement on the outstanding issues
> > if ant 1.6.
> >
> > One of the outstanding issues is what namespace to use
> > for nested elements of tasks. (Discovered by introspection
> > rules).
> >
> > The choices are:
> >   a) Use the default ant namespace, this is the current rule.
> >   b) Use the namespace of the enclosing task or type.
> >   c) Allow either - let the build script author choose.
> >
> > Using the if task from ant-contrib and assuming an
> > project tag of  > as an example:
> >
> > Choice a)
> >
> > 
> >
> >   
> >   
> >
> >
> >   both conditions are true
> >
> > 
> >
> > Choice b)
> >
> > 
> >
> >   
> >   
> >
> >
> >   both conditions are true
> >
> > 
> >
> >
> > Choice c)
> >
> > (one could use a) or b) or this)
> > 
> >
> >   
> >   
> >
> >
> >   both conditions are true
> >
> > 
> >
> >
> > Peter
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

I think I need to justify some more what do I think the way I do
about macrodef. I know the vote is already going, but I really
want for people to understand my position.

To me macrodefs are for writing all those tasks that I am too
lazy, or they are too simple for me to need to go and write and
maintain some Java code. It is not to replace  but
as a side efect, it will replace all those little antcalls we wrote 
because we didn't want to write java.

With that in mind, I would want  to resemble a Java task
and not to resemble . And if it resemples a java task,
then attributes should resemble java variables in my code. 
That is, its values should not affect the values of properties
(which is what  does). If I want a task to affect other tasks
then I can always call  or  as part of the macro.
But if  modify properties, then there is no way for me
to stop them for happening.

Substitution is the least interfearing behavior.

So, that is why I think the way I do. Comments? changes of votes? :-)

Jose Alberto
 
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] 
> Sent: 11 November 2003 12:23
> To: [EMAIL PROTECTED]
> Subject: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> 
> Hi,
> 
> I don't think that another discussion thread will lead us 
> anywhere. Instead of trying to summarize what has been 
> discussed, let me point to the archives (I hope the list is complete):
> 








I'd like to keep this particular vote focussed on property versus
textual substitution.  I am aware that the vote won't be complete after
that as we'll still have issues to decide upon (scope+extent or
notation, depending on this vote's outcome), but let's get this one here
straight first.

Actually, I'm not 100% sure about the rules we have to apply since we've
already shipped betas with the code, so strictly speaking a decision we
are considering a code change which would require (lazy) consensus of
the committers as opposed to a new idea that would require a majority
only.  Let's see where we get from here and whether we'll have to
actually decide that at all 8-)

Stefan

OK, how do we want to implement  attributes:

[ ] as textual substitution
[ ] as "real" Ant properties

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Namespace support in ant 1.6

[Jim Fuller]

>I know that these shortcommings would be mitigated by using NameSpaces,
>but yet
>I still want to be able to lump all my antlibs into the default
>namespace and
>use them without namespace stuff.

which is why I suggested having an ant processor switch stating
 
a) if namespace processing is on
b) another switch that states to handle antlib in default namespace, or have 
some convention
 
ta, Jim Fuller
This e-mail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the intended recipient please contact the sender immediately. Any 
disclosure, copying, distribution or any other use of this communication is 
strictly prohibited and may be unlawful. Stuart Lawrence Marketing 
Communications Limited reserves the right to monitor and intercept 
communications for unlawful business purposes.

This also confirms that this message has been swept for viruses, although 
Stuart Lawrence Marketing Communications Limited accepts no responsibility for 
any loss or damage resulting directly or indirectly from the use of this email 
or contents.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24231] - command-line option to signify no more options

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24231

command-line option to signify no more options





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 17:44 ---
The usual point of -- is that it means "there are no further options past this
point in the command line". An example from the man page of the unix rm command:

To remove a file whose name starts with a ‘-’, for example ‘-foo’,  use
   one of these commands:

  rm -- -foo

  rm ./-foo

 
Correct me if this is not the meaning you intend, as I have misunderstood your
intent. I assume you do from this line in your patch:
+msg.append("  -. signify end of options" + lSep);


So, to answer your question assuming I understand your intent and your patch
does what I think you intend (I havn't directly verified it)...

Currently targets begining with - are currently misidentified as (usually
unrecognized) options by the commandline parser. If -- was included in the
commandline before the target was specified the command line would now
understand that -targetname is a target and not an option and properly execute
it. Misidentification is the only reason targets starting with - don't execute
from the command line. They are otherwise perfectly legal targets with equal 
status.

Try this sometime:


  


With your patch I assume it would be possible to say 

ant -. -projecthelp 

and get the output:

-projecthelp:
 [echo] You can't see me!

The problem is that the -targetname "feature" is not (so far as I know) an
intentionally designed in feature with respect to "hiding internal targets", but
a coincidental side effect of command line parsing when it tries to warn the
user of typos in their options. Sadly, I just discovered that this technique of
access control was added to the documentation for the 1.5 release. IMHO Adding
'-' to the target name to prevent invoction should not have been made a
supported feature, although it now is (as of version 1.18 of using.html, and
it's subsequent release in 1.5). This practice overloads the meaning of the name
atribute, and creates a syntax within the realm of target names, which was
(until the "feature" was documented) unconstrained.

This "feature" had previously remained undocumented despite the fact that it
existed since version 1.1 of Main.java. (I avoid using it myself, since I came
up with an alternate, if somewhat lenghthier, method of controling access to
targets back when 1.4.1 was the current release). Another flaw of this "feature"
is that it yeilds an error message about options rather than one indicating that
the build file writer chose not to let the user run this target directly. The
later would imply that the user should look for another target, whereas the
former looks like a mistake by the writer of the build file and seems to imply
the build should be "fixed" by changing the target name (to the newish user who
doesn't know or remember about - targets at least).

The ability to protect/hide targets from the command line user is clearly
desired by many build file authors and the "feature" is widely used. Although
the "feature" is based on an "until recently undocumented feature" it is now is
a back compatability issue. I expect that back compatability is likely to be
honored here, but even if it isn't it would be very poor form (imho) to break it
without providing an alternative. 

My patch to bug 22020 attempts to add an explicit means of specifying command
line visibility, but is being held for consideration in 1.7 because the
mechanism I propose may also be expanded or altered to allow build file writers
to specify accessibility of targets from other contexts (such as import).
Several commiters feel (I am not a commiter) that access can't be implemented
until we are comfortable with import and have a feel for how people will use it.
I have to admit that this does sound reasonable.

Resolving bug 22020 (with or without my patch) would supply an alternative
access control mechanism and thus make it possible to begin considering a minor
break in back compatability by implementing the feature you are requesting.

However, given that it is now a back compatability issue, I suspect you will
need a use case that can't be resolved with a simple work around before any
patch will be commited. I will leave it to commiters to declare this WONTFIX or
not however.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Steve Cohen]

Wouldn't you say, though, Jose, that  does replace those uses
of  for which  had too big a footprint for the job?  

-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 11, 2003 11:19 AM
To: Ant Developers List
Subject: RE: macrodef - do attributes as properties or substitutions


I think I need to justify some more what do I think the way I do about
macrodef. I know the vote is already going, but I really want for people
to understand my position.

To me macrodefs are for writing all those tasks that I am too lazy, or
they are too simple for me to need to go and write and maintain some
Java code. It is not to replace  but as a side efect, it will
replace all those little antcalls we wrote 
because we didn't want to write java.

With that in mind, I would want  to resemble a Java task and
not to resemble . And if it resemples a java task, then
attributes should resemble java variables in my code. 
That is, its values should not affect the values of properties (which is
what  does). If I want a task to affect other tasks then I can
always call  or  as part of the macro. But if
 modify properties, then there is no way for me to stop them
for happening.

Substitution is the least interfearing behavior.

So, that is why I think the way I do. Comments? changes of votes? :-)

Jose Alberto
 
> -Original Message-
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 11 November 2003 12:23
> To: [EMAIL PROTECTED]
> Subject: [VOTE] macrodef - do attributes as properties or 
> substitutions
> 
> 
> Hi,
> 
> I don't think that another discussion thread will lead us
> anywhere. Instead of trying to summarize what has been 
> discussed, let me point to the archives (I hope the list is complete):
> 








I'd like to keep this particular vote focussed on property versus
textual substitution.  I am aware that the vote won't be complete after
that as we'll still have issues to decide upon (scope+extent or
notation, depending on this vote's outcome), but let's get this one here
straight first.

Actually, I'm not 100% sure about the rules we have to apply since we've
already shipped betas with the code, so strictly speaking a decision we
are considering a code change which would require (lazy) consensus of
the committers as opposed to a new idea that would require a majority
only.  Let's see where we get from here and whether we'll have to
actually decide that at all 8-)

Stefan

OK, how do we want to implement  attributes:

[ ] as textual substitution
[ ] as "real" Ant properties

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: macrodef - do attributes as properties or substitutions

[Jose Alberto Fernandez]

> From: Steve Cohen [mailto:[EMAIL PROTECTED] 
> 
> Wouldn't you say, though, Jose, that  does replace 
> those uses of  for which  had too big a 
> footprint for the job?  
> 

Oh, but of course. I do plan to use macrodef to replace things
that I did with  before. But the reason they were done
with  before, is that it was more convinient than writing
the equivalent script or java code; they did not need to evaluate
multiple targets or other complex stuff. 

For things more complex,  is still the way to go. Why?
Because it provides a new execution context, in which I can deside
whether properties are inherited or not, and it provides isolation
so that the parent context is not directly manipulated by the child.

 using  would be a cluge in the middle, half here
half there, which I think is wrong. Either is a macro definition 
(as the term is defined in computer science form the days of assembler)
it should be called something else and have a real execution context.

BTW, how this things will affect the other tasks derived from macrodef
like presetdef?


Jose Alberto

> -Original Message-
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, November 11, 2003 11:19 AM
> To: Ant Developers List
> Subject: RE: macrodef - do attributes as properties or substitutions
> 
> 
> I think I need to justify some more what do I think the way I 
> do about macrodef. I know the vote is already going, but I 
> really want for people to understand my position.
> 
> To me macrodefs are for writing all those tasks that I am too 
> lazy, or they are too simple for me to need to go and write 
> and maintain some Java code. It is not to replace  
> but as a side efect, it will replace all those little 
> antcalls we wrote 
> because we didn't want to write java.
> 
> With that in mind, I would want  to resemble a Java 
> task and not to resemble . And if it resemples a 
> java task, then attributes should resemble java variables in my code. 
> That is, its values should not affect the values of 
> properties (which is what  does). If I want a task to 
> affect other tasks then I can always call  or 
>  as part of the macro. But if  modify 
> properties, then there is no way for me to stop them for happening.
> 
> Substitution is the least interfearing behavior.
> 
> So, that is why I think the way I do. Comments? changes of votes? :-)
> 
> Jose Alberto
>  
> > -Original Message-
> > From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> > Sent: 11 November 2003 12:23
> > To: [EMAIL PROTECTED]
> > Subject: [VOTE] macrodef - do attributes as properties or
> > substitutions
> > 
> > 
> > Hi,
> > 
> > I don't think that another discussion thread will lead us anywhere. 
> > Instead of trying to summarize what has been discussed, let 
> me point 
> > to the archives (I hope the list is complete):
> > 
> 
> 
> 
> 
> 
> 
> 
> 
> I'd like to keep this particular vote focussed on property 
> versus textual substitution.  I am aware that the vote won't 
> be complete after that as we'll still have issues to decide 
> upon (scope+extent or notation, depending on this vote's 
> outcome), but let's get this one here straight first.
> 
> Actually, I'm not 100% sure about the rules we have to apply 
> since we've already shipped betas with the code, so strictly 
> speaking a decision we are considering a code change which 
> would require (lazy) consensus of the committers as opposed 
> to a new idea that would require a majority only.  Let's see 
> where we get from here and whether we'll have to actually 
> decide that at all 8-)
> 
> Stefan
> 
> OK, how do we want to implement  attributes:
> 
> [ ] as textual substitution
> [ ] as "real" Ant properties
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24627] New: - [patch] make to include directory path when complaining about it

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24627

[patch] make  to include directory path when complaining about it

   Summary: [patch] make  to include directory path when
complaining about it
   Product: Ant
   Version: 1.6Beta
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


just better error reporting

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 24627] - [patch] make to include directory path when complaining about it

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24627

[patch] make  to include directory path when complaining about it





--- Additional Comments From [EMAIL PROTECTED]  2003-11-11 21:19 ---
Created an attachment (id=9060)
ExecTast.java patch

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23314] - org.apache.tools.ant.taskdefs.XSTLProcess Standard Parameter

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23314

org.apache.tools.ant.taskdefs.XSTLProcess Standard Parameter

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Target Milestone|1.6 |1.7

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]