RE: Roles (was: antlib)

[Jose Alberto Fernandez]

> From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
> 
> > I have no problem on allowing people to use namespaces, but I do 
> > have a problem on forcing people to use them just because 
> some others
> > want to use some fancy XML tool. The buildfile belongs to the
> > user and s/he should be in charge.
> > 
> 
> As someone already said, it's about "not reinventing the 
> wheel", not about
> enabling the use of fancy tools.  But as ubiquitous and 
> accepted as XML
> namespaces are, I see many things that could be gained from using
> namespaces.  Also, I suspect most users familiar with XML 
> will have had some
> dose of contact with namespaces.
> 

But ANT is not for experience XML users but for Java programmers
or C or .NET (with the new tasks). ANT is popular because
it is simple to use you do not have construccions that require
you to read a full spec to understand. I am not against NS, but
I am against forcing people to use them just because.

> > > Also namespaces lets the antlib user specify what prefix to 
> > > use.  But it
> > > doesn't allow two antlibs to use the same prefix in the 
> > > context of the same
> > > element, which I think is good.
> > > 
> > 
> > This sounds proper in theory, but in practice lets see:
> > 
> >  1) Lets assume that we still want to be able to chop ANT jars
> > between core and different optional jars which have specific
> > dependencies of diferent packages and such.
> > 
> >  2) Now because they are in different antlibs it would mean I am
> > forced to use different namespaces for each.
> > 
> 
> Is that really so?  As I understood it antlibs wouldn't be a 
> requirement for
> providing Ant tasks and types.  I thought the normal  and
>  would still work as they do now.
> 

So again you have a two tier world where some things are more core
than others. Me as a library provider need to decide now whether
to ship my library with a property file so that it can be incorporated
seemingly into ANT namespace or use an XML definition and force
my users to learn NS. Hu

> I suppose it would also be possible to let one antlib extend 
> another one,
> thus letting it use the same namespace.
> 

The suggestion I was critisazing was that of having "one ANTlib one URI"


> >  3) So now you have people using 3rd party tasks like antcontrib
> > without problem and without conflicts, but they would have to
> > change not just one line (to use the antlib) but every bloddy
> > use of the tasks just because they are forced to use 
> name spaces.
> > 
> 
> To use antcontrib as an antlib they would at the very least 
> have to replace
> the s with an  element or something, no?  
> But the tasks
> should still work as they do now using .
> 

So not the antlib writer will have to provide both an XML descriptor 
AND a properties file? How about all the fancy typing?

> > > If you really want you can use short names with namespaces as 
> > > well.  Just
> > > set the default namespace locally.
> > > 
> > 
> > I have no problem using XML namespaces as long as they are 
> independent
> > of the antlib and under complete user control (not antlib 
> > designer control).
> > In other words the user should be able to decide if s/he 
> wants to load
> > the library on some particular namespace or in the default "" 
> > namespace
> > which is the one used by core.
> > 
> > So if I say:
> > 
> > 
> > 
> > I will be able to use: , , etc. But is I do:
> > 
> > 
> >
> > 
> > 
> > 
> > then I can use , , etc.
> > 
> 
> I think the  shouldn't define the prefix, but the 
> namespace URI
> instead .  Something like:
> 
>   
>   ns="urn:uri-supplied-by-ant-user"/>
>  
>   
> 

I thing this is what I meant (in escense), with the understanding
that:

a) the user can use the same URI on several s
   (any conflicts are his problem)

b) the default value for the ns attribute is ns="".

> Of course if the antlib would provide its own namespace in 
> the descriptor.
> Ant could do some kind of automatic loading when a namespace 
> declaration
> matching the namespace URI is encountered.  But I'm not sure 
> that's a good
> idea.
> 

Agreed it is not good idea.

> > Which means that the default value for the 'usens' attribute 
> > is "" which assumes
> > some implicit namespace definitions like:
> > 
> > xmlns="ant-namespace" and probably xmlns:ant="ant-namespace"
> > 
> > which uses as kosher namespaces as possible, I think.
> > 
> 
> But this would require that the  element would 
> define the default
> namespace like this:
> 
>   
>   ...
>   
> 
> Why not use the empty namespace for Ant core?
> 

Fine with me.

Jose Alberto

Re: Roles (was: antlib)

[Conor MacNeill]

On Thu, 8 May 2003 12:30 am, Costin Manolache wrote:
>
> The URI however should be chosen by the antlib author ( maybe based on some
> rules specific to ant ), and should serve as an ID of the library.
>
> My proposal is to use the (main) package name. There are other options -
> but I don't think every end user using it's own name for an antlib is a
> good one.
>

+1

I believe the URI should be defined by the antlib builder, not the user. It 
should be opaque - no semantic structure, at least from Ant's processing. An 
antlib should just declare to what namespace URI it belongs and then that 
antlib's defs would be accessible through that namespace in the build file.

This would allow multiple antlibs to belong to a single namespace, which might 
be useful for extension purposes. So, something like this


  
  


Antlibs could potentially declare themselves to belong to the default 
namespace. This would handle Ant's existing optional tasks. This facility 
might be restricted to antlibs found in a particular location.

A classloader could probably be associated with the URI, picking up all 
antlibs declaring the URI. 

Just some thoughts
Conor

RE: Roles (was: antlib)

[Jose Alberto Fernandez]

> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> 
> 
> I think you started with wrong assumptions here.
> 
> There is no need to change anything in the core or optional tasks, 
> you can have an antlib that uses multiple jars ( and most 
> likely antlibs
> will eventually use some dependency mechanism and have 
> mutliple jars ).
> 
> 

So you want to continue with the aberration of allowing having
tasks in the descriptor that cannot be loaded or fail to resolve 
due to lack of dependencies? This is what we have to allow today
in order to have those magic property files that contain all the
optional tasks. At least I was striding to get rid of it.

But if you impose the rule "one antlib one URI" (as it was suggested)
then you have to continue with this aberration just for backward compatibility.

Let me just make clear that I am assuming the content of an "antlib"
is defined by its XML (or whatever) descriptor.

> > I have no problem using XML namespaces as long as they are 
> independent
> > of the antlib and under complete user control (not antlib designer
> > control). In other words the user should be able to decide 
> if s/he wants
> > to load the library on some particular namespace or in the 
> default ""
> > namespace which is the one used by core.
> 
> The namespace is not under user control - by definition. Read 
> the W3C spec,
> it is designed to be fixed, stable, durable, etc. 
> And there is no point in the user changing the namespace URI 
> - the ns is 
> the id or name of the library.
> 

