DO NOT REPLY [Bug 19777] - nested fileset's for ant 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=19777

nested fileset's for ant task





--- Additional Comments From [EMAIL PROTECTED]  2003-05-08 20:08 ---
Ant 1.6 will have a task called 'subant' that can invoke a target in multiple
sub directories.

Pull the source from CVS, or get a nightly build to check it out.

Jesse

DO NOT REPLY [Bug 19777] New: - nested fileset's for ant 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=19777

nested fileset's for ant task

   Summary: nested fileset's for ant task
   Product: Ant
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


the  task should allow nested fileset's.

DO NOT REPLY [Bug 19774] New: - XMLJUnitResultFormatter should save time when a test was run

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

XMLJUnitResultFormatter should save time when a test was run

   Summary: XMLJUnitResultFormatter should save time when a test was
run
   Product: Ant
   Version: 1.5.1
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It would be nice if XMLJUnitResultFormatter would save the date/time when the 
test (or suite) was run.  Presumably, it would be stored as an attribute of the 
 element.  With this information I could write an XSL file so along 
with the other test stats, I could display when the test was run.

Similarly, the total TestCase time could be stored in the XML (a new element or 
an attribute to ).

Re: Roles (was: antlib)

[J.Pietschmann]

Jose Alberto Fernandez wrote:
Is there a DTD for XSLT? Can I validate an XSLT template against a DTD?
Not in general. This is a restriction of DTDs, which can't cope with
XML namespaces. DTDs are a SGML heritage and predate XML namespaces.
You can always construct a DTD which a certain class of (useful)
XSL style sheets validates against.
You can partially validate arbitrary style sheets against an XSD or
a RNG schema.
I thought that was not possible given that most of the elements in the 
template wil be the things I am trying to generate. In the case of XSLT
the the URI is really for the XSLT processor, but not XML as such.
Well, the p and div element names are for the browser (HTML renderer,
to be more precise), not for (X)HTML as such. After all, any XML
document is most useful if it is ultimately processed by some software,
which necessarily has to have some knowledge on how to handle the
information embedded in the pointy brackets.
Java packages are global. NS spaces are hyerarchical I can change the 
meaning of "ANT:" twenty times inside the same buildfile depending
on where I make the xmlns declaration.
You confuse the namespace, which is fix and (hopefully) unique
which the qname prefix. Don't do this. Read the spec or a good
book about this topic.
actually I think it is quite complicated in general.
The XML namespace syntax is a compromise between providing unique
long names to the processor and reasonably short names to human
readers. Yes, you can use this to obfuscate XML documents. You
don't *have* to obfuscate XML documents though.
Many people complained about the potential problems ill written
but valid XML documents can pose to unexperienced users as well as
for q&d hackers (for example, you can't use simple perl regex
matching to grab some tuff from the middle of a big XML document,
you'll have to parse the whole doc in order resolve prefixes to
namespaces). Interestingly, when namespaces were introduced to C++
there weren't much bitch&moan, while it posed exactly the same
problems.
J.Pietschmann

Re: Roles (was: antlib)

[J.Pietschmann]

peter reilly wrote:
The NS standard http://www.w3.org/TR/REC-xml-names/
allows one to do somthing like this:

   
   message


of course it is up to the ant software to understand the xml file,
but "unsupported attribute 'class'" is not a usefull error message
in this case.
I would make elements from namespaces without associated code
in certain positions legal (silently ignored by Ant) or a warning
level problem. Same for attributes from namespace which is not the
default namespace nor the namespace of the element. This allows
buildfile editors to put stuff for other tools into the buildfile
in a structured way. This is used for example in XSLT, which allows
elements  from non-default, non-xslt namespaces as immediate children
of xsl:stylesheet, for various purposes, the most oviously
useful is extended documentation:
 http://www.w3.org/1999/Transform";
xmlns:doc="http://nwalsh.com/xsldoc";
xmlns:xhtml="http://www.w3.org/...";>
   A sample stylesheet
   
 The template matching 
   is used for...
 
  
  
   ...
Attributes could also provide interesting use cases:
  
J.Pietschmann

DO NOT REPLY [Bug 19768] New: - request for "daemon" attribute for 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=19768

request for "daemon" attribute for  task

   Summary: request for "daemon" attribute for  task
   Product: Ant
   Version: 1.6Alpha (nightly)
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi,

