Hi Again after 9 years
Don't know if any1 remembers me but I contributed some tasks and fixes back in 2003-2004 (1.4 - 1.6 days) I'm thinking of writing a task to pack .crx files for chrome extensions. I have the following questions: 1. Is there interest for such a task to be contributed? It seems that there are no pure java options out there so this would be useful. 2. Are there any major changes in the way a task is written today vs 1.6. You don't need to tell me things that are on here: http://ant.apache.org/manual/develop.html . Rather, I am looking for advice about what may have changed in ant that I may trip over. What do folks think? -Gus -- http://www.the111shift.com
Re: macro and XML NS hell ;-)
=The value of property foo is baz /
/case
default
ant:echo message=The value of property foo is not sensible /
/default
/ac:switch
/project
However, in real use switch probably does more than just echo on each
line and so this is of limited help.
Unless I am confused, in your example ant would wind up looking for
ant:case, and when it didn't find it it would have to poll the
containing elements for their name spaces and search those name spaces
or just search all available name spaces for a matching element. (the
latter of which obviously runs into problems).
If we do take a shortcut I think it would be better to do it like this:
project default=compile
switch value=${foo} xmlns=antlib:net.sf.antcontrib
case value=bar
echo message=The value of property foo is bar /
/case
case value=baz
echo message=The value of property foo is baz /
/case
default
echo message=The value of property foo is not sensible /
/default
/ac:switch
/project
This version means that ant looks for an echo element in the antcontrib
name space. Upon not finding an ant contrib echo it only has to look in
ant core for an alternate echo element and if it doesn't have either an
antcontrib echo or an ant echo, it should fail. Basically what we have
here is the condition that all antlibs inherit (but may overide) ant
core tasks.
I like that one better, what do you think?
Gus
Peter
Gus Heck wrote:
Gus Heck wrote:
re given to the elements in the calling macro.
In ant 1.6.0+, the namespace of elements discovered by reflection take
the namespace uri of type/task that contains the element (Note this
is the
uri and not the localname).
The enclosed patch will allow the namespace of nested elements to be
either the ant uri or the namespace of the containing type/task.
I am quite possibly confused but I thought xml namespaces required
that the namespace be
1. The namespace indicated by the specified prefix
2. If there is no prefix, then the current default namespace must be
used. (defined on some containing element, be it the top element or
some other containing element with an xmlns=some uri).
If an unprefixed element is taking on a namespace not declared with
xmlns=some uri (which is different from xmlns:foo=some uri)
aren't we blowing it in implementing namespaces correctly?
-Gus
Was I wrong? Confused? or just ignored?
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: macro and XML NS hell ;-)
Gus Heck wrote: re given to the elements in the calling macro. In ant 1.6.0+, the namespace of elements discovered by reflection take the namespace uri of type/task that contains the element (Note this is the uri and not the localname). The enclosed patch will allow the namespace of nested elements to be either the ant uri or the namespace of the containing type/task. I am quite possibly confused but I thought xml namespaces required that the namespace be 1. The namespace indicated by the specified prefix 2. If there is no prefix, then the current default namespace must be used. (defined on some containing element, be it the top element or some other containing element with an xmlns=some uri). If an unprefixed element is taking on a namespace not declared with xmlns=some uri (which is different from xmlns:foo=some uri) aren't we blowing it in implementing namespaces correctly? -Gus Was I wrong? Confused? or just ignored? -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BugID 27282 Misspelling: s/occured/occurred/g
Perhaps we need to appoint a committee to research spellings and spelling variants. Then we could foot note all words with variants for clarity. Honestly we should pick a single reference and a single locale and standardize on that. That way when a bug like this comes in we check the reference, and say yeah or nay without 6-10 emails of discussion. Given this discussion and the earlier mis pelt (my spell checker objects without the space :) ) discussion, I think we should spend more time coding and less time spelling things out. -Gus wrote: Not a native speaker either, but in possesion of an Oxford Advanced Learners Dictonary... This states: occur: take place; happen: Don't let this ~ again ... An idea has ~red to me. ... Since it usally lists differences for GB/UK, and doesn't mention it here, 'occurred' is probably the only correct spelling for this one. Regards, Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Ant Wiki] Updated: FrontPage
All the wiki mails are comming to me with the date 12/31/1969... is this intentional? It looks like a bug in the setups somewhere. [EMAIL PROTECTED] wrote: Date: 2004-03-01T10:19:22 Editor: 66.80.4.221 Wiki: Ant Wiki Page: FrontPage URL: http://wiki.apache.org/ant/FrontPage no comment Change Log: -- @@ -1,7 +1,7 @@ ##language:en #pragma section-numbers off -= Welcome to the Ant Wikis = += Welcome to the Ant Wiki = The Ant Wiki has been migrated from its old home on nagoya.apache.org to part of the Apache Wiki Farm. If you find any issues, feel free to fix them up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macro and XML NS hell ;-)
re given to the elements in the calling macro. In ant 1.6.0+, the namespace of elements discovered by reflection take the namespace uri of type/task that contains the element (Note this is the uri and not the localname). The enclosed patch will allow the namespace of nested elements to be either the ant uri or the namespace of the containing type/task. I am quite possibly confused but I thought xml namespaces required that the namespace be 1. The namespace indicated by the specified prefix 2. If there is no prefix, then the current default namespace must be used. (defined on some containing element, be it the top element or some other containing element with an xmlns=some uri). If an unprefixed element is taking on a namespace not declared with xmlns=some uri (which is different from xmlns:foo=some uri) aren't we blowing it in implementing namespaces correctly? -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: something for you [new virus?]
More likely, someone who's collected adresses includes both peter's address and this list has the virus. Is it you? :) -Gus Alexey N. Solofnenko wrote: Have you installed a new virus? - Alexey. [EMAIL PROTECTED] wrote: you earn money - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7 (target access)
In any case I am starting to think about ant 1.7 and further. Here are the points which spring to my mind : 1) local properties, 2) roles, 3) get the xdocs proposal out, 4) think about virtual file system abstractions, and do something about them, 5) fix some popular bugs from bugzilla How about access levels for targets too? In my patch to this effect (bug 22020) I addressed this from the perspective of command line invocation, but it was suggested that it would be better to come up with a solution that also related to use of targets by imports, the ant task, etc... and that a change that large should wait till 1.7. Now would seem to be the time to start a discussion and figure out what is desired here. -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REGRESSION: Ant 1.6+ doesn't detect duplicate targets
With a notion of target access levels we could flag a target as overridable, and leave the default as not overridable perhaps... kinda like java's final modifier only backwards. -Gus Dominique Devienne wrote: From: Peter Reilly [mailto:[EMAIL PROTECTED] I think it is used as a feature with the import task for target overriding... I thought that was the origin of the problem, but that doesn't make it less of a bug I'd say. Not much sense in the same build file overriding its own targets, no? It is a bug in one of my build file, and I'd like Ant to tell me about it. It's already much more difficult to know that a build file is correct with Ant 1.6+, since only executed tags are validated, so lets not add to the confusion with allowing duplicate targets in build files, please. Just yesterday I fixed yet another hidden bug in another build file, where the content of an outofdate was executed for the first time in a long while, because running in a newly checked out sandbox. I had the outofdate in an xmlns=..., and the Ant targets in sequential could thus not be found in the Ant-Contrib namespace... This kind of hidden bugs would warrant UNIT tests for build files, to run all possible targets, in all circumstances, with code coverage of the build file code, etc... I liked the fail-fast behavior of Ant 1.5 better, even though I'm aware of the technical reasons behind the changes to all UE. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Include the Apache 2.0 License in ant 1.6.1
If it doesn't go in 1.6.1 won't we be forced to do a 1.6.2 or 1.6.1p1 or something to update the licenses by March 1? [EMAIL PROTECTED] wrote: If there is time enough for that modifications, ok. Otherwise we should wait for the next release (may it be 1.6.2) But we should put the result of this vote on the web site. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A path for Ant 2? (was Re: FYI: Blog Complex build systems need a real language found)
This thread has somewhat stirred up my brain a bit and a thought that floated to the top goes like this: We do want to be able to write simple declaritive build scripts for builds. I think this is a major virture of Ant. But clearly when one ventures into the system of builds and such there are people who feel they need a more programatic tool. Maybe what is happening here is that we are trying to make Ant do too much... feature creep in essence. So the interesting (to me) part of the thought I had is this: Perhaps Ant is the tool for defining small declarative builds, or portions of a complex build system, and another more programatic tool should be created to take a series of Ant builds and coordinate them in large projects. While custom tasks are a great tool to have, and that option should always remain open, java is not a scripting language, it is an OO language, and one winds up with a fair bit of OO overhead (that's a fun one to say :) ). It takes some time and effort to learn where to find the things you need to write a custom task (like the use of DirectoryScanner, and the half dozen types of results it creates and the difference between getNotIncludedFiles, getExcludedFiles, and getDeselectedFiles). Maybe this is the real role for Ant 2? Ant 2 could use Ant 1 builds (or something close that can be autocreated from ant 1 builds) as atomic units, and provide a more comprehensive means of coordinating them, passing properties into them, etc. We could promote it like like a movie sequel :) Ant II: The Colony -Gus Stefan Bodewig wrote: On Wed, 21 Jan 2004, Jan Materne [EMAIL PROTECTED] wrote: http://www.theserverside.com/news/thread.jsp?thread_id=23426 I don't read TSS and haven't followed the article, but Jon is the build guy at ThoughtWorks, Martin Fowler's company. Martin has already blogged[1] about the same issue and my main comment[2] is that it is true. Complex builds need a real language and to me the real language is Java - write tasks. Stefan Footnotes: [1] http://martinfowler.com/bliki/BuildLanguage.html [2] http://stefanbodewig.blogger.de/stories/48048/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Bug Tracking System
My non-non commiter vote: [ ] +1 Bugzilla sucks - go to Jira [x] -1 BugZilla rocks - if it ain't broke, don't fix it. Doesn't it figure. I read a similar commons thread, and wrote a long email about why I think bugzilla is friendlier to the novice user than both JIRA and Scarab then I come here and see the same issue. Apparently I should have wrote it here... That is what I get for reading the other mail first :) One of the biggest strengths of Ant (and any OSS project) is the user feedback from both experienced and novice users... Here is most of what I posted (minus a question that has already been answered there), which I think we should consider here too. (I don't beleive it is likely to have hit the archives yet or I would link it). I sometimes think that there is an aspect of the ASF bug tracking systems that gets forgotten... How easy it is to learn to use them. As a contributer to Ant, and an operator of my own bugzilla, I have been very satisfied with bugzilla in this repsect. The first time I ever used bugzilla I had no trouble figuring out how to do a query, or fill in a bug form. The query form seemed a bit disorganized, but there were lots of explanatory links and with a little looking I found the submit button without too much trouble. I have not once had to explain details of how to use bugzilla to users of my bugzilla, nor have I recieved complaints about it. Some of the users are introductory programming students who have never used any bug tracker before. In contrast, I don't like scarab. I have several times found issues in OJB (relating to JDO implementations), but they use Scarab. Scarab I regret to say is quite difficult to use (at least if you don't already know how to use it, or maybe only if you are used to using bugzilla, I don't know which). It entirely fails to document itself clearly. Bugzilla has explanitory links all over it's bug creation and query forms, which is something I beleive to be critical to a bug tracking system that will be accessed by users who are not already familiar with it. I have several times tried to use Scarab, and each time it has failed, or it has eaten all my plain text formatting by coalescing all the whtiespace (that makes stack traces really fun to read), or whatnot. I am sure it is user error on my part, but so far I really haven't had time to find out where to read up on how to properly use Scarab. Another annoyance is that after you sign up for an account with scarab it tells you you must request membership in a project, which seems to imply that you might be rejected. Really not a very welcoming start. The systems used at apache should (IMHO) be transparent, user friendly and self explanitory. If they want users to report bugs in their software, it should be easy to learn the system. The current result with Scarab and me, is if I see that a project uses scarab, I only report bugs on their mailing list. I suppose if I decide I want to become a direct contriubuter to a project that uses Scarab, or I have some free time and think of it, I will take the time do the research to figure out how to enter bugs properly in Scarab. So I wrote the above mostly based on the gut reaction, oh no not another bug system to fight with... After looking at Jelly's JIRA as linked from their project pages (http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10012), it is clear that there are some nice features, it looks nicer than both bugzilla and scarab and is and friendlier than scarab, but I do see one major usability glitch. Nowhere did I see a link for Entering a bug. This is the main reason people come to a bug database. How can there not be a link on the front page for it!?!? I have a strong suspeicion that such a link would have appeared had I created an account and logged in, but there was no link for that either... just a log in link. (now I think it is vairly likely if I followed the log in link it would eventually get me to an account creation link, but) Only my existing knowledge of how web apps and bug trackers tend to work tells me that. Nothing on the page helps you enter a bug. (unless I am blind or stupid, both of which happen occasionally). It could use more explanitory links too, but at least there was a help link (once I saw the really tiny bubble thing in the upper right) that led to a detailed manual (though that manual didn't have a Enter a bug section). I didn't have time to browse the manual deeply, but this is still inferior to links on the issue entry page, because the user must leave the page, and search the manual for the item they don't understand, rather than being taken directly to the item. It's hypertext man, take advantage of that! The entry page is is a stark contrast to bugzilla where you are immediately provided with links to do each of the main tasks (quick search, detailed query, enter bug, get summaries, log in, create account). Whatever
Re: a comment about xml namespace
I have only followed this discussion peripherally at best, and I know it has been going on for a while, so I am almost certainly be missing information from previous posts, but here's what strikes me as potentially reasonable... and thus represents my initial expectations of what I will find when I do get around to exploring antlibs. It seems to me that in an ant file of the future one might find: 1. There should be a name space URI that ant uses to identify it's internal core components... the things we distribute that are not in antlibs. This should be the default namespace for any element that does not have a defined namespace. This could have a antcore:// or just ant:// scheme part for recognizability, or be a http:// schemed URI with the idea that it better identifies the source of the program intended to process the xml. Since it is unique it could be mumblyfoo://barbazbam and still work (I think). This would also apply to tasks introduced with taskdef/. 2. The name space URIs that antlibs declare to identify their components. Each of these is associated with user specified prefix. We probably should require these URI's to use the antlib:// scheme so that they are easily identified as xml elements that we _do_ need to pay attention to. Elements without a prefix that were not matched against the core could then be searched for among the antlibs to retain back compatability, but just as with classpaths it might matter what order the antlibs were in if there were conflicting elements. User specified antlibs would need to follow the ones we distributed in the search order. This is potentially hairy, but if it is to be possible for people to write and distribute thier own antlibs, then this is going to crop up no matter what we do. The URI should be defined IN the antlib, and might be associated with it's prefix directly in the ant xml (causing the main engine to look for an antlib in default and declared locations that declares itself as to have that URI and error out if an antlib:// scheme uri does not match an available antlib) or if the user wants to use only default name spaces and let ant figure out what lib to use antlib lib=foo/bar-antlib.jar/ or somesuch to tell ant to look there too for otherwise unrecognized elements. It would seem reasonable that antlibs maintained by apache ant would have a uri like: antlib://ant.apache.org/antlibs/tasks/optional/unix# and the individual tasks could be identified as the fragment parts: antlib://ant.apache.org/antlibs/tasks/optional/unix/#symlink antlib://ant.apache.org/antlibs/tasks/optional/unix/#chgrp This gives each task a URI of it's own, and would potentially allow us, custom task authors, or anlib authors to provide RDF metadata for tasks as well as RDF metadata in the build file. I'm not sure how such data would get used, but I'm sure someone will think of a use. Perhaps there will be an ontology to describe tasks to IDE's so that IDE's can attempt to integrate antlibs not known about by the IDE authors? like maybe this triple for a dependancyreasoner task antlib://example.org/antlibs/#dependancyreasoner http://ant.apache.org/ontologies/ant-ide-integration#contentType http://www.w3.org/2002/07/owl# The IDE could then ask itself (or some external entity) if it knew anything about OWL, and perhaps discover a means of validating the content as proper OWL (a web service? something like w3c's html-validator? download a lib from the ide vendor?) or warn the user that it doesn't know how to validate OWL. Ok so I can think of one... Imagine builds that think for themselves... scary :) Antcontrib might have an antlib that was specified as: antlib://ant-contrib.sourceforge.net# which of course has. antlib://ant-contrib.sourceforge.net#foreach 3. Other name space URI's associated with prefixes but not associated with antlibs. If it isn't in the core and it is not an antlib, just ignore it. If it is contained within a task, it should be available to the task If the task requires (for example) valid RDF subelements, it should look for elements that are associated with the rdf namespace(s), and ignore others. Tasks requiring content that uses an external name space should have a way of communicating this namespace to a list of recognized name spaces. Then one could run ant in 1 of 3 name space modes... -nsFail -nsWarn -nsIgnore. I don't see typos as a big problem if things were done this way, because URI's would be pulled from the libs and prefix typos can be identified with warn or fail mode. If you typo from one prefix into another... I don't think we can ever fix that problem. If you construct your build in a way that regularly uses outside name spaces without a task to register them as recognized, the ?ant-ignore uri=? seems like a good way to still allow -nsFail to be useful, but if you do ?ant-ignore uri=http://www.w3.org/1999/02/22-rdf-syntax-ns#; ? then you can't have a task that uses RDF subelements (unless
Re: a comment about xml namespace
This seems to be an incomplete version of what I wrote and does not match what I find in my sent folder. I will try again and hope I don't spam you all too much. my mail client seems to be acting funny. Appologies. -Gus Gus Heck wrote: I have only followed this discussion peripherally at best, and I know it has been going on for a while, so I am almost certainly be missing information from previous posts, but here's what strikes me as potentially reasonable... and thus represents my initial expectations of what I will find when I do get around to exploring antlibs. It seems to me that in an ant file of the future one might find: 1. There should be a name space URI that ant uses to identify it's internal core components... the things we distribute that are not in antlibs. This should be the default namespace for any element that does not have a defined namespace. This could have a antcore:// or just ant:// scheme part for recognizability, or be a http:// schemed URI with the idea that it better identifies the source of the program intended to process the 2. The name space URI that a given antlib declares to identify it's components and is associated with user specified prefix.We probably should require these URI's to use the antlib:// scheme so that they are easily identified as xml elements that we do need to pay attention to. Elements without a prefix that were not matched against the core could then be searched for among the antlibs, but just as with classpaths it might matter what order the antlibs were in if there were conflicting elements. This is potentially hairy, but if it is to be possible for people to write and distribute thier own antlibs, then this is going to crop up no matter what we do. The URI should be defined IN the antlib, and might be associated with it's prefix directly in the ant xml (causing the main engine to look for an antlib in default and declared locations that declares itself as to have that URI and error out if an antlib:// scheme uri does not match an available antlib) or if the user wants to use only default name spaces and let ant figure out what lib to use antlib lib=foo/bar-antlib.jar/ or somesuch to tell ant to look there too for otherwise unrecognized elements. It would seem reasonable that antlibs maintained by apache ant would have a uri like: antlib://ant.apache.org/antlibs/optional/unix and the individual tasks could be identified (though I am not sure what use it is for ant, it would be genrally consistant with RDF and potentially allow us, custom task authors, or anlib authors to provide RDF metadata for tasks) as the fragment parts: antlib://ant.apache.org/antlibs/optional/unix/#symlink antlib://ant.apache.org/antlibs/optional/unix/#chgrp antcontrib might have an antlib that was specified as.. antlib://ant-contrib.sourceforge.net which of course has. antlib://ant-contrib.sourceforge.net#foreach 3. Other name space URI's associated with prefixes but not associated with antlibs. If it isn't in the core and it is not an antlib, just ignore it. If it is contained within a task, it should be available to the task If the task requires (for example) valid RDF subelements, it should look for elements that are associated with the rdf namespace(s), and ignore others. Tasks requiring content that uses an external name space should have a way of communicating this namespace to a list of recognized name spaces. Then one could run ant in 1 of 3 name space modes... -nsFail -nsWarn -nsIgnore. I don't see typos as a big problem if things were done this way, because URI's would be pulled from the libs and prefix typos can be identified with warn or fail mode. If you typo from one prefix into another... I don't think we can ever fix that problem. If you construct your build in a way that regularly uses outside name spaces without a task to register them as recognized, the ?ant-ignore uri=? seems like a good way to still allow -nsFail to be useful, but if you do ?ant-ignore uri=http://www.w3.org/1999/02/22-rdf-syntax-ns#; ? then you can't have a task that uses RDF subelements (unless there is a way for tasks to un-ignore name spaces, or ignore without throwing away). How far are my expectations from what is actually in place? What are the flaws in my expectations (I am sure there will be plenty :) )? -Gus Jose Alberto Fernandez wrote: From: Jim Fuller [mailto:[EMAIL PROTECTED] I like the idea that Ant may understand what to do with other external namespaces like such as proposed with the html: example. And generally agree with how it is proposed how Ant deals with namespaces it 'knows' about. I am going to become picky here because I think it is important to understand the small details in this conversation. There are several ways to understand what it means for ANT to know about a namespace: 1) ANT knows about any namespace declaration that there is in your buildfile. This may not seem too
Re: a comment about xml namespace
I have only followed this discussion peripherally at best, and I know it has been going on for a while, so I am almost certainly be missing information from previous posts, but here's what strikes me as potentially reasonable... and thus represents my initial expectations of what I will find when I do get around to exploring antlibs. It seems to me that in an ant file of the future one might find: 1. There should be a name space URI that ant uses to identify it's internal core components... the things we distribute that are not in antlibs. This should be the default namespace for any element that does not have a defined namespace. This could have a antcore:// or just ant:// scheme part for recognizability, or be a http:// schemed URI with the idea that it better identifies the source of the program intended to process the xml. Since it is unique it could be mumblyfoo://barbazbam and still work (I think). This would also apply to tasks introduced with taskdef/. 2. The name space URIs that antlibs declare to identify their components. Each of these is associated with user specified prefix. We probably should require these URI's to use the antlib:// scheme so that they are easily identified as xml elements that we _do_ need to pay attention to. Elements without a prefix that were not matched against the core could then be searched for among the antlibs to retain back compatability, but just as with classpaths it might matter what order the antlibs were in if there were conflicting elements. User specified antlibs would need to follow the ones we distributed in the search order. This is potentially hairy, but if it is to be possible for people to write and distribute thier own antlibs, then this is going to crop up no matter what we do. The URI should be defined IN the antlib, and might be associated with it's prefix directly in the ant xml (causing the main engine to look for an antlib in default and declared locations that declares itself as to have that URI and error out if an antlib:// scheme uri does not match an available antlib) or if the user wants to use only default name spaces and let ant figure out what lib to use antlib lib=foo/bar-antlib.jar/ or somesuch to tell ant to look there too for otherwise unrecognized elements. It would seem reasonable that antlibs maintained by apache ant would have a uri like: antlib://ant.apache.org/antlibs/tasks/optional/unix# and the individual tasks could be identified as the fragment parts: antlib://ant.apache.org/antlibs/tasks/optional/unix/#symlink antlib://ant.apache.org/antlibs/tasks/optional/unix/#chgrp This gives each task a URI of it's own, and would potentially allow us, custom task authors, or anlib authors to provide RDF metadata for tasks as well as RDF metadata in the build file. I'm not sure how such data would get used, but I'm sure someone will think of a use. Perhaps there will be an ontology to describe tasks to IDE's so that IDE's can attempt to integrate antlibs not known about by the IDE authors? like maybe this triple for a dependancyreasoner task antlib://example.org/antlibs/#dependancyreasoner http://ant.apache.org/ontologies/ant-ide-integration#contentType http://www.w3.org/2002/07/owl# The IDE could then ask itself (or some external entity) if it knew anything about OWL, and perhaps discover a means of validating the content as proper OWL (a web service? something like w3c's html-validator? download a lib from the ide vendor?) or warn the user that it doesn't know how to validate OWL. Ok so I can think of one... Imagine builds that think for themselves... scary :) Antcontrib might have an antlib that was specified as: antlib://ant-contrib.sourceforge.net# which of course has. antlib://ant-contrib.sourceforge.net#foreach 3. Other name space URI's associated with prefixes but not associated with antlibs. If it isn't in the core and it is not an antlib, just ignore it. If it is contained within a task, it should be available to the task If the task requires (for example) valid RDF subelements, it should look for elements that are associated with the rdf namespace(s), and ignore others. Tasks requiring content that uses an external name space should have a way of communicating this namespace to a list of recognized name spaces. Then one could run ant in 1 of 3 name space modes... -nsFail -nsWarn -nsIgnore. I don't see typos as a big problem if things were done this way, because URI's would be pulled from the libs and prefix typos can be identified with warn or fail mode. If you typo from one prefix into another... I don't think we can ever fix that problem. If you construct your build in a way that regularly uses outside name spaces without a task to register them as recognized, the ?ant-ignore uri=? seems like a good way to still allow -nsFail to be useful, but if you do ?ant-ignore uri=http://www.w3.org/1999/02/22-rdf-syntax-ns#; ? then you can't have a task that uses RDF subelements (unless there is a way for tasks to
Re: [VOTE] macrodef - do attributes as properties or substitutions
My (non-committer) oppion coincides with Stefan here, with a slight
preference for
@{x}
because it looks like put the substitution AT this location when I
read it to myself.
However I can understand that $ escaping is already done and well tested
so reusing that code has value. $(x) is good enough for me if that is a
priorety (you will note I am not offering to code @{x} :) ).
(or we could make it (:x:) so that mozilla can turn them all into
smilies when we paste it to the list :) )
-Gus
Stefan Bodewig wrote:
On Mon, 17 Nov 2003, peter reilly [EMAIL PROTECTED] wrote:
OK, how do we want to implement macrodef attributes:
current
[ ] as textual substitution~ 4
[ ] as real Ant properties ~ 2
undecided ~ 1
only counting the binding votes would result in 1/2/1, so neither
choice has received enough binding votes by now. Dominique, Jose
Alberto and Steve know that I'm not ignoring their votes, but
technically they are non-binding.
If macrodef attribute are to be implements as substitutions, what
should be the notation? (where x is the attribute name)
[ ] as ${x} (look like ant properties)
-1, too confusing.
[ ] as @x
-1 doesn't work if you want to concatenate an expanded attribute and
some other text, i.e.
attribute name=foo/
attribute name=foobar/
is @foobarbaz the expansion of foo plus the literal text barbaz or is
it the attribute foobar plus the literal text baz - or something
completely different?
[ ] as ${attribute:x}
-1 - still looks too much like a property and collides with existing
properties that's name starts with attribute: (unlikely but
possible).
[ ] as $(x)
[ ] as @{x}
either one works for me - as well as [EMAIL PROTECTED]
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brent Rector on Msbuild vs Ant
now, they dont have to care what I say, but we do have the option of pulling all .NET support from ant1.6...we will just have to see if that matters to them. It'll be an interesting test of conflict of the tactical 'get .net developers today' over the strategic 'own the developers forever'. I think they would cheer if we took out .net support. It would give them another selling point for msbuild. The thing they hate most is competition. Leave it in and they will be more annoyed :). -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANTidote] possibly needs to be renamed!
I don't know much about trademark law, but doesn't it matter if their trademark precedes our usage? I'm pretty sure I can't declare Red to be my trademark and then tell certain linux distributors that they must cease associating their product with mine... can I? -Gus Christoph Wilhelms wrote: Hi all! I just want to tell you, that the President of the company Druide http://www.druide.com Eric Brunelle infomed me, that his company own the (not shure if just French or international) trademarks for the name Antidote in relation to computer software products. If I understand correctly the purpose of this software (http://www.antidote.info) it is a spellchecking and thesaurus software for general purpose and has nothing in common with our ANTidote. I proposed to let everything like it is, linking his URL from out Antidote project page to redirect the users of the other Antidote... Anyways: If we have to rename it, I propose to use a simple and gereic name like Ant GUI. Additionally: Renaming sounds like a not too bad idea, because I found (using Google) some virus detection programs called Antidote... Thoughts!?! Christoph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANTidote] possibly needs to be renamed!
Hmm I have this suspicion that we are just an ancillary target, these people probably really want to sue the virus software people who likely have some money to sue for. The problem is that if they don't pursue everyone, they probably can't go after the big one and have the courts beleive them. They might well accept a simple cheap workaround like the Apache Antidote name, as it aquiesses to thier trademark in name at least, and then they don't have to spend money chasing us. Also, if there is no trademark on file at the USPTO, we could of course get the trademark and tell them to stop using ours, but that might not be the peaceful easy and cheap way out -Gus Steve Loughran wrote: Adam R. B. Jack wrote: You may be right, because antidote is a commonly used word, but I am with Stefan here and I feel playing save can't be bad :-). What are the chances that the new name isn't a clash with somebody else somewhere? How far/wide do you search? Do you change again in a while when somebody surfaces? When does it end? when we bring a real product to market we pay lots of people for branding, user acceptance queries, etc. Even so, when you look at the global naming space, there are many cases of misnamed products. e.g The vauxhall/opel nova translated to 'no go' in spanish for example, which isnt good naming for a car, even though in the 1.1L version it was pretty apt. I think typically folks w/ name clashes, who don't truly clash in product/concept/marketing typically just learn to ignore it and coexist. The Internet is too big for no clashes. Maybe call it org.apache.ant.idote or something. ;-) google for antidote and software: Antidote for PC viruses http://www.vintage-solutions.com/English/Antivirus/Super/ Antidote medical billing http://www.donwalsh.com/antidote/antidote.html Antidote computer services http://www.antidotecomputer.com/ The PC virus one crops up all the time. Also a search of the USPTO of use registrations (try under) http://tess2.uspto.gov/bin/gate.exe?f=tessstate=vlg2jr.1.1 shows that only antidote computer services have a live US registration The EU search engine http://oami.eu.int/search/trademark/la/en_tm_search.cfm shows nothing; I dont know what that means. If it were just me, I would tell whoever sent the letter to Christophe that our product is a separate product from theirs, and we don't think there will be any more confusion between them than say MS office and Star Office. But I dont want to escalate things too out of hand. Indeed, given you are meant to call Ooo OpenOffice.org to distinguish it from OpenOffice, you can get very close to a trademark and still be clear. But it is too early to escalate. Perhaps we just make sure that we call it Apache ANTidote on all the web page docs tonight, send him a letter saying we have made sure that we use the full name. If he insists then raise the stakes by asking for to see the USPTO registration as you cannot find it in the search engine. finally, if we do to change the products name we ping the virus software vendors and ask if they have received the same emails what their action will be. heh. Surely Apache has run into this before, no? probably. There is some kind of Apache perfume registered, I see. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: failonerror; general solution
I'm not as eager to see the tasks in Ant proper as others, that's why I haven't taken any initiative here (in Apache speak, that's the difference between my +0 and the +1s that have been cast by others). Are we talking about all ant-contrib tasks or just try/catch? I thought just try/catch... -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: failonerror; general solution
Dominique Devienne wrote: -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 11:23 AM To: Ant Developers List Subject: Re: failonerror; general solution Dale Anson wrote: What's the difference in use case between this and the try/catch from ant-contrib or antelope? I'd suggest grabbing the try/catch from either, and making it a core task. Just judging from the e-mail that I get, the try/catch task in antelope is one of the main reasons people download it. I am +1 to trycatch, because it gives you better failure modes than just 'ignore'; like the option to rollback or warn. I'm +0 to trycatch, and +1 to enhancing sequential myself. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I see that both have their benefits. trycatch is slightly nicer in that you can do the catch right there, or set a property and use it the way sequential would work... I think that that is true from looking at the examples posted. Sequential has the advantage of not needing to get the ant-contrib folks to give it to us (which I seem to remember was the sticking point b4) If try-catch can be pulled in quick I'd be +1 for that +0 for sequential, and the oposite if it is going to take weeks to get try catch in Nothing prevents us from adding try catch later for additional functionality. If it isnt' going in 1.6 then I am for waiting on try/catch cause we probably have another year before 1.7 comes out :) -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 23397] - Need attribute for target tag to indicate hidden/internal target
Since bug 22020 has been duped twice (once before, and once since) and there is a patch available (mine of course :), though I did not report 22020), what are the chances of geting it into 1.6 It was submitted months ago. -Gus [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23397. 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=23397 Need attribute for target tag to indicate hidden/internal target [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-09-25 07:52 --- *** This bug has been marked as a duplicate of 22020 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: DO NOT REPLY [Bug 23397] - Need attribute for target tag to indicate hidden/internal target
Antoine Levy-Lambert wrote: What you would like would be useful to prevent the wrong targets from being called. But I wonder whether this change would not make ant unnecessary complex. The default (atribute omitted) state should behave as always. This is necessary for back compatability, and to keep the learning curve from getting too steep. The import task gives me the same sort of worry about complexity, but I keep reiminding myself... You don't have to use it if you don't want it ;). So at least from the user side, there is no obligatory complexity increase. The addition of another atribute in the documentation for target would be the only brain drain :)... As for the development side, it may lead to increased complexity if we add access modifiers with more complex meanings. As it is now, however the only meaning of public/private is do we reject it when invoked from the command line and the only time we need to check that is already included in the patch. I too would be interested to hear what other commiters think. - Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: DO NOT REPLY [Bug 23397] - Need attribute for target tag to indicate hidden/internal target
In fact I would be even more interested to hear the opinons of both commiters and non-commiters :). -Gus Gus Heck wrote: Antoine Levy-Lambert wrote: What you would like would be useful to prevent the wrong targets from being called. But I wonder whether this change would not make ant unnecessary complex. The default (atribute omitted) state should behave as always. This is necessary for back compatability, and to keep the learning curve from getting too steep. The import task gives me the same sort of worry about complexity, but I keep reiminding myself... You don't have to use it if you don't want it ;). So at least from the user side, there is no obligatory complexity increase. The addition of another atribute in the documentation for target would be the only brain drain :)... As for the development side, it may lead to increased complexity if we add access modifiers with more complex meanings. As it is now, however the only meaning of public/private is do we reject it when invoked from the command line and the only time we need to check that is already included in the patch. I too would be interested to hear what other commiters think. - Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: DO NOT REPLY [Bug 23397] - Need attribute for target tag to indicate hidden/internal target
How does a java application (other than ant) invoke an ant target (I
can see using a task easily, but not a target) Can you give me an
example where a target gets invoked by java code?
If you are talking about invocation from within ant, then I have
difficulty imagining what parts of ant would hide targets from other
parts of ant... Imported Files is about the only case that comes to
mind, and to me that seems like an entirely different issue, but I have
provided for that possiblity, by adding an isAccessibleFrom(String)
method, which is used like this:
if (aTarget.isAccessibleFrom(command line)) { /* do stuff */ }
Modification of this method to understand strings other than command
line (such as importing build) and a check at the time of import
would be something that could be added in the future I think. For now,
this would eliminate the need to rely on command line behavior to hide
targets from users, and pave the way towards smoother IDE integration.
I am perfectly happy to change the name of my access atribute to
something like commandLine/noCommandLine or hidden/visible or
entry/noEntry if that helps. I can see a good argument for reserving
public/private for an alternate, deeper meaning than I have implemented,
but it is a word pair that comes to mind easily and so that is what I
have used for now.
-Gus
[EMAIL PROTECTED] wrote:
I don´t see the need for such an attribute. And if introduced it should work
not only from commandline. It should work too, if invoked by other java
applications.
Jan
-Original Message-
From: Gus Heck [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 25, 2003 5:58 PM
To: Ant Developers List
Subject: Re: AW: DO NOT REPLY [Bug 23397] - Need attribute for target
tag to indicate hidden/internal target
In fact I would be even more interested to hear the opinons of both
commiters and non-commiters :).
-Gus
Gus Heck wrote:
Antoine Levy-Lambert wrote:
What you would like would be useful to prevent the wrong
targets from
being called. But I wonder whether this change would not make ant
unnecessary complex.
The default (atribute omitted) state should behave as
always. This is
necessary for back compatability, and to keep the learning
curve from
getting too steep. The import task gives me the same sort of worry
about complexity, but I keep reiminding myself... You don't have to
use it if you don't want it ;). So at least from the user
side, there
is no obligatory complexity increase. The addition of
another atribute
in the documentation for target would be the only brain drain :)...
As for the development side, it may lead to increased
complexity if we
add access modifiers with more complex meanings. As it is
now, however
the only meaning of public/private is do we reject it when invoked
from the command line and the only time we need to check that is
already included in the patch.
I too would be interested to hear what other commiters think.
- Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/script ant
These changes arn't working for me. See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23358 -Gus Knut Wannheden wrote: These changes expand on Antoine's -lib code to support multiple -lib options. In addition, the -lib option can now name a directory containing jars and all jars in that directory will be added to Ant's launch classpath. So I suppose it isn't possible to add a directory with classes in it as a -lib option. The classes need to be packed up in a jar, right? -- knut - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting 1.6 out the door
Costin Manolache wrote:
Dominique Devienne wrote:
As I've been saying all along, lets just introduce a new (unique) notion
for attribute/variable expansion (at use time rather than definition
time), which
is something new in Ant anyhow. No (or less?) backward compatibility
issues, and makes it plain and obvious what is what:
${name} it's a property!
(@name) it's an attribute/variable!!!
I think this is a bad idea.
Chosing between macrodef and ant simplicity - I preffer the second.
There are already a lot of complex rules in ant and antcall and
import, I think the last thing we need is a new syntax for macrodef
variables.
Costin
Is it simpler to add yet another complex rule to the meaning of ${foo}
or to attach the new rule to a new syntax that only needs to be learned
for the use of macrodef only. Anyone who hasn't used macrodef will see
the new syntax in a build and know there is something different going on
with (@foo) (or whatever). By contrast, ${foo} will appear to be
something the user has seen before, but produce unexpected behaviors...
and perhaps bug reports? Furthermore, if the syntax is the same, then
one needs both scoping/rules to identify the type of ${} and rules about
it's behavior. If the syntax is different there is no need to
distinguish it because it is already distinct. One could make all their
replace tokens look like properties too, but I suspect this is not a
common thing to do for the similar reasons.
No context, no unnecessary brain cycles to figure out what is what.
I'll be just as glad as the next guy to use macrodef, I just don't want
that
power to come of the expanse of Ant's simplicitly and user-friendliness.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting 1.6 out the door
Nicola Ken Barozzi wrote: peter reilly wrote, On 01/09/2003 20.10: On Monday 01 September 2003 16:43, Dominique Devienne wrote: ... It's not all about power, or one would use a real programming language like Perl or Python. macrodef, although powerful, complexifies the rules of Ant, namely the property expansion one, making it context dependent! What she said :) Never underestimate the power and simplicity of context/scope free rules. Although Ant already has scopes with ant/antcall/subant, the property expansion rules works the same everywhere, and I'd like this to stay the same. macrodef follows (I think) the same rules of properties as antcall with inheritall=yes. +1 Modeling after antcall...? I am wary of this as antcall is broken at the top level. http://issues.apache.org/bugzilla/show_bug.cgi?id=22759 I certainly havn't looked at macrodef closely enough to know if it will be subject to the same problem, but it makes me wonder. It might even be the case that antcall should be deprecated and replaced with macrodef if macrodef works at the top level and can truely duplicate antcall's functionality. From Nicola Ken Barozzi: Imports should be reusable bits of builds. But instead they carry the baggage of targets. With macrodef I can finally *create tasks using Ant*. And so Ant becomes an xml based programming language? Writing tasks in java seems preferable to me. I am not opposed to macrodef, but I want clear syntax that doesn't make atributes look like properties, and if we do have macrotemplates (which I still have some reservations about) I think they should have a backwards compatable syntax that is also clearly different from both properties and atributes. A clear syntax is my biggest gripe here. -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting 1.6 out the door
Steve Loughran wrote:
Gus Heck wrote:
I don't think there's such a thing as experimental stuff. It's
either in or
not, and once in, it must be backward compatible.
I'm sorry so few people chimed in on the subject of overloading the
meaning
of ${name} in Ant. If this could be changed, then I'd have an
enthusiastic
+1, but as it stands, I'm -1 or maybe -0.
--DD
I agree 100%.
I also would like some feedback on my target access modifier patch,
if possble
(see http://issues.apache.org/bugzilla/show_bug.cgi?id=22020)
I have mentioned this to a couple of people, including the friend who
introduced me to ant in the first place and all thought the idea was
good. I would like it to get in 1.6 if possible.
I am worried about the interaction between public/private and the
inclusion mechanism. Will people expect object style access modifiers
to work with inclusion, such that targets marked private can not be
called by included content?
I am similarly concerned and so I would like it considered before back
compatablity constrains us with import etc. Personally, the private
public distinction I have made (as I have implemented it) could be
called non-user and user as easily as it only effects the ability to
access things from the command line. I tried to write it in a way that
other access tags could be used, to create a broader continum, though I
havn't gone so far to set it up to handle independant flags. (such that
user/non-user could be independant from import/no-import)
My patch is just a suggestion, and I am looking for feedback on how it
could be improved, or made to play nicely with things like import.
Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting 1.6 out the door
I don't think there's such a thing as experimental stuff. It's either in or
not, and once in, it must be backward compatible.
I'm sorry so few people chimed in on the subject of overloading the meaning
of ${name} in Ant. If this could be changed, then I'd have an enthusiastic
+1, but as it stands, I'm -1 or maybe -0.
--DD
I agree 100%.
I also would like some feedback on my target access modifier patch, if
possble
(see http://issues.apache.org/bugzilla/show_bug.cgi?id=22020)
I have mentioned this to a couple of people, including the friend who
introduced me to ant in the first place and all thought the idea was
good. I would like it to get in 1.6 if possible.
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
Templates appear to be something new, though I don't think I
like them
(see below)
(1) -- ${xyz}
(2) -- ${macroattr:xyz}
(3) -- ${macrotemplate:xyz}
Well, as I said I use those terms above just as examples, I am not
hookup in words,
I was just looking for some identifier to describe them. Still the
concepts
I am expressing are very clasical ones, these are not things out of the
blue.
I would personally prefer a slightly more distinct syntax that didn't
use ${} for things that arn't exactly properties. Looking at it another
way: your suggestion is a half-magic property :) It reserves property
names starting with macroattr: and macrotemplate: as special, and
different from other properites.
If macro definitions are available to sub builds, then your 3rd case
might occur, but I don't think it would be good to allow macros to be
called across build file boundaries. builds would be almost
unintelligible without tracking down the macros from other files.
This is all regular kosher ANT stuff, up to this day, taskdef/s get
inherited, they do not need to be redeclared for the task to be
available
during the antcall/. Are you proposing that we have a different,
special case,
semantics for macrodef?
I hadn't realized that taskdefs did this, but if it were up to me I
wouldn't have designed it this way. I would prefer to see the taskdefs
in each build file, so that I don't have to find out who's calling the
buildfile to find out where to find out what the task does. Any time you
get that many find-outs in a sentance it is clearly a royal pain in the
making (imho). :).
In otherwords, I would have prefered the simple rule, if it isn't part
of the standard distro of ant, there will be a taskdef in the build to
tell you what it is. I don't think saving a few extra lines of typing
(or cut/paste) for the taskdefs is really worth making the build
unreadable without reference to another build (which won't be known
unless it appears in a comment).
I havn't followed the antlib topic closely enough (I havn't followed it
at all really because of the sheer volume of mail on those threads, and
the need to get some of my own work done :) ), but I get the impression
that antlib might reasonably eliminate the taskdef stuff by creating a
single place to look for definitions of things that arn't part of the
standard distro. and that would be fine. I only object to having to
having the builds depend on things defined in other builds with no
pointer to the definition (or standard location for the definition).
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
Nicola Ken Barozzi wrote: [returned from holiday, happy to read the list again :-) ] Jose Alberto Fernandez wrote, On 22/08/2003 14.58: From: Gus Heck [mailto:[EMAIL PROTECTED] ... If macro definitions are available to sub builds, then your 3rd case might occur, but I don't think it would be good to allow macros to be called across build file boundaries. builds would be almost unintelligible without tracking down the macros from other files. This is all regular kosher ANT stuff, up to this day, taskdef/s get inherited, they do not need to be redeclared for the task to be available during the antcall/. ... We already have a solution for the case of taskdef I would just like the behavior on both cases to be the same, so to reduce the leaarning curve. What about making them part of antlibs too? How does a macro defined in the build become an antlib? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
I'm not sure I buy your 3 things argument. In my mind there are 2 things
in what is previously proposed...
properties and parameters
Templates appear to be something new, though I don't think I like them
(see below)
(1) -- ${xyz}
(2) -- ${macroattr:xyz}
(3) -- ${macrotemplate:xyz}
So for a definition like:
property name=xyz value=true/
Now ${xyz} is true forevermore because properties are immutable
macrodef name=abc
attribute name=pqr/
sequential
javac debug=${xyz} ... /
This line ${xyz} should get replaced
javac debug=${macroattr:pqr} ... /
javac debug=${macrotemplate:xyz} ... /
/sequential
/macrodef
I'm not sure how you get a second level of expansion, or if it is desireable
After this definition the macro that is actually expanded will look
something like:
attribute name=pqr/
sequential
javac debug=true ... /
javac debug=${macroattr:pqr} ... /
javac debug=${xyz} ... /
/sequential
which will be further expanded in a call frangment, maybe inside an
ant call:
property name=xyz value=false/
abc pqr=true/
abc pqr=false/
I'm not sure this makes sense (to me at least) if it is part of an
ant call, then the macrodef should be in the build file used in the
antfile atribute... in which case your first javac might also come out
with debug=false (assuming inheritall=false, and the property definition
was before the macro definition) or debug=${xyz} (unexpanded, and
causing the build to fail because it wasn't defined yet, if the property
isn't before the macro definition, as you have shown). If the task does
property replacement at invocation time, then you still should get
debug=false for your first javac since the property won't have been
expanded yet.
If macro definitions are available to sub builds, then your 3rd case
might occur, but I don't think it would be good to allow macros to be
called across build file boundaries. builds would be almost
unintelligible without tracking down the macros from other files.
It would also bring up yet another scoping issue for 2 files that
defined macros with the same name and then one called the other. Granted
this might be an xml namespaces thing, but the more parts of ant that
require namespaces the steeper the learning curve for new users.
To effectively finish executing the following ANT fragment:
property name=xyz value=false/
sequential
javac debug=true ... /
javac debug=true ... /
javac debug=${xyz} ... /
/sequential
sequential
javac debug=true ... /
javac debug=false ... /
javac debug=${xyz} ... /
/sequential
So, as long as we can acomplish something like this, and we do not add a
bunch
of new machinery in the process, I think it is a wonderful feature.
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
I stopped arguing this point, as I was the only one concerned apparently,
but since Jose Alberto brings it up again...
Having ${NAME} not evaluate to the value, if any, of the NAME property, at
the time the task it's used in (macrodef is this case) is executed, is
REALLY REALLY BAD in my sincere opinion. Maybe foreach does it, but that
I agree with you on this... I had to use foreach for the first time
recently and was astounded that it had been written that way. It
completely confuses the issue of property immutability, and makes the
parameter hard to find. You need to know what the argument is before you
look for it. Think about explaining property imutability to someone...
${foo.bar} can never change... exept when it isn't a property... how do
I know it isn't a property? they ask... The answer would be you just
have to know the tasks where ${foo.bar} might not be a property, and
check what the parameter name is. At that point the person you are
explaining this to rolls their eyes and says Ugh. That is annoying :)
I think macrodef should not duplicate this problem and if foreach ever
came into ant it should have a namechange and new parameter system.
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [new tasks] presetdef and macrodef
Jose Alberto Fernandez wrote:
Dominique,
As its name indicates macrodef/ is a MACRO. And macros are macros are
macros
and they are suppose to be textually replaces at the point on
invocation.
Of course the parameters need to be replaced. The point is they
shouldn't look like properties. This way they can't be confused with
properties. An alternate form to ${foo} is all that is needed. Just
search for a diferent pattern... [EMAIL PROTECTED] or (@foo) or @{foo} or %{foo} or
$[foo] or really anything that isn't ${foo}. Dominique did also point
out that (@foo) and [EMAIL PROTECTED] are already commonly used in other contexts
that build authors will be familliar with.
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Yes. PropertyHelper is a property interceptor, and it simply rocks.
In essence, you register a helper with Ant. Then, at each request for
a property, each registered helper is asked for the property value in
turn; the first one that has it, returns it.
Completely not following this property helper discussion up to this
point so I may be repeating something, (forgive me if I am) but this
sounds like the results of the request for a property could change if a
new property helper gets added... Does this break immutability? It may
be that the value of a property object never changes, but if the value
of ${foo} is one thing and then becomes another when a helper is
added I suspect whatever you have done is not going to cause this,
but what about someone writing a custom task that intentionally adds and
removes property helpers. What happens if someone writes a setproperty
task built on this idea? what happens if the property helper intercepts
built in things like ${basedir}? Sounds like the basis for a possible
chdir task :). Sounds highly abusable to me...
If you have set it up so ant doesn't accept new property helpers after
it starts executing the file, then this probably isn't an issue...
Just curious,
-Gus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
Antoine, Since you have recently been playing with symlinks/FTP what are your thoughts on bug 14320? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14320 -Gus Stefan Bodewig wrote: On Wed, 6 Aug 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: 1) concerning the inclusion of in includedDirectories 1a) change the implementation of RM_DIR in order not to delete the root dir of the fileset or 1b) revert the inclusion of in includedDirectories and change the tests + document the difference with DirectoryScanner or our all time backwards compatibility saving option 1c) add a new attribute to ftp that controls the behavior. I'm not sure it's worth it, no real opinion other than we shouldn't break backwards compatibility just to fix something that hasn't been perceived as broken so far. 2) Concerning the symbolic links 2a) keep the code change and simply mention it in WHATSNEW. Then users who do not want to download symbolic link directories can simply set thecorresponding attribute to false. or 2b) add a flag in DirectoryScanner#setFollowSymlinks to record the fact that follow symlinks has been explicitly set to true, and only follow symlinks if the user mentioned it explicitly ? or 2c) call setFollowSymlinks(false) in FTPDirectoryScanner's constructor. I.e. change the default value of the attribute and document it that way. I'd be in favor of 2c). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
Antoine, Since you have recently been playing with symlinks/FTP what are your thoughts on bug 14320? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14320 -Gus Stefan Bodewig wrote: On Wed, 6 Aug 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: 1) concerning the inclusion of in includedDirectories 1a) change the implementation of RM_DIR in order not to delete the root dir of the fileset or 1b) revert the inclusion of in includedDirectories and change the tests + document the difference with DirectoryScanner or our all time backwards compatibility saving option 1c) add a new attribute to ftp that controls the behavior. I'm not sure it's worth it, no real opinion other than we shouldn't break backwards compatibility just to fix something that hasn't been perceived as broken so far. 2) Concerning the symbolic links 2a) keep the code change and simply mention it in WHATSNEW. Then users who do not want to download symbolic link directories can simply set thecorresponding attribute to false. or 2b) add a flag in DirectoryScanner#setFollowSymlinks to record the fact that follow symlinks has been explicitly set to true, and only follow symlinks if the user mentioned it explicitly ? or 2c) call setFollowSymlinks(false) in FTPDirectoryScanner's constructor. I.e. change the default value of the attribute and document it that way. I'd be in favor of 2c). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net FTP.java
Antoine Levy-Lambert wrote: - Original Message - From: Gus Heck [EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 4:10 PM Antoine, Since you have recently been playing with symlinks/FTP what are your thoughts on bug 14320? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14320 First the bad news : I do not have the time to work on this in the frame of ant 1.6. I am concerned that this might open a large Pandora box. :-( Fair enough :) Once ant 1.6 is released, I would like to discuss again the topic of Resource(s) and/or Jakarta-Common VFS. I would like to evaluate the use of Jakarta-Common VFS in ant, so that ant does not need to reinvent the wheel for everything. Just a thought at the moment, might be wrong. hmm I should find out what Jakarta-Common VFS is :) snip Manipulating the symbolic link as a link is doable in a portable way for packaging tasks (zip, jar, war, ear, tar). I am not sure what is the API to find the target of the symbolic link (do an exec of ls -L and read the result, or go the JNI route ?) ... Parsing command line output seems dicey and brittle. *** We need another attribute for filesets and directoryscanner called preservesymlinks. *** GUS I can imagine that one could add an atribute that caused an OS check and if we it is a *nix set a flag that caused copy to use FileUtils.isSymbolicLink to identify symlinks. symlinks could then be reproduced in either absolute form or minimum relative form or not reproduced in the destination directory based on an atribute such as copySymlinksAs=none|absolute|minRelative I don't know how much time I can put into it, but I'd be willing to try that if it sounds like a good idea to anyone else. /GUS ANTOINE Does minRelative mean relative to the root dir of the fileset ? Maybe asis would be a good option too, to copy somelink - ../../foo/bar as ../../foo/bar /ANTOINE /usr/local/storage/links/link2foo - /usr/local/storage/gus/baz/bar/foo is also equivalent to the following /usr/local/storage/links/lin2foo - ../../../../user/local/storage/gus/baz/bar/foo /usr/local/storage/links/lin2foo - ../../../local/storage/gus/baz/bar/foo /usr/local/storage/links/lin2foo - ../../storage/gus/baz/bar/foo /usr/local/storage/links/lin2foo - ../gus/baz/bar/foo The last of these is what I call minRelative. (I don't know if there is a more standard term). I currently convert all links in my website to this form by execing the linux command (not the ant task): symlinks -rcs from the document root twice. The first invocation changes absolute to relative, and the second reduces the lenghthy links to minimal links. I do not know if this command is available on other *nix platforms. It should also be possible to compare the canoniacal path of the dir the link is to be created in and the canonical path of the target of the link and calculate the minimum number of ../ 's needed to create the link and get minRelative that way. Maintaining asis requires direct knowledge of which of the 4 posibilities above was on the file system, and probably does require parsing output of ln or ls or whatever. minRelative links are of particular to me interest because they are the least likely to break when moving directories containing links around. The first of the 4 relative links always breaks, if it gets moved up or down a level, but if I move /usr/local/storage to /usr/local/old/storage then the last two forms still work. My website build creates links in a tempdir before moving the whole thing to where the world can see it (assuming all went well). This attribute would only be legal with followsymlinks=false (since true means manipulate the objects pointed to by the links). Then we need to define task by task how to use preservesymlinks/copysimlinks=none|absolute|minRelative AFAIK ANT Symbolic links do not exist in Windows (for ant's FileUtils#isSymbolicLink) Symbolic links can be created via the symlink task, which relies on ln -s available in the operating system /ANT agree WINDOWS .lnk files exist non .lnk links exist not aware of command line utility distributed with all versions of the OS to do this aware of ln.exe in cygwin aware of shortcut.exe, a program which is part of the Windows NT resource kit of Microsoft /WINDOWS lnk files have substantial functional differences. a .lnk to a directory cannot be included in the middle of a path as such: C:\projects\ant.lnk\src\main ... this won't work, but of course does work with symlinks. I have heard that there is something like symlinks out there called reparse points but I really don't know anything other than the name. (google searches a year ago wern't too fruitful on the topic, but this may have changed). UNIX the area where symbolic links support should be least problematic, except for possible exceptions due to media not accepting symbolic links /UNIX /AFAIK Apart from copy/, packaging tasks are good candidates for having the option of copying/preserving symbolic links
Re: CVS Commit with ANT
I'm doing CVS commit from ant via the apply task currently. I needed to sudo out of root for this particular situation, so cvs wouldn't have worked and I havn't tried the cvs command directly for commits. Apply works great for me though. This sort of question (How do I...?) is best asked on the ant users list. This list (the dev list) is mostly for people who are contributing code to be included in ant, discussing bugs, and their resolution, or trying to write code that involves with the ant internals. -Gus Vikas Phonsa wrote: Hi Does any one know if there is an Ant task to do CVS commit. I have seen the CVS task being used of checkouts and updates but he arguments don't seem to be working for a Commit. Any one has attempted CVS commit with Ant. Vik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: exec on openvms
- The Ant exec task throws a BuildException if the exit code is unequal zero. Do you know how to get around that? Should the Execute class, in the case of VMS, map the exit status to what's common on Unix systems? Maybe we should provide a Execute.isFailure(int result) method that returns result != 0 on all platforms except OpenVMS (and result % 2 != 0 on OpenVMS). So I read this and looked to my left at the Design Patterns book that was already open to the Adapter Pattern for other reasons... Fate? It does seem that an adapter to the java.Runtime() class that was OS sensitive could be an option. One might even have different adapter implementations for each OS, and instantiate different implementations based on which OS ant is being run under so you didn't have to process a bunch of if(Os.isName(foo)) to execute anything. Just a thought, perhaps not even a good one. You tell me :) -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checkstyle Audit
minor: RedundantThrowsCheck: It complains about BuildException. So is it prefered to eliminate the throws BuildException? or keep it? I'm willing to fix my code if I know what is actually desired here. Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
property from a flat file
Is there already a known way to load the entire contents of a file into a property? I know someone that wrote a custom task for this (using it with replace) and at a quick look I didn't see this functionality anywhere. Should I convince him to add a valuefromfile atribute to property? or did I simply miss an existing feature? -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
import statements
I was noticing that the file I am working on has it's imports in alphabetical order. Is this the standard, or are we free to organize our imports however we want in submissions? I have noticed some that arn't quite alphabetical, and I actually prefer a different organization altogether -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Enhance chgrp/chown?
Stefan Bodewig wrote: On Wed, 21 May 2003, Gus Heck [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: currently chmod has a fair number of additional features. Which are? dir, includes, excludes, defaultexcludes... Please don't! These attributes come from the pre-fileset time and are only kept for backwards compatibility. Please look at the special case in Chmod's execute that is needed to keep the old behavior of the dir attribute. Ah glad I asked. Another logicical addition to all 3 of them might be allowing dirsets. I think the type=dir attribute covers this, doesn't it? I guess multiple ways of doing things just isn't popular with anyone around here. Makes me wonder why we have dirsets at all if we can't use them here, and only in a narrow way for subant... I suppose type=dir is a pre-dirset feature on chmod, which I may have inadvertently propogated to my tasks because dirset was very new at the time I wrote them. (which was 4-5 months before they were commited due to the 1.5 release feature freezes). These tasks are not yet released, so maybe they should take DirSets instead? Granted that one would then need to supply a dirset and a fileset to get the both effect, but it would seem more consistant with the documentation of fileset which entirely fails to mention that directories are matched too. (unless you count the fact that /CVS is one of the default excludes). So what is the purpose of DirSet? Maybe fileset should have had a type=dir|file|both instead of having Dirsets. (of course with dirset released, it cant' be undone) What direction should I be taking with chgrp/chown here? Thinking out loud... It looks like we are not winding up with one way of doing things, but several ways that cannot be mixed between tasks. This will force the user to remember which flavor of file or directory specification a particular task finds tasty. To put it another way, I think we want to make using ant as simple as possible. To me life is simplest when any logical answer will do, and failing that, simple if there is one answer that always works. The worst case is a hashtable of case specific answers. The hashtable is what we are in danger of here. Given the constraints of back compatability, it seems that the only way to make life easy for the user is keep adding the new ways of referencing things (ie dirsets) to the old tasks in which they make sense. (much like has been done to chmod with filesets). This way at least, A dirset would always work and older ways you might or might not. If my logic is correct, and the goal is to minimize the number of ways to acomplish the same thing, we should not release chgrp and chown with the old method (type=) but rather convert them to a DirSet accepting version. (and add dirsets to chmod). This change would break builds (like mine particularly), but hey it is an alpha version... such is life. The pruning of things like chmod's dir atribute can be part of ant 2.0 where back compatability is not one of our promises... Of course if dirset is prunable, then I have it all backwards :). It has been a core task of Ant virtually since Ant exists, so there is no way to move it from core to optional unless we restructure the set of built-in tasks completely IMHO. To clarify. I don't think we should move any core task to optional at all - until we restructure our task system completely, which I'd expect to go along with antlibs, yes. There are more tasks than just chmod that are in core but don't really fit there (cvs for example). ok I understand. Have you found out anything about tandem/nonstop and chgrp chown yet? -Gus
Enhance chgrp/chown? (was: Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Chmod.java ExecuteOn.java)
Stefan Bodewig wrote: currently chmod has a fair number of additional features. Which are? dir, includes, excludes, defaultexcludes... chmod supports these with it's own internal fileset. I could duplicate it into my AbstractAccessTask (I think) to produce a similar effect in my tasks, but I hate duplicating code like that... it violates that whole DRY thing :). Another logicical addition to all 3 of them might be allowing dirsets. Finally, it seems a bit incongruous that chmod is not in optional/unix/ (now that that package exists), It has been a core task of Ant virtually since Ant exists, so there is no way to move it from core to optional unless we restructure the set of built-in tasks completely IMHO. Do you mean that if we move one thing there will be demand to move lots of others, or do you mean that there is a fundamental code level blockage to this that I have yet to perceive? Or is it a facet of the upcomming antlib thing? Of course moving a task to another package, brings up back compatability questions at the api level They can be solved by making the old class an (more or less) empty subclass of the new task. See Transform.java or SendEmail.java. Ok, and if I do this, is there still a difficulty in moving the meat of the chmod class to where it can extend the same base as the others? It doesn't seem like the sort of class that is likely to be extended or used in other code, I disagree with used. I could easily imagine using Chmod for a permission aware untar or unzip task for example. Mmm yes I suppose that people might have done things like that with it. So is worth my time to add the above mentioned features? (by that mean, would a reasonable implementation be likley to get committed?) -Gus
Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Chmod.java ExecuteOn.java
I noticed that this effects the chgrp and chown tasks... which also Extend ExcecuteOn and therefore now have the maxparallel atribute as well. I plan to patch the docs to reflect this and the fact that they seem to accept the verbose atribute as well. Other things I have noticed is that a little while back chmod added support for Os.isFamily(tandem). Should this go into chmod/chgrp too? If someone verifies that non-stop supports chgrp and chown in the standard unixy way I'll be glad to patch it as well. Furthermore, it seems that chgrp and chown really ought to support esentially the same feature set as chmod, but currently chmod has a fair number of additional features. I might flesh out chmod and chgrp, but since that takes more than a few minutes work, I would like to know if this is desired. Finally, it seems a bit incongruous that chmod is not in optional/unix/ (now that that package exists), and the situation seems ripe for a bit of refactoring, such that AbstractAccessTask.java holds most of the support for these three tasks and each task holds the specific differences. Of course moving a task to another package, brings up back compatability questions at the api level so I am hoping for a discussion of the severity of problems likely from moving chmod. It doesn't seem like the sort of class that is likely to be extended or used in other code, but that might just be my lack of imagination (or need for another coffee). Oh and do we have any idea when the target date for the first 1.6 beta release is... if this is to be done, I am sure we want the maximum ammount of user testing and feedback on it. -Gus [EMAIL PROTECTED] wrote: bodewig 2003/05/19 05:18:10 Modified:.WHATSNEW build.xml docs/manual/CoreTasks apply.html chmod.html src/main/org/apache/tools/ant/taskdefs Chmod.java ExecuteOn.java Log: You can now limit the parallelism of apply and chmod by using the new maxparallel attribute. Submitted by: Frank A. Hunleth fhunleth at cs dot wustl dot edu used in build.xml to fix PR: 17640 With the new addsourcefile attribute, you can make apply ommit the source file names from the command line. PR: 13654 apply and chmod now support nested filelists as well. PR: 15929 apply and chmod will display a summary if you set the new verbose attribute to true. PR: 19883 Revision ChangesPath 1.421 +12 -0 ant/WHATSNEW Index: WHATSNEW === RCS file: /home/cvs/ant/WHATSNEW,v retrieving revision 1.420 retrieving revision 1.421 diff -u -r1.420 -r1.421 --- WHATSNEW 16 May 2003 09:22:28 - 1.420 +++ WHATSNEW 19 May 2003 12:18:07 - 1.421 @@ -346,6 +346,18 @@ that can be used to turn of Microsoft extensions while using the jvc compiler. Bugzilla Report 19826. +* You can now limit the parallelism of apply and chmod by using the new + maxparallel attribute. + +* With the new addsourcefile attribute, you can make apply ommit the + source file names from the command line. Bugzilla Report 13654. + +* apply and chmod now support nested filelists as well. + Bugzilla Report 15929. + +* apply and chmod will display a summary if you set the new + verbose attribute to true. Bugzilla Report 19883. + Changes from Ant 1.5.2 to Ant 1.5.3 === 1.377 +3 -2 ant/build.xml Index: build.xml === RCS file: /home/cvs/ant/build.xml,v
Re: cvs commit: ant/docs/manual/CoreTasks subant.html
You could include my patch for the behavior you described (see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18391) or Andreas's patch (see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18715) which includes my functionality plus some other stuff too. -Gus Dominique Devienne wrote: This is incorrect, at least with my version. It will attempt to find a build.xml in all the directories, and FAIL if one cannot be found. To achieve what you describe, use a fileset: subant target= property name=build.dir value=subant1.build/ property name=not.overloaded value=not.overloaded/ fileset dir=. includes=*/build.xml/ /subant I understand you had failonerror=true, but then a build failure in any of the build actually found would be ignored, so it's not a good example IMHO. Regards, --DD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 14, 2003 4:58 AM To: [EMAIL PROTECTED] Subject: cvs commit: ant/docs/manual/CoreTasks subant.html antoine 2003/05/14 02:57:38 Modified:docs/manual/CoreTasks subant.html Added: proposal/xdocs/src/org/apache/tools/ant/taskdefs SubAnt.xml Log: added a merge point in xdocs for SubAnt and regenerated corresponding manual page PR:19181 docs of subant task Revision ChangesPath 1.1 ant/proposal/xdocs/src/org/apache/tools/ant/taskdefs/SubAnt.xml Index: SubAnt.xml === external description p iEXPERIMENTAL:/i This task is experimental and may be under continual change till Ant1.6 ships; it may even be omitted from the product. /p p Calls a given target for all defined sub-builds. This is an extension of ant for bulk project execution. /p /description section anchor=examples name=Example pre lt;project name=subant default=subant1gt; lt;property name=build.dir value=subant.build/gt; lt;target name=subant1gt; lt;subant failonerror=false target=gt; lt;property name=build.dir value=subant1.build/gt; lt;property name=not.overloaded value=not.overloaded/gt; lt;dirset dir=. includes=*/gt; lt;/subantgt; lt;/targetgt; lt;/projectgt; /pre p this snippet build file will run ant in each subdirectory of the project directory, where a file called build.xml can be found. /p /section /external 1.2 +89 -39ant/docs/manual/CoreTasks/subant.html Index: subant.html === RCS file: /home/cvs/ant/docs/manual/CoreTasks/subant.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- subant.html26 Mar 2003 17:55:37 - 1.1 +++ subant.html14 May 2003 09:57:38 - 1.2 @@ -34,7 +34,7 @@ tr td valign=top align=left - !-- Applying task/long-description -- + !-- Applying task/description -- !-- Start Description -- table border=0 cellspacing=0 cellpadding=2 width=100% trtdnbsp;/td/tr @@ -46,7 +46,15 @@ /td/tr trtdblockquote -iEXPERIMENTAL:/i This task is experimental and may be under continual change till Ant1.6 ships; it may even be omitted from the product. p Calls a given target for all defined sub-builds. This is an extension of ant for bulk project execution. +p +iEXPERIMENTAL:/i This task is experimental and may be under continual +change till Ant1.6 ships; it may even be omitted from the product. +/p +p +Calls a given target for all defined sub-builds. This is an extension +of ant for bulk project execution. +/p + /blockquote/td/tr /table @@ -55,13 +63,11 @@ !-- Start Attributes -- table border=0 cellspacing=0 cellpadding=2 width=100% trtdnbsp;/td/tr - trtd bgcolor=#525D76 font color=#ff face=arial,helvetica.sanserif a name=attributes strongParameters/strong/a/font /td/tr - trtdblockquote table tr @@ -74,20 +80,27 @@ td bgcolor=#cc valign=top align=left font color=#00 size=-1 face=arial,helvetica,sanserifbType/b/font /td +td bgcolor=#cc valign=top align=left + font color=#00 size=-1 face=arial,helvetica,sanserifbRequirement/b/font +/td /tr -!-- Attribute -- +!-- Attribute Group -- + +!-- Attribute Group -- +!-- Attribute -- tr td bgcolor=#ee valign=top align=left font color=#00 size=-1 face=arial,helvetica,sanserifantfile/font /td td bgcolor=#ee valign=top align=left - font color=#00 size=-1
Re: Roles (was: antlib)
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
Re: ant tutorial
I agree. This is really cool. The section labeled Top Level Tasks seems to say that tasks on the top level are run at parse-time. Does this mean that the order of tasks at the top level is the order of execution, or do the old toplevel tasks still run first? Gus Craeg Strong wrote: This tutorial is incredibly valuable, IMO. I would love to see this checked into CVS and given a permanent home on the ant website, kind of like ant in anger... 2c, --Craeg The first place was a very long time ago and there was a lot of history for why Ant is the way it is. You might be interested in a little tutorial I wrote to try and explain this history: http://codefeed.com/tutorial/ant_config.html Slick. I like it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant task and dirset/fileset
Hmm I notice that the source is marked as experimental and subject to change. Is this still true? To what extent. I am slightly leary of upgrading to an alpha branch for our builds, particularly if the compelling feature is going to be a moving target :) Also in your example buildfile, I am not sure I understand how the targets work. It looks like clean, build reversion and rebuild all do the same thing? -Gus Dominique Devienne wrote: No doc, no test :-( Subant accept a buildpath, which is a regular path (accepts nested fileset, dirset, etc... Subant's buildpath can be specified either outside (and referenced using buildpathref) or inside (subant contains an implicit buildpath, so you can add a dirset or buildpathelement directly within subant). All files all the build path (it's a path, so it's ordered) that is a directory is appended build.xml, or the value of the 'antfile' attribute if specified. By default, subant calls the target it's defined within automatically, or the target explicitly defined in the 'target' attribute. Supports all ant attributes (except 'dir' and 'output') and nested elements, and adds the 'failonerror' attribute, and nested fileset/filelist/buildpath/buildpathelement/dirset elements to compose the build path within. Hope that helps. --DD -Original Message- From: Gus Heck [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 4:07 PM To: Ant Developers List Subject: Re: Ant task and dirset/fileset Ok I searched bugzilla and subant appears exactly once... but it says it is committed. Problem is I don't see it in the manual, where can I get some doc for it? (or do I need to go find that link to the xdocs that I forgot to bookmark?) -Gus Dominique Devienne wrote: Yes ;-) Me, and other people too. There is in Ant's BugZilla one task called subant that was recently added to the HEAD (slightly modified) on an experimental basis, and there's also a patch to ant along the same lines. There has been quite a bit of discussion about both (one vs. the other even) on ant-dev as well. You should look it all up. As the original author and user of subant, I can tell you it's working just fine for me. Here's one of my build files, for example. Should be familiar to Makefile writers (it does build C++ libraries after all ;-) ?xml version=1.0? project name=Gocad default=build taskdef resource=com/lgc/buildmagic/tasks.properties / typedef resource=com/lgc/buildmagic/types.properties / buildpath id=buildpath pathelement location=src/lib/utils/utils.xml / pathelement location=src/lib/math/math.xml / pathelement location=src/lib/geobase/geobase.xml / pathelement location=src/lib/lines/lines.xml / pathelement location=src/lib/surfaces/surfaces.xml / pathelement location=src/lib/volumes/volumes.xml / pathelement location=src/lib/tgobjs/tgobjs.xml / pathelement location=src/lib/appli/appli.xml / pathelement location=src/lib/ascii/ascii.xml / pathelement location=src/lib/archive/archive.xml / pathelement location=src/lib/gapi/gapi.xml / /buildpath target name=clean subant buildpathref=buildpath / /target target name=build subant buildpathref=buildpath / /target target name=reversion subant buildpathref=buildpath / /target target name=rebuild subant buildpathref=buildpath / /target /project -Original Message- From: Gus Heck [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 3:34 PM To: [EMAIL PROTECTED] Subject: Ant task and dirset/fileset Has anyone ever thought about or tried to make the ant task accept a fileset or dirset? I have a use for such functionality but, before I go writing myself a custom version, or writing a patch, I thought I might ask if this has been tried, is being tried, or has be explicitly decided against? -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ant task and dirset/fileset
Has anyone ever thought about or tried to make the ant task accept a fileset or dirset? I have a use for such functionality but, before I go writing myself a custom version, or writing a patch, I thought I might ask if this has been tried, is being tried, or has be explicitly decided against? -Gus
Re: Ant task and dirset/fileset
Ok I searched bugzilla and subant appears exactly once... but it says it is committed. Problem is I don't see it in the manual, where can I get some doc for it? (or do I need to go find that link to the xdocs that I forgot to bookmark?) -Gus Dominique Devienne wrote: Yes ;-) Me, and other people too. There is in Ant's BugZilla one task called subant that was recently added to the HEAD (slightly modified) on an experimental basis, and there's also a patch to ant along the same lines. There has been quite a bit of discussion about both (one vs. the other even) on ant-dev as well. You should look it all up. As the original author and user of subant, I can tell you it's working just fine for me. Here's one of my build files, for example. Should be familiar to Makefile writers (it does build C++ libraries after all ;-) ?xml version=1.0? project name=Gocad default=build taskdef resource=com/lgc/buildmagic/tasks.properties / typedef resource=com/lgc/buildmagic/types.properties / buildpath id=buildpath pathelement location=src/lib/utils/utils.xml / pathelement location=src/lib/math/math.xml / pathelement location=src/lib/geobase/geobase.xml / pathelement location=src/lib/lines/lines.xml / pathelement location=src/lib/surfaces/surfaces.xml / pathelement location=src/lib/volumes/volumes.xml / pathelement location=src/lib/tgobjs/tgobjs.xml / pathelement location=src/lib/appli/appli.xml / pathelement location=src/lib/ascii/ascii.xml / pathelement location=src/lib/archive/archive.xml / pathelement location=src/lib/gapi/gapi.xml / /buildpath target name=clean subant buildpathref=buildpath / /target target name=build subant buildpathref=buildpath / /target target name=reversion subant buildpathref=buildpath / /target target name=rebuild subant buildpathref=buildpath / /target /project -Original Message- From: Gus Heck [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 3:34 PM To: [EMAIL PROTECTED] Subject: Ant task and dirset/fileset Has anyone ever thought about or tried to make the ant task accept a fileset or dirset? I have a use for such functionality but, before I go writing myself a custom version, or writing a patch, I thought I might ask if this has been tried, is being tried, or has be explicitly decided against? -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] JDK 1.1 support
Steve Loughran wrote: I don't see reasons to try to back-port fixes made on 1.6 to the 1.5. Only bugs identified by people running JDK 1.1 should make it to the 1.5 branch. This should be the only activity going on in that 1.5 branch. to date we are putting fixes to the 1.5 branch into 1.5.x, both minor and major, the zip work being the biggest. If any of that work had been in Java1.2 style, we couldnt have back ported it. Some of the changes (I think of the weak reference stuff) did have extra work to get into 1.1 compliance, incidentally. Once 1.6 ships, then we can stop doing any work to the 1.5.x branch, so this issue of having to back port code into a java1.1. compatible branch goes away. Except for people who want to maintain 1.1 support, and they get to do the work themselves. So we should wait till after the release to refactor our code? Given the above, there are no reasons to limit the 1.6 code base from *any* change that's JDK 1.2 (Java 2) compatible. That includes moving everything to the Java 2 Collections. I dont see the java2 collections as the compelling reason for this. They are nice, I use them, but it is really things like classloader, security manager, weak references and other major system changes that are forcing the move. I also see the reflection tests for existance of 1.2 methods as adding substantial clutter to the code. I think removing these is quite valuable to people trying to understand the flow of our code. I think these should be eliminated at a rate greater than slowly but surely :). As I said before, 1.5.x is a damn good release (once 1.5.3 is out), and should more than satisfy JDK 1.1 users (wherever they're hiding). The buck has to stop somewhere, and from the votes, it's clear 1.6 should depend on JDK 1.2. This should not prevent though JDK 1.2 to be fully used everywhere it's possible. Steve and Costin might as well -1 the move to JDK 1.2 with this kind of thinking. --DD I'm very happy with the move. I just don't think we should use this as an excuse to go s/Hashtable/HashMap/ s/Vector/ArrayList/ through all the I would agree that this type of conversion is of limmited value. It should probably happen, but it would be low on the priorety list I think. Use of Iterator rather than enumeration might be of some value, again from the standpoint of code clarity. old code, of which there is a frighteningly large amount, just for the sake of it. I know this is at odds with 'refactor mercilessly', but as Conor's test coverage data shows, we dont have the test coverage to refactor mercilessly :( Perhaps, rather than saying don't refactor until 1.7, (or will it be 2.1?) we should say if you want to refactor it, and it doesn't have a test case write the testcases before refactoring it?