There is definetly nothing on W3C about antlib libraries. The URI
is just a string and W3C imposes no meaning to it. Whether it is 
universally unique or not is just suggested not impossed,
the same as public-ids for DTDs. As long as you can distinguish
between two diferent things that is all that is required.

> Regarding use of the core namespace if no name conflicts: +1
> 

So I am an  writer and have a  task and because
it does not conflict with core I fix it in the core namespace.
So ANT 1.7 comes along and decides to add a  task to core.
Now what, did 1.7 broke backward compatibility? My antlib is now
incompatible with the new version of ANT eventhough no APIs where
mofified. Is ant.apache.org gonna monitor all 3rd party
 to make sure core never uses a name someone else
already used?

This is a administration nightmare. This is why I am saying
let the user resolve the conflicts, if he decides to use two
antlibs with clashes, then allow him to load them is separate
namespaces to resolve its own conflicts.

> 
> 
> > So if I say:
> > 
> > 
> > 
> > I will be able to use: , , etc. But is I do:
> > 
> > 
> 
> Again - the URI is not under user control, but under the antlib author
> control. Just like the "if" and the other task names. 
> Allowing the user to
> rename tasks would be very wrong and confusing. ( let's 
> rename ""
> to "copy", then import few files - and figure out what the 
> build file is
> actually doing ). 
> 

Tell me where in the introspection engine this is required.
This is just your idea. Antlib could pick the namespace dynamically
at loading time. 

And lets just say that today I could rename all tasks to french
names if I wanted just need to write a properties file.
(granted the inner-elements will continue in english, but hey).

Jose Alberto

RE: Roles (was: antlib)

[Jose Alberto Fernandez]

> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> 
> Stefan Bodewig wrote:
> 
> > On Tue, 06 May 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> >> Jose Alberto Fernandez wrote:
> >> 
> >>> The important point is for the user (which is the one who has to
> >>> deal with name clashes) to have control of the final naming scheme
> >>> used in his/her buildfile.
> >>
> 
> If you're reffering to the prefix - of course, that's how NS works.
> 
> The URI however should be chosen by the antlib author ( maybe 
> based on some
> rules specific to ant ), and should serve as an ID of the library.
> 

Why? What has the URI to do with the classes or elements defined in the
antlib? You are impossing an arbitrary tie to a uri namespace
that has no real meaning whatsoever, since the meaning is on the classes
themselves.

> My proposal is to use the (main) package name. There are 
> other options - 
> but I don't think every end user using it's own name for an 
> antlib is a good
> one. 
> 

What I suggest is to let the user of the antlib define whatever URI
it wants to whatever antlib it wants and it that way giving him
control of which libraries s/he wants to use toguether on the same
namespace. The antlib will just load the definitions there
and that's it. There is no reason to force people to use different
spaces or to enforce rules to administer diferent spaces.

Jose Alberto

DO NOT REPLY [Bug 19747] New: - Echoproperties should not overwrite; Random order is hassle