I want to suggest to add a feature daemon with boolean value to the  task,
to enable  to start services based on java with a  task call.

Currently if i start e.g. the tomcat server with a forked jvm, ant waits until
the server has shut down again.

So the task should look like:
-
   
   
   
   
   
   
   

-
as far as i understand ant, fork="yes" should be present for the daemon task to 
work.

Iff this would work, java driven services could get rid of os specific startup 
scripts, making the setup and maintaining even easier. A (minor) drawback would 
be, that ant will then be a prerequisite for running.

see http://archives.apache.org/eyebrowse/[EMAIL PROTECTED]
org&msgNo=30487
and (with example script)
http://archives.apache.org/eyebrowse/[EMAIL PROTECTED]
org&msgNo=30476

Re: Roles (was: antlib)

[peter reilly]

On Wednesday 07 May 2003 20:40, J.Pietschmann wrote:
> 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
>  healthhazard:class="toxic"/>
> (or shorter:  h:class="toxic"/> )
> 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.

I realize this. My point is that the java code dealing with the attributes
should be correct.

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

This is one way to do it. However ComponentHelper will most likely need
need to have a map for each uri. - as multi build files are processed. (ant,
antcall, subant and import ).

Peter

Re: Roles (was: antlib)

[peter reilly]

Thanks for the detailed reply.
I will reply in-line.
However, I think that I did not make my main point
clear in my original e-mail. So I will detail it
first.

Currently 3rd party add-ons to ant are done using
 and/or . These can either define
the tasks or types in-line or by using property files (
as a file or a resource).

Using property files is nice but with new attributes
to typedef (adaptor for example) it would be better to
use an xml file/resource.

This should be independent of using antlibs/jars or XML ns.
Hence I think that the root element name should not be
"antlib" as this implies more baggage.
(Also my work in progress implementation uses an ant task
for the xml parsing and the root element name is the task
name ;-)).

On Wednesday 07 May 2003 15:56, Costin Manolache wrote:
> 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 ).

The NS standard http://www.w3.org/TR/REC-xml-names/
allows one to do somthing like this:


   
   message



of course it is up to the ant software to understand the xml file,
but "unsupported attribute 'class'" is not a usefull error message
in this case.

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

This is true, but using namespaces one could do:

   
   hello world



which is clearly wrong - but with the current code gives the
misleading error:
"Could not create task or type of type: target"
>
> >   - 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.
The idea is to allow a xml ns to be used for purposes other that defining
Unknown Elements. My example was an antdoc xml ns.
>
> 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
It does matter from a build script point of view.



http://"; retry="no"/>


is different from:



http://"; retry="no"/>


> 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 (  type="antcontrib:if" /> ), but that will require some tricky change in PH2
> to implement.
Actually I think change is easy enough. :-)
>
> It is easier to do , but that's ugly.
>
> I don't think this is a showstopper.
>

DO NOT REPLY [Bug 19765] New: - Compile tasks should not use ${user.dir} for temp files

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

Compile tasks should not use ${user.dir} for temp files

   Summary: Compile tasks should not use ${user.dir} for temp files
   Product: Ant
   Version: 1.5.3
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Various compile tasks create temp files in the current working directory (via 
the user.dir system property, see method org.apache.tools.ant.taskdefs.
compilers.DefaultCompilerAdapter.executeExternalCompile). There should be a way 
to define a different temp directory here (or use the java.io.tmpdir directory 
from Java 1.2 on). 




In a server installation with a bundled Ant, or in networked build 
environments, 
the current working directory may be read-only (eg, some /opt/... path).




The same is probably true for other tasks that use the org.apache.tools.ant.
taskdefs.FileUtils.createTempFile method with a null directory, like javadoc, 
cvstagdiff, and cab.

RE: Roles (was: antlib)

[Jose Alberto Fernandez]

> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> 
> Jose Alberto Fernandez wrote:
> 
> > 
> > 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.
> 
> And you instead propose to use something as complex - but different.
> 
> Your "rewriting task names to resolve conflicts" is in no way 
> better than
> "use namespace to resolve conflicts". User of ant will be far better
> learning the standard way to resolve conflicts than learning your 
> syntax and rewriting. 
> 