[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=19747

Echoproperties should not overwrite; Random order is hassle

   Summary: Echoproperties should not overwrite; Random order is
hassle
   Product: Ant
   Version: 1.5.2
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


In the process of building an audit file to identify all versions and other 
info specific to an automated build, I call Echoproperties with a destination 
file. Unfortunately this overwrites the existing file, so I cannot apply nice 
header formatting. Also I would like to sort the properties... It is hard to 
navigate the list in the random order they appear in. Adding optional sort and 
append attributes would be a nice improvement and would retain current 
operation.

DO NOT REPLY [Bug 19734] - to support wildcards

[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=19734

 to support wildcards





--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 20:16 ---
i can't do that. here's the reason: i use Eclipse as the IDE that runs under 
JDK 
1.3. but the ant tasks should use jdk 1.4 for the regexp to be used. but 
eclipse 
runs ant with the same VM as eclipse runs.

DO NOT REPLY [Bug 19737] - does not load updated file in same target

[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=19737

 does not load updated file in same target





--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 20:13 ---
nope, as the code states:












the property is just loaded once (this is the only target in the ant build file 
that handles with the build.number). so the property is just set once, after 
the 
 task was called. and i assume that this  task does 
not have an internal property "build.number" ... ?

Re: Roles (was: antlib)

[J.Pietschmann]

Jose Alberto Fernandez wrote:
I have no problem on allowing people to use namespaces, but I do 
have a problem on forcing people to use them just because some others
want to use some fancy XML tool. The buildfile belongs to the
user and s/he should be in charge.
The buildfile belongs to the user, but the vocabulary belongs to
the Ant/Task developers.
Do you complain about XHTML/XSLT/SVG/XSLFO/XForm etc. as well?
J.Pietschmann

Re: Roles (was: antlib)

[J.Pietschmann]

peter reilly wrote:
  -  namespaces of attributes is not handled yet - the
 code uses getQName() on the attributes and does
 not pass the URI of the attributes to the attribute list given
 to
Most vocabularies don't use namespaces for attributes, the reason being
that the semantics of attributes with the same name can be derived with
the help of the elements where the attributes appear.
An example:
  
and
  
The src attribute obviously serves a different purposes for the different
elements, but it is assumed the element provides enough context to handle
this.
An exception are attributes where more than one attribute with the same
local name can be expected to be attached to an element
An example
  
(or shorter:  )
The example may strike you as stupid, but this kind of vocabulary
may really evolve from merging simpler stuff. I'd think Ant can avoid this,
or at least try.

2) The usage of Project#createTask/DataType(name) will not work for
tasks loaded as a result of XML namespaces, a Project#createTask/DataType(
uri, name) method will need to be added.
Some projects migrated to namespaced XML by passing
  ns-uri+"^"+name
internally through the APIs.
J.Pietschmann

DO NOT REPLY [Bug 19743] New: - map does not translate correctly in pathconvert

[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=19743

map does not translate correctly in pathconvert

   Summary: map does not translate correctly in pathconvert
   Product: Ant
   Version: 1.5.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


map does not correctly convert the following fragment in pathconvert:

when i echo build.lib it displays "c:/temp/build/lib" which is the portable 
representation of separators. If i put this as a constant it does not work 
either, if i put c:\temp\build\lib as a constant it does work, even if i set 
the targetos to unix.








   

DO NOT REPLY [Bug 19740] New: - Ant TagDiff for CVS displays incomplete path

[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=19740

Ant TagDiff for CVS displays incomplete path

   Summary: Ant TagDiff for CVS displays incomplete path
   Product: Ant
   Version: 1.5.2
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When running tagdiff against a CVS module, all file paths are missing the first 
two characters.

Modified Files - 9 entries (back to top) 
 cumentation/Products/Session_1_0/Online Help/avcontrols.html (1.13.2.1)

DO NOT REPLY [Bug 19734] - to support wildcards

[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=19734

 to support wildcards





--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 16:06 ---
You do not add rt.jar to the classpath. 

You must use a 1.4.x VM to run Ant. Make sure your JAVA_HOME environment
variable points to a 1.4.x VM, not a 1.3.x VM.

Jesse

DO NOT REPLY [Bug 19734] - to support wildcards

[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=19734

 to support wildcards





--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 16:03 ---
well, when adding the Jakarta ORO lib to the classpath it works. but adding the 
JDK 1.4 rt.jar to the classpath, it still says: 

No supported regular expression matcher found

it would be nice to have at least JDK 1.4 regexp working so that no additional 
library is necessary (oro.jar)

DO NOT REPLY [Bug 19734] - to support wildcards

[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=19734

 to support wildcards





--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 15:38 ---
If you run Ant with a 1.4.x JVM it's supported, no need to add anything to the
classpath

If you want to use Jakarta-ORO, or Jakarta-Regexp, put the jar in $ANT_HOME/lib

It's not a core task because it requires external libraries to use it.

Jesse

Re: Roles (was: antlib)

[Stefan Bodewig]

On Wed, 07 May 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:

> If you're reffering to the prefix

I was.

> - of course, that's how NS works.

I know.

Stefan

DO NOT REPLY [Bug 19734] - to support wildcards

[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=19734

 to support wildcards





--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 15:28 ---
i tried it:

1. additing JDK 1.4.1 into class path =>
No supported regular expression matcher found

2. wanted to download jakarta regexp at http://jakarta.apache.org/site/
[preferred]/jakarta/regexp/ =>
not found

3. tried Jakarta ORO by including jakarta-oro-2.0.7.jar into classpath =>
No supported regular expression matcher found


I find this wildcard search a general feature, so why not support it in the 
core tasks? anyway, how do i get this  to work?

DO NOT REPLY [Bug 19737] - does not load updated file in same target

[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=19737

 does not load updated file in same target

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 15:22 ---
Please spare yourself some frustration and make yourself familiar with how
properties work in Ant.  If you reread my comment when I closed Bug 19730 you'll
see I said - no matter which task you've used to set it.

You say the build number doesn't change, this in turn implies that the property
has a value before you start the loadproperties task.  The task will read the
file (believe me, it does), but it will not change the value of the property
because properties are immutable in Ant.

RE: Roles (was: antlib)

[Costin Manolache]

Jose Alberto Fernandez wrote:

>> From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
>> 
>> > 
>> > Let's not reinvent the wheel here.
>> > 
>> > The solution for names conflicts is namespaces - not rewriting.
>> > 
>> 
>> I agree.  With the new ProjectHelper2 everything should be in
>> place to start
>> using namespaces.
>> 
> 
> I have no problem on allowing people to use namespaces, but I do
> have a problem on forcing people to use them just because some others
> want to use some fancy XML tool. The buildfile belongs to the
> user and s/he should be in charge.

Namespaces are the common solution used to resolve name conflicts.

I have a big problem on using some "original" solution like renaming 
tasks with some prefix. 

This has nothing to do with "fancy XML tools" ( in fact, very few 
editors are able to deal nicely with namespaces ). We have a problem - name
conflits - and one solution. 

I like Perl and the "there is more than one way to do things", but in
this case we have a standard solution that everyone uses, and it would be
very confusing and wrong to force the user to learn a different one.


>> This would also allow antlibs to have a DTD or XML Schema
>> which could be
>> used in XML editors or for validation.
>> 
> 
> Well ANT's XML is the result of introspection, and we already know
> our object model cannot be represented by a simple DTD. I see no way
> or reson to enforce 3rd party libraries to define their objects
> to be DTD-able.
> I am not sure about XMLSchema but my hopes are not too high.

I agree with you on this one. XMLSchema is one of the worse things
I've seen. 

However it is possible to associate a DTD/schema with (most) of the
ant ( we even have a dtd generator, that works great with emacs, I use 
the DTD every day ). And some users may choose to create build files
with editors using only the subset of ant that is supported by the editor
( i.e. fits the restrictions of the DTD/schema ).



>> Also namespaces lets the antlib user specify what prefix to
>> use.  But it
>> doesn't allow two antlibs to use the same prefix in the
>> context of the same
>> element, which I think is good.
>> 
> 
> This sounds proper in theory, but in practice lets see:
> 
>  1) Lets assume that we still want to be able to chop ANT jars
> between core and different optional jars which have specific
> dependencies of diferent packages and such.
 
>  2) Now because they are in different antlibs it would mean I am
> forced to use different namespaces for each.

Why ? I think most people agreed that using the jar file name as a 
namespace URI is not the best solution.

If we go with the package name ( or other solution where the ns is fixed 
by the antlib creator ) - you can have the files in multiple jars.
For package name - the descriptor will have to be in that package.


>  3) So now you have people using 3rd party tasks like antcontrib
> without problem and without conflicts, but they would have to
> change not just one line (to use the antlib) but every bloddy
> use of the tasks just because they are forced to use name spaces.

I think you started with wrong assumptions here.

There is no need to change anything in the core or optional tasks, 
you can have an antlib that uses multiple jars ( and most likely antlibs
will eventually use some dependency mechanism and have mutliple jars ).


 
> I doubt many people will be fill happy about that, and the backward
> compatibility consequences.
> 
>> If you really want you can use short names with namespaces as
>> well.  Just
>> set the default namespace locally.
>> 
> 
> I have no problem using XML namespaces as long as they are independent
> of the antlib and under complete user control (not antlib designer
> control). In other words the user should be able to decide if s/he wants
> to load the library on some particular namespace or in the default ""
> namespace which is the one used by core.

The namespace is not under user control - by definition. Read the W3C spec,
it is designed to be fixed, stable, durable, etc. 
And there is no point in the user changing the namespace URI - the ns is 
the id or name of the library.

Regarding use of the core namespace if no name conflicts: +1



> So if I say:
> 
> 
> 
> I will be able to use: , , etc. But is I do:
> 
> 

Again - the URI is not under user control, but under the antlib author
control. Just like the "if" and the other task names. Allowing the user to
rename tasks would be very wrong and confusing. ( let's rename ""
to "copy", then import few files - and figure out what the build file is
actually doing ). 



> 
 
> 
> 
> then I can use , , etc.



Costin

> Which means that the default value for the 'usens' attribute is "" which
> assumes some implicit namespace definitions like:
> 
> xmlns="ant-namespace" and probably xmlns:ant="ant-namespace"
> 
> which uses as kosher namespaces as possible, I think.
> 
> Jose Alberto

DO NOT REPLY [Bug 19737] New: - does not load updated file in same target

[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=19737

 does not load updated file in same target

   Summary:  does not load updated file in same
target
   Product: Ant
   Version: 1.5.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


 does not load the current file that was changed within the 
same target (or even the same run when the file is changed in another target 
that occurs in the "depends=" parameter of the target.

example: a target updates the build.number file with the  task. 
tha  task then reads this properties file. the resulting value 
of the build.number property is the value before  was called:

---












---

Re: Roles (was: antlib)

[Costin Manolache]

peter reilly wrote:

> I would agree with XML namespace usage like this.
> There are however some major and minor consequences
>  - in no particular order.
> 
> 1) the code to handle XML namespaces in ProjectHelper2 is
> not yet complete.
>   -  namespaces of attributes is not handled yet - the
>  code uses getQName() on the attributes and does
>  not pass the URI of the attributes to the attribute list given
>  to

Easy to fix it to localname, but I don't want to get into ns + attributes,
let's leave it for ant1.7 :-)
( or at least wait for the component creation to be done ).

Attribute + NS affects the introspection.

>   - the uris for project/target elements/attributes are not checked.

Project and target are "owned" by ant, you can't redefine them in antlibs.


>   - the ns standard allows different types of software processing
> for the different namespaces, if this is to be supported
> ProjectHelper2 would need to look at the uri before handing the
> element to the "ElementHandler" object (see my previous e-mail
> on the subject)

Not sure I agree ( or understand ) this.

What's missing is UnknownElement ( which actually creates the component )
passing the NS to ComponentHelper. Instead it calls the old
Project.createTask, etc.
That's easy to fix.

ProjectHelper2 doesn't care about namespaces or element names ( except
project/target ) - it just passes them to UnknownElement.



> 2) The usage of Project#createTask/DataType(name) will not work for
> tasks loaded as a result of XML namespaces, a
> Project#createTask/DataType( uri, name) method will need to be added.

+1

The real problem here is changing the code that _calls_ createTask(name) to
use the 2 param. That would make the code specific to ant1.6
An alternative would be to also change createTask( String ) to look for a
":" in the name, and if found to separate the last part as name, the first
part as URI. 

For most current uses ( createTask with core tasks ) things will continue to 
work since ant has the default namespace. 



> 3) In what ns will the introspected attributes and nested elements of the
> new
> elements reside? Some of the previous e-mails assume that they belong
> in the antlib's namespace - but what about datatypes that extend ant's
> datatypes - e.g mypath. (This is assuming that the attributes/nested
> elements are found by introspection - for jmx:... this may not be the
> case - or a different Class than IntrospectionHelper may be used).

Those created by IntrospectionUtil - it doesn't matter, it's set by the
introspection rules. For the new polymorphic tasks - probably the same
rules of component creation as in top-level tasks. ( still not sure if we 
agreed on how many lookup tables we'll use )


> 4) the proposed polymorphic element type substitution
>  will need to be made ns-aware. either
>  or the ns prefix -> ns uri mapping at
> the parse time when processing type="newtype" will need to be
> maintained.

Probably using the prefix in newtype would be the most intuitive (  ), but that will require some tricky change in PH2
to implement. 

It is easier to do , but that's ugly.

I don't think this is a showstopper.


> 5) Use of the ns form  6) The current usage of  will still
> be maintained.  One of the ideas floating about in discussion for
> antlib is that one can have  adaptor=.."/>. To allow third party add-ons to do this without using
> ns or antlibs, one would need to load the xml definition file with
> for example 
> or  or provide a new
> task to process the definition file/resource.

It needs to be maintained at least for backward compat. And one proposal is
to use  elements in the antlib descriptor.

Having the adaptor attribute would be great !

> To support this I would propose the following:
> 
> 1: define the xml format of the definition file.
> I would propose a root element of "antdef" and nested elements of
> "typedef" and "taskdef" and a possible "description" nested element
> and/or attribute.

Or "antlib" as root element ?

I'm pretty sure sooner or later we'll have some "conditions" or 
"echo" or even paths :-)

And also "dependencies" in one form or another.

But for start  should be enough.
I wouldn't use  - just a typedef and the fact that implements Task
or has an adapter that implements task 


> 2: either extend the  task to use the definition file in the
> same way as property files are deal with at the moment or provide
> a task -  and nested elements from typedef/>

Again -  :-)
 
> 3: release/document the  task to manipulate the classpath.

Sorry - tomcat took much more than I expected last weekend. 


> 4: Implement the XML ns changes to use the xml definition file possibly
>using a predefined filename and using a package name.

Not sure I understand - which part are you talking about ?

Costin


> 
> Peter
> 
> On

DO NOT REPLY [Bug 19734] - to support wildcards

[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=19734

 to support wildcards





--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 14:53 ---
Are you aware of the  task?

DO NOT REPLY [Bug 19730] - only works once

[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=19730

 only works once

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 14:52 ---
This is by design.  All properties in Ant are immutable, no matter which task
you've used to set them.

DO NOT REPLY [Bug 19727] - does not find file

[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=19727

 does not find file

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 14:50 ---
You are absolutely right,  should
not only be equivalent to , it actually is.

Look into your example in this report, you don't use the file attribute of
property, but its resource attribute.

DO NOT REPLY [Bug 19727] - does not find file

[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=19727

 does not find file

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 14:37 ---
but the documentation of (ant 1.5.3)  (that works) says:

"This is equivalent to  except that it supports nested 
 elements and it cannot be specified outside a target."

so,  should be the exact same es 
 ... shouldn't it?

Re: Roles (was: antlib)

[Costin Manolache]

Stefan Bodewig wrote:

> On Tue, 06 May 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
>> Jose Alberto Fernandez wrote:
>> 
>>> The important point is for the user (which is the one who has to
>>> deal with name clashes) to have control of the final naming scheme
>>> used in his/her buildfile.
>>
>> Let's not reinvent the wheel here.
>> 
>> The solution for names conflicts is namespaces - not rewriting.
> 
> +1 to both.  Make the use choose the namespace for the antlib he/she
> wants to use.

If you're reffering to the prefix - of course, that's how NS works.

The URI however should be chosen by the antlib author ( maybe based on some
rules specific to ant ), and should serve as an ID of the library.

My proposal is to use the (main) package name. There are other options - 
but I don't think every end user using it's own name for an antlib is a good
one. 

Costin

DO NOT REPLY [Bug 19734] New: - to support wildcards

[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=19734

 to support wildcards

   Summary:  to support wildcards
   Product: Ant
   Version: 1.5.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


My problem is to replace the build number in a Java source file. So I don't 
know the exact string to replace. I would like to have something like



which would replace the old build number string(s) no matter what value it has.

DO NOT REPLY [Bug 19730] New: - only works once

[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=19730

 only works once

   Summary:  only works once
   Product: Ant
   Version: 1.5.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I wrote a target that is intended to do the following thing:
1. read build number from build.number file and save to property
2. increase build number in build.number file
3. read new build number from build.number file and save to another property
4. take the two build numbers to replace the build number string in a 
Version.java file

--- ant target:













---

but the debug echo output is:

---
increase build.number:
[echo] Old bn=BUILD_NUMBER = 10 new bn=BUILD_NUMBER = 10
---

and shows the old build.number value (in this example 10). It seems that the 
second call of  doesn't work because the property build.number 
has still the old value after second call of .

DO NOT REPLY [Bug 14849] - JProbe tasks: executables cannot be found with JProbe 4.0.1

[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=14849

JProbe tasks: executables cannot be found with JProbe 4.0.1

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 14:12 ---
OK, all JProbe tasks work with JProbe 4.0.2 now.

Thanks, Jan

DO NOT REPLY [Bug 19727] - does not find file

[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=19727

 does not find file

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 14:04 ---
Don't use resource when you are looking for a file, there is a difference 
between
those attributes (resources searches in your CLASSPATH).  Please see the manual
of the property task for more details.

BTW, there is no reason to use ${file.separator}, Ant will get it right
automatically, no matter whether you use / or \.

DO NOT REPLY [Bug 19727] New: - does not find file

[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=19727

 does not find file

   Summary:  does not find file
   Product: Ant
   Version: 1.5.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I try to read the build number from the properties file build.number via the 
 task:

---



---

but the task does not find the file even though it is there (triple checked 
file name and directory path name):

---
increase build.number:
[property] Unable to find resource D:\data\prjs\amc\prg\java\build.number
[echo] Build number= ${build.number}
---

Re: modify classpath for a following compile ..

[Harsha Kalidindi]

Jesse:
 can use a reference to a  defined elsewhere in the
project.
In  you can build a org.apache.tools.ant.types.Path object and
then add it to the project with Project.addReference(). Then your
 target can use the reference.
Thanks. Works nicely.
Regards,
Harsha
This communication is intended for the addressee(s) and may contain 
confidential and legally privileged information. We do not waive 
confidentiality or privilege by mis-transmission. If you have received this 
communication in error, any use, dissemination, printing or copying is 
strictly prohibited; please destroy all electronic and paper copies and 
notify the sender immediately.

RE: Roles (was: antlib)

[Wannheden, Knut]

> > > 
> > > Let's not reinvent the wheel here.
> > > 
> > > The solution for names conflicts is namespaces - not rewriting. 
> > > 
> > 
> > I agree.  With the new ProjectHelper2 everything should be in 
> > place to start
> > using namespaces.
> > 
> 
> I have no problem on allowing people to use namespaces, but I do 
> have a problem on forcing people to use them just because some others
> want to use some fancy XML tool. The buildfile belongs to the
> user and s/he should be in charge.
> 

As someone already said, it's about "not reinventing the wheel", not about
enabling the use of fancy tools.  But as ubiquitous and accepted as XML
namespaces are, I see many things that could be gained from using
namespaces.  Also, I suspect most users familiar with XML will have had some
dose of contact with namespaces.

> > This would also allow antlibs to have a DTD or XML Schema 
> > which could be
> > used in XML editors or for validation.
> > 
> 
> Well ANT's XML is the result of introspection, and we already know
> our object model cannot be represented by a simple DTD. I see no way
> or reson to enforce 3rd party libraries to define their objects
> to be DTD-able. 
> I am not sure about XMLSchema but my hopes are not too high.
> 

With roles I think XML Schema could very well be used to validate a
buildfile.  But I'm not saying that a schema should be enforce.  It would be
a gain of using XML namespaces.

> > Also namespaces lets the antlib user specify what prefix to 
> > use.  But it
> > doesn't allow two antlibs to use the same prefix in the 
> > context of the same
> > element, which I think is good.
> > 
> 
> This sounds proper in theory, but in practice lets see:
> 
>  1) Lets assume that we still want to be able to chop ANT jars
> between core and different optional jars which have specific
> dependencies of diferent packages and such.
> 
>  2) Now because they are in different antlibs it would mean I am
> forced to use different namespaces for each.
> 

Is that really so?  As I understood it antlibs wouldn't be a requirement for
providing Ant tasks and types.  I thought the normal  and
 would still work as they do now.

I suppose it would also be possible to let one antlib extend another one,
thus letting it use the same namespace.

>  3) So now you have people using 3rd party tasks like antcontrib
> without problem and without conflicts, but they would have to
> change not just one line (to use the antlib) but every bloddy
> use of the tasks just because they are forced to use name spaces.
> 

To use antcontrib as an antlib they would at the very least have to replace
the s with an  element or something, no?  But the tasks
should still work as they do now using .

> > If you really want you can use short names with namespaces as 
> > well.  Just
> > set the default namespace locally.
> > 
> 
> I have no problem using XML namespaces as long as they are independent
> of the antlib and under complete user control (not antlib 
> designer control).
> In other words the user should be able to decide if s/he wants to load
> the library on some particular namespace or in the default "" 
> namespace
> which is the one used by core.
> 
> So if I say:
> 
>   
> 
> I will be able to use: , , etc. But is I do:
> 
>   
>  
> 
>   
> 
> then I can use , , etc.
> 

I think the  shouldn't define the prefix, but the namespace URI
instead .  Something like:


   
 


Of course if the antlib would provide its own namespace in the descriptor.
Ant could do some kind of automatic loading when a namespace declaration
matching the namespace URI is encountered.  But I'm not sure that's a good
idea.

> Which means that the default value for the 'usens' attribute 
> is "" which assumes
> some implicit namespace definitions like:
> 
>   xmlns="ant-namespace" and probably xmlns:ant="ant-namespace"
> 
> which uses as kosher namespaces as possible, I think.
> 

But this would require that the  element would define the default
namespace like this:


...


Why not use the empty namespace for Ant core?

--
knut

Re: [GUMP] Test Failure - Ant

[Stefan Bodewig]

The CVS tasks failed because cvs exited with 1.  A temporary network
problem, I'd guess.

Stefan

[GUMP] Test Failure - Ant

[Diane Holt]

This email is autogenerated from the output from:



Build results exceed maximum length.
Please see URL above for details.
Last 50 lines of build output follows.


[junit] Testsuite: org.apache.tools.ant.CaseTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.049 sec

[junit] Testsuite: org.apache.tools.ant.ImmutableTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.106 sec

[junit] Testsuite: org.apache.tools.ant.IncludeTest
[junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0.323 sec

[junit] Testsuite: org.apache.tools.ant.IntrospectionHelperTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.019 sec

[junit] Testsuite: org.apache.tools.ant.LoaderRefTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.755 sec

[junit] Testsuite: org.apache.tools.ant.ProjectTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.114 sec

[junit] Testsuite: org.apache.tools.ant.PropertyExpansionTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.021 sec

[junit] Testsuite: org.apache.tools.ant.TopLevelTaskTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.157 sec

[junit] Testsuite: org.apache.tools.ant.TaskContainerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.58 sec

[junit] Testsuite: org.apache.tools.zip.AsiExtraFieldTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.016 sec

[junit] Testsuite: org.apache.tools.zip.ExtraFieldUtilsTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.029 sec

[junit] Testsuite: org.apache.tools.zip.ZipEntryTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.027 sec

[junit] Testsuite: org.apache.tools.zip.ZipLongTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.004 sec

[junit] Testsuite: org.apache.tools.zip.ZipShortTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.004 sec

[junit] Testsuite: org.apache.tools.tar.TarEntryTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.01 sec


BUILD FAILED
/home/rubys/jakarta/ant/build.xml:1585: At least one test has failed.

Total time: 8 minutes 2 seconds

RE: Roles (was: antlib)

[Jose Alberto Fernandez]

> From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
> 
> > 
> > Let's not reinvent the wheel here.
> > 
> > The solution for names conflicts is namespaces - not rewriting. 
> > 
> 
> I agree.  With the new ProjectHelper2 everything should be in 
> place to start
> using namespaces.
> 

I have no problem on allowing people to use namespaces, but I do 
have a problem on forcing people to use them just because some others
want to use some fancy XML tool. The buildfile belongs to the
user and s/he should be in charge.

> This would also allow antlibs to have a DTD or XML Schema 
> which could be
> used in XML editors or for validation.
> 

Well ANT's XML is the result of introspection, and we already know
our object model cannot be represented by a simple DTD. I see no way
or reson to enforce 3rd party libraries to define their objects
to be DTD-able. 
I am not sure about XMLSchema but my hopes are not too high.

> Also namespaces lets the antlib user specify what prefix to 
> use.  But it
> doesn't allow two antlibs to use the same prefix in the 
> context of the same
> element, which I think is good.
> 

This sounds proper in theory, but in practice lets see:

 1) Lets assume that we still want to be able to chop ANT jars
between core and different optional jars which have specific
dependencies of diferent packages and such.

 2) Now because they are in different antlibs it would mean I am
forced to use different namespaces for each.

 3) So now you have people using 3rd party tasks like antcontrib
without problem and without conflicts, but they would have to
change not just one line (to use the antlib) but every bloddy
use of the tasks just because they are forced to use name spaces.

I doubt many people will be fill happy about that, and the backward
compatibility consequences.

> If you really want you can use short names with namespaces as 
> well.  Just
> set the default namespace locally.
> 

I have no problem using XML namespaces as long as they are independent
of the antlib and under complete user control (not antlib designer control).
In other words the user should be able to decide if s/he wants to load
the library on some particular namespace or in the default "" namespace
which is the one used by core.

So if I say:



I will be able to use: , , etc. But is I do:


   



then I can use , , etc.

Which means that the default value for the 'usens' attribute is "" which assumes
some implicit namespace definitions like:

xmlns="ant-namespace" and probably xmlns:ant="ant-namespace"

which uses as kosher namespaces as possible, I think.

Jose Alberto

Re: Roles (was: antlib)

[peter reilly]

I would agree with XML namespace usage like this.
There are however some major and minor consequences
 - in no particular order.

1) the code to handle XML namespaces in ProjectHelper2 is
not yet complete.
  -  namespaces of attributes is not handled yet - the
 code uses getQName() on the attributes and does
 not pass the URI of the attributes to the attribute list given
 to
  - the uris for project/target elements/attributes are not checked.
  - the ns standard allows different types of software processing
for the different namespaces, if this is to be supported
ProjectHelper2 would need to look at the uri before handing the
element to the "ElementHandler" object (see my previous e-mail
on the subject)

2) The usage of Project#createTask/DataType(name) will not work for
tasks loaded as a result of XML namespaces, a Project#createTask/DataType(
uri, name) method will need to be added.

3) In what ns will the introspected attributes and nested elements of the new
elements reside? Some of the previous e-mails assume that they belong
in the antlib's namespace - but what about datatypes that extend ant's
datatypes - e.g mypath. (This is assuming that the attributes/nested
elements are found by introspection - for jmx:... this may not be the
case - or a different Class than IntrospectionHelper may be used).