Contin please, I have not mentioned in the discussion about NS usage
that we should use renaming. I did mention that that is what the
 does today. (Which is the only thing it could do given the fact
that when it was written there was no NS support).

This discussion is about how we use NS, if we use it, and my position is
that there is no reason to force people on using specific NS's for each
library they load, and that it should be upto the user to decide which
set of libraries to load on which NS. If I waht to load everything in
the default library and there is no conflict I should be able to; if
I want to put everyone on a different NS, then I could do that too.
It should be upto the user.

> We do force people to use XML, and we force them to use a specific 
> DTD (  ... ) and semantics. Even Perl forces people to use 
> a certain syntax and rules. 
> 
> If you have a solution to the name conflict that is far 
> better than using
> the standard solution - then we can consider it. But renaming 
> task names is 
> certainly not.
> 
> 

I have not proposed renaming for a solution that uses NS, which I have
been willing to consider. In any case, with  there is no way
for you to stop me from renaming task, today. (not that I am advocating it).

> 
> > 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
> 
> Yes. In the first case you'll need to be very carefull to avoid naming
> conflicts, and you may not be able to benefit from some tools.
> 
> In the second - you'll force users to use NS - which is a 
> standard used in
> almost all XML specifications today. We already forced them 
> to learn XML
> in the first place, and learning NS won't be a waste of time.  
> 
> 

Doesn't anybody think that this is ugly? To have to maintain two different
mechanisms that produce two completely different ways of writing
buildfiles. When you can have a unified approach that cover the whole
spectrum. I was hopping that  will allow in the future to
declare things on a separate namespace, just as  would.

> 
> >> 
> >>  >> 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)
> 
> The namespace is _not_ under user control, at least according to W3C. 
> You can't just use whatever URI you want for XSLT or XHTML - 
> the URI of a specification/DTD is defined by that specification.
> 

Is there a DTD for XSLT? Can I validate an XSLT template against a DTD?
I thought that was not possible given that most of the elements in the 
template wil be the things I am trying to generate. In the case of XSLT
the the URI is really for the XSLT processor, but not XML as such.

> The equivalent of a namespace in a programming language is the 
> package. What you are suggesting is equivalent in letting users 
> pick whatever package they want for a java class, at runtime. 

Dynamically linked libraries exist in many programming languages
not only java, and how do you refer to them inside your code
whether you use some alias or something ingrane in the library
itself depends on how the linking process and library loader
system works for that language. Java does not have a monopoly on how to do this.

> 
> BTW, if we are still talking about java programmers using ant 
> - I doubt
> we'll have that many users who don't understand how package work and 
> have a big shock learning about XML namespaces.
>  

Java packages are global. NS spaces are hyerarchical I can change the 
meaning of "ANT:" twenty times inside the same buildfile depending
on where I make the xmlns declaration. I can have "A:" and "B:" mean
the same thing or different things in diferent parts of the
same file. It is not a simple concept, actually I think it is quite
complicated in general.

Jose Alberto

invoke another target/buildfile and continue even if the invoked target failed

[Mariano Benitez]

are there any plans to implement this.
it would be really cool to have this feature, we can use it for the long 
test runs when you are stacked when some module build fails, the entire 
build fails. Of course we have workarounded it, but it would greatly 
simplify long test builds.

All I'm asking is a haltonerror and errorproperty attributes for the 
 and  targets.

Regards,
Mariano

DO NOT REPLY [Bug 19762] - jspc task is always recompiling files even if they are up-to-date

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

jspc task is always recompiling files even if they are up-to-date





--- Additional Comments From [EMAIL PROTECTED]  2003-05-08 12:11 ---
Created an attachment (id=6269)
the patch files with JspC.java and Jasper41mangler.java

DO NOT REPLY [Bug 19762] New: - jspc task is always recompiling files even if they are up-to-date

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

jspc task is always recompiling files even if they are up-to-date

   Summary: jspc task is always recompiling files even if they are
up-to-date
   Product: Ant
   Version: 1.5.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


attached is a patch file that fixes it. there was a todo there :)

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|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-05-08 09:05 ---
We can this INVALID/REOPEN game for ages.  Please read the manual for 
buildnumber
and what Conor has written below "to the value that was read in".

The buildnumber task reads your old file and sets the build.number property to
the value found therein.  After that it increases the number in the file.