4) the proposed polymorphic element type substitution
 will need to be made ns-aware. either
 or the ns prefix -> ns uri mapping at
the parse time when processing type="newtype" will need to be maintained.

5) Use of the ns form  will still
be maintained.  One of the ideas floating about in discussion for
antlib is that one can have . To allow third party add-ons to do this without using
ns or antlibs, one would need to load the xml definition file with
for example 
or  or provide a new
task to process the definition file/resource.

To support this I would propose the following:

1: define the xml format of the definition file.
I would propose a root element of "antdef" and nested elements of
"typedef" and "taskdef" and a possible "description" nested element
and/or attribute.

2: either extend the  task to use the definition file in the
same way as property files are deal with at the moment or provide
a task - 

3: release/document the  task to manipulate the classpath.

4: Implement the XML ns changes to use the xml definition file possibly
   using a predefined filename and using a package name.

Peter

On Wednesday 07 May 2003 06:14, Costin Manolache wrote:
> Let's not reinvent the wheel here.
>
> The solution for names conflicts is namespaces - not rewriting.
>
> If we use a prefix, let's stick with what everyone else is using. Inventing
> some "original" solution ( that may or may not be easier or more flexible
> than the W3C solution ) won't make things better for the user.
>
> 
>   
>
> is not easier than
>
> 
>   
>
>
>
> Costin
>
> Jose Alberto Fernandez wrote:
> > Hi guys,
> >
> > I was away on vacation so hasn't been around to make comments about the
> > entire discussion. I will try to sumarize here some comments that go
> > across several messages I have read today.
> >
> > The current  provides a way for the user of a particular antlib
> > to rename one or more elements that are in conflict with elements of some
> > other antlib it tries to use. As the renaming is local to the project
> > there is no problem; it is up to the user of the antlib to decide what
> > names to use to refer to the loaded things. For example I may use the
> >  class of antcontrib but for reasons of my project being in need
> > to also use a  defined by some other third party which works
> > diferently. So I could just load it and rename it lets say to 
> > and use it in my project using that name.
> >  It is up to me as the user of the antlib.
> >
> > From the discussion this last few days I like the idea from (I think)
> > Peter/Nicola of having short and long names where the long names are form
> > by adding a prefix defined not by the antlib writer, but by the antlib
> > user:
> >
> > 
> >
> > which would allowme to use either:
> >
> >  or 
> >
> > it is upto the user to decide what to use. Of course the same would be
> > for the tasks (i.e., ) that allows loading individual tasks into
> > roles. The same rules of collisions and conflict resolution apply.
> >
> > The important point is for the user (which is the one who has to
> > deal with name clashes) to have control of the final naming scheme used
> > in his/her buildfile. And we are not impossing any wierd semantics or
> > making assumptions, if I decide to use the same prefix for two antlibs it
> > is up to me to make sure there are no conflicts.
> >
> >> -Original Message-
> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >> Sent: 02 May 2003 14:35
> >> To: [EMAIL PROTECTED]
> >> Subject: Re:

RE: Roles (was: antlib)

[Wannheden, Knut]

> 
> Let's not reinvent the wheel here.
> 
> The solution for names conflicts is namespaces - not rewriting. 
> 

I agree.  With the new ProjectHelper2 everything should be in place to start
using namespaces.

This would also allow antlibs to have a DTD or XML Schema which could be
used in XML editors or for validation.

Also namespaces lets the antlib user specify what prefix to use.  But it
doesn't allow two antlibs to use the same prefix in the context of the same
element, which I think is good.

If you really want you can use short names with namespaces as well.  Just
set the default namespace locally.

--
knut

Re: Roles (was: antlib)

[Stefan Bodewig]

On Tue, 06 May 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> Jose Alberto Fernandez wrote:
> 
>> The important point is for the user (which is the one who has to
>> deal with name clashes) to have control of the final naming scheme
>> used in his/her buildfile.
>
> Let's not reinvent the wheel here.
> 
> The solution for names conflicts is namespaces - not rewriting. 

+1 to both.  Make the use choose the namespace for the antlib he/she
wants to use.

Stefan

AW: AW: command line option visibility within a task ..

[Jan . Materne]

If you want more specific:  supports multiple loglevel.
- LogLevel defined with nested class extending EnumeratedAttribute
  => Ant will enforce that only valid values are set