loadproperties read the file but doesn't reset the value of the property because
no task in Ant will do so.

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|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-05-08 08:52 ---
but the build.number is not set to the current value. here's a test case:











---

output is:

---
build.number++:
[echo] current bn=${build.number}
[echo] next bn=9
[echo] new bn=9
---

although the build.number file has a build.number property value of 10! i run 
this a dozen times and the output is always 1 lower than the value in the 
build.number file.

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

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-05-08 06:01 ---
If you don't have a 1.4 environment, then you can't use 1.4 features. Putting
1.4's classes into a 1.3 VM's classpath won't work. The solution for you is to
use ORO.

Re: Roles (was: antlib)

[Gus Heck]

Jose Alberto Fernandez wrote:
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.
 

 

I had never touched xml when I  first encountered Ant. But rather than 
saying: "Yuck, I have to learn XML", my reaction was rather, 
Excellent... I have been meaning to learn about XML anyway.

All this talk of namespaces gave me a good reason to go read up on them 
in case they do become part of ant. But if a custom solution is coded 
where can I go read up on it... where can I get a second book, or web 
info on it ifi the  manual doesn't seem adequate? If standards are used, 
then lots of information will be available to make sense of them.

I am in favor of using a standards based approach because it will save 
me work in the long run. Time spent learning namespaces is likely to be 
time well spent, useful elsewhere.  If I have to learn something I'd 
much rather learn something I might see again.

-Gus

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-08 03:56 ---
Your assumption is wrong.  sets the property.

http://ant.apache.org/manual/CoreTasks/buildnumber.html

"then set the property build.number to the value that was read in"

Re: Roles (was: antlib)

[Costin Manolache]

Conor MacNeill wrote:

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

Can you explain why you don't want a semantic structure ?

I don't understand why using a java package name - i.e. the base package of
the library - as ns is worse than using an arbitrary string.  

And I don't unserstand why not using the URI in a meaningfull way - to
locate the descriptor. 

If we use an arbitrary string - we'll still have to use a declaration to
associate it with a resource. 

Of course - using the URI as a file is bad, using it as a HTTP is not very
good either. But a java package name has all the characteristics that a
namespace name needs, and it's intuitive for java developers.


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

What would be the benefit ? 

IMO it would be more confusing. Even if we don't care about tools - having 
a namespace associated with a clear set of elements and tags is good for 
clarity. 


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

+1 - the default namespace is a special case. My problem is with
spaghetti-namespaces ( that change names or can be combined ). 


  

would become:
  
   
  



In the first case - 's namespace can be used to locate/load the lib.
In the second - an explicit load into the default namespace.


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

For advanced uses - ok.

For common use - I think using the main class loader and adding the antlibs
( and their dependencies ) to the main loader is far better.

By advanced use I mean the case where you want to use multiple versions 
of an antlib at the same time, or antlibs that have conflicting deps,
etc.

Costin

> 
> Just some thoughts
> Conor

RE: Roles (was: antlib)

[Costin Manolache]

Jose Alberto Fernandez wrote:


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

And you instead propose to use something as complex - but different.

Your "rewriting task names to resolve conflicts" is in no way better than
"use namespace to resolve conflicts". User of ant will be far better
learning the standard way to resolve conflicts than learning your 
syntax and rewriting. 

We do force people to use XML, and we force them to use a specific 
DTD (  ... ) and semantics. Even Perl forces people to use 
a certain syntax and rules. 

If you have a solution to the name conflict that is far better than using
the standard solution - then we can consider it. But renaming task names is 
certainly not.



> 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

Yes. In the first case you'll need to be very carefull to avoid naming
conflicts, and you may not be able to benefit from some tools.

In the second - you'll force users to use NS - which is a standard used in
almost all XML specifications today. We already forced them to learn XML
in the first place, and learning NS won't be a waste of time.  



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

The namespace is _not_ under user control, at least according to W3C. 
You can't just use whatever URI you want for XSLT or XHTML - 
the URI of a specification/DTD is defined by that specification.

The equivalent of a namespace in a programming language is the 
package. What you are suggesting is equivalent in letting users 
pick whatever package they want for a java class, at runtime. 

BTW, if we are still talking about java programmers using ant - I doubt
we'll have that many users who don't understand how package work and 
have a big shock learning about XML namespaces.
 
Costin