- setLevel(LogLevel) uses cascading if-statements for evaluating
  the value
  if ("debug".equals(loglevel.getValue())) ...


Jan

> -Ursprüngliche Nachricht-
> Von: Harsha Kalidindi [mailto:[EMAIL PROTECTED]
> Gesendet am: Dienstag, 6. Mai 2003 19:13
> An: Ant Developers List; Ant Developers List
> Betreff: Re: AW: command line option visibility within a task ..
> 
> Peter:
> 
>  Thanks for the example.
> 
>  I was thinking of an attribute called debug for my 
> tasks but I 
> think I will use verbose to keep it consistent ..
> 
> Regards,
> Harsha
> 
> 
> 
> >The normal way is get debug output is to
> >use log(..., Project.MSG_VERBOSE);
> >
> >And then use -debug at the command line.
> >
> >This however results in a lot of debug output
> >
> >So some tasks have a verbose attribute - like for 
> >
> >
> >ant -Ddelete.verbose="yes" ...
> >
> >Check the source (ant.apache.tools.ant.taskdefs.Delete) for 
> example code.
> >Peter
> >
> >On Tuesday 06 May 2003 17:52, Harsha Kalidindi wrote:
> > > Jan,Peter:
> > >
> > >  Thanks for fixing the email address.
> > >
> > > >Main.main() -> Main.start() -> Main.Main() and none of 
> these methods
> > > >store the arguments. So you can´t access them.
> > > >You can modify this class (should be very easy ...). But 
> then you have a
> > > >customized version of an Ant base class.
> > >
> > >  I definitely don't want to customize a base Ant class ..
> > >
> > >  I'll have to think about this ..
> > >
> > > Regards,
> > > Harsha
> > >
> > > > > -Ursprüngliche Nachricht-
> > > > > Von: Harsha Kalidindi 
> [mailto:[EMAIL PROTECTED]
> > > > > Gesendet am: Dienstag, 6. Mai 2003 18:11
> > > > > An: [EMAIL PROTECTED]
> > > > > Betreff: command line option visibility within a task ..
> > > > >
> > > > > Hi:
> > > > >
> > > > >  I am trying to write a few tasks to extend ant in
> > > > > our environment.
> > > > >
> > > > >  I would like these tasks to emit some debug
> > > > > information depending
> > > > > on the command line options used with the ant invocation.
> > > > >
> > > > >  Is there a way I can get a list of command line
> > > > > options that ant
> > > > > was invoked with?
> > > > >
> > > > > Thanks,
> > > > > Harsha
> > > > >
> > > > > [EMAIL PROTECTED] 212.762.4165
> > > > >
> > > > > This communication is intended for the addressee(s) 
> and may contain
> > > > > confidential and legally privileged information. We 
> do not waive
> > > > > confidentiality or privilege by mis-transmission. If you have
> > > > > received this
> > > > > communication in error, any use, dissemination, printing or
> > > > > copying is
> > > > > strictly prohibited; please destroy all electronic and paper
> > > > > copies and
> > > > > notify the sender immediately.
> > >
> > > [EMAIL PROTECTED] 212.762.4165
> > >
> > > This communication is intended for the addressee(s) and 
> may contain
> > > confidential and legally privileged information. We do not waive
> > > confidentiality or privilege by mis-transmission. If you 
> have received this
> > > communication in error, any use, dissemination, printing 
> or copying is
> > > strictly prohibited; please destroy all electronic and 
> paper copies and
> > > notify the sender immediately.
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> 
> [EMAIL PROTECTED] 212.762.4165
> 
> This communication is intended for the addressee(s) and may contain 
> confidential and legally privileged information. We do not waive 
> confidentiality or privilege by mis-transmission. If you have 
> received this 
> communication in error, any use, dissemination, printing or 
> copying is 
> strictly prohibited; please destroy all electronic and paper 
> copies and 
> notify the sender immediately.
> 

Re: Roles (was: antlib)

[Conor MacNeill]

On Wed, 7 May 2003 03:14 pm, Costin Manolache wrote:
> Let's not reinvent the wheel here.
>
> The solution for names conflicts is namespaces - not rewriting.
>

+1

Conor

RE: Roles (was: antlib)

[Costin Manolache]

Let's not reinvent the wheel here.

The solution for names conflicts is namespaces - not rewriting. 

If we use a prefix, let's stick with what everyone else is using. Inventing
some "original" solution ( that may or may not be easier or more flexible 
than the W3C solution ) won't make things better for the user. 


  

is not easier than 


  



Costin


Jose Alberto Fernandez wrote:

> Hi guys,
> 
> I was away on vacation so hasn't been around to make comments about the
> entire discussion. I will try to sumarize here some comments that go
> across several messages I have read today.
> 
> The current  provides a way for the user of a particular antlib to
> rename one or more elements that are in conflict with elements of some
> other antlib it tries to use. As the renaming is local to the project
> there is no problem; it is up to the user of the antlib to decide what
> names to use to refer to the loaded things. For example I may use the
>  class of antcontrib but for reasons of my project being in need
> to also use a  defined by some other third party which works
> diferently. So I could just load it and rename it lets say to  and
> use it in my project using that name.
>  It is up to me as the user of the antlib.
> 
> From the discussion this last few days I like the idea from (I think)
> Peter/Nicola of having short and long names where the long names are form
> by adding a prefix defined not by the antlib writer, but by the antlib
> user:
> 
> 
> 
> which would allowme to use either:
> 
>  or 
> 
> it is upto the user to decide what to use. Of course the same would be for
> the tasks (i.e., ) that allows loading individual tasks into
> roles. The same rules of collisions and conflict resolution apply.
> 
> The important point is for the user (which is the one who has to
> deal with name clashes) to have control of the final naming scheme used in
> his/her buildfile. And we are not impossing any wierd semantics or making
> assumptions, if I decide to use the same prefix for two antlibs it is up
> to me to make sure there are no conflicts.
> 
> 
> 
>> -Original Message-
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>> Sent: 02 May 2003 14:35
>> To: [EMAIL PROTECTED]
>> Subject: Re: Roles (was: antlib)
>> 
>> 
>> On Wed, 30 Apr 2003, Jose Alberto Fernandez
>> <[EMAIL PROTECTED]> wrote:
>> 
>> > The problem you are overlooking is the case of  element
>> > in , , , etc.
>> 
>> Maybe not really overlooking but understimating.
>> 
>> The alternative would be to use  and 
>> for the different interfaces.  If they come from different antlibs, we
>> really should use XML namespaces to resolve this.
>> 
>> But I now understand that having a table per interface may be
>> convenient (though not strictly necessary).
>> 
>> Stefan
>> 
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> 
>>

DO NOT REPLY [Bug 19714] New: - Nested element ("weblogic") of the "serverdeploy" task should support WebLogic Server 7

[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=19714

Nested element ("weblogic") of the "serverdeploy" task should support WebLogic 
Server 7

   Summary: Nested element ("weblogic") of the "serverdeploy" task
should support WebLogic Server 7
   Product: Ant
   Version: 1.6Alpha (nightly)
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


WebLogic Server 6 uses the command: "java weblogic.deploy" to deploy an 
application. But the WebLogic Server 7 uses the command: "java 
weblogic.Deployer" (view http://e-
docs.bea.com/wls/docs70/programming/deploying.html#1124819). 

 The current task uses WebLogic Server 6 "weblogic.deploy" utility to deploy an 
application. It should be upgraded to detect and support WebLogic Server 7

DO NOT REPLY [Bug 19712] - Add a task for SQLJ compilation

[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=19712

Add a task for SQLJ compilation





--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 00:25 ---
Created an attachment (id=6247)
Documentation for the code

DO NOT REPLY [Bug 19712] - Add a task for SQLJ compilation

[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=19712

Add a task for SQLJ compilation





--- Additional Comments From [EMAIL PROTECTED]  2003-05-07 00:25 ---
Created an attachment (id=6246)
Source for the enhancement

DO NOT REPLY [Bug 19712] New: - Add a task for SQLJ compilation

[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=19712

Add a task for SQLJ compilation

   Summary: Add a task for SQLJ compilation
   Product: Ant
   Version: 1.6Alpha (nightly)
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


A new optional task should be added to support SQLJ compilation.  This will 
simplify compilation of SQLJ which requires complicated dependency checks in 
the absence of a dedicated task.

I have the necessary code and documentation.  It has been posted to the dev 
list and I will attempt to add it to this entry.