DO NOT REPLY [Bug 28228] - classloader task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28228. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28228 classloader task --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 08:27 --- It looks like some files are missing for the tar.gz file: the classloaders in the o.a.t.a.taskdefs.classloader package: AntClassLoaderAdapter SimpleClassLoaderAdapter URLClassLoaderAdapter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANT 1.7 features suggestion
I'm soo late for the party that I'll try to not restart the whole thing. On Tue, 04 May 2004, Anthony Goubard [EMAIL PROTECTED] wrote: 1) Integrate if and unless at the Task level. A nested condition would be far more powerful, as would be an if task. Don't expect any opinion from me. 8-) 3) Regexp conditions SMOP. If anybody wanted to code them up (using Ant's regexp engine abstraction layer, of course), I'm sure there wouldn't be any objections. 4) Add an overwrite attribute at the property task. Properties are immutable but sometimes I think that you would like to change a propety. I don't think this would be a good idea since immutability is something that the parent build file relies upon and adding the attribute would give the child build file control over it. An overwritable attribute that the parent could set would be more inline with the intent of Ant (why properties are immutable). Not that I was advocating it. Most cases where you've used antcall with param can be replaced by macrodef and your need to be mutable properties become attributes that way. I've found that this addresses most needs for mutable properties at the same time. 5) Merge some jar files Would defeat the reason why we've split up optional.jar in the first place. - I think that more than 50% of the users uses Java 1.4 and all the tasks that can be realized with 1.4 should be in the same jar file : xalan, xslp, swing, Some of our users run Kaffee with the swing classes for Java 1.1 from Sun. You may want to load the swing lib via a different classloader than main Ant. Same for TraX/Xalan and any JDK 1.4. 6) Get the properties from a target after antcall Would immediately break tons of builds that rely on throw-away properties during antcall if it became the default. You probably wouldn't want to keep all properties anyway, just a few of them. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
On Mon, 10 May 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Would the following solve this problem generically? !-- This task is automatically available for every ANTLIB and its only function is to force the loading of the library if necessary. Force the lazy loading. -- mylib:antlibresolve/ looks like a reasonable compromise. The alternative would be a built-in task that takes the antlib URI, this wouldn't even require any magic taskname. antlibresolve uri=.../ or even antlibresolve prefix=.../. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trapping RuntimeExceptions form Tasks
On Wed, 05 May 2004, Peter Reilly [EMAIL PROTECTED] wrote: I see verify errors sometimes with beanshell and groovy scripts. Because you are reloading classes which is a problem in its own. I think you'd better find a way to avoid these VerifyErrors instead of swallowing/ignoring them. 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANT 1.7 features suggestion
I'm soo late for the party that I'll try to not restart the whole thing. On Tue, 04 May 2004, Anthony Goubard [EMAIL PROTECTED] wrote: 1) Integrate if and unless at the Task level. A nested condition would be far more powerful, as would be an if task. Don't expect any opinion from me. 8-) 3) Regexp conditions SMOP. If anybody wanted to code them up (using Ant's regexp engine abstraction layer, of course), I'm sure there wouldn't be any objections. 4) Add an overwrite attribute at the property task. Properties are immutable but sometimes I think that you would like to change a propety. I don't think this would be a good idea since immutability is something that the parent build file relies upon and adding the attribute would give the child build file control over it. An overwritable attribute that the parent could set would be more inline with the intent of Ant (why properties are immutable). Not that I was advocating it. Most cases where you've used antcall with param can be replaced by macrodef and your need to be mutable properties become attributes that way. I've found that this addresses most needs for mutable properties at the same time. 5) Merge some jar files Would defeat the reason why we've split up optional.jar in the first place. - I think that more than 50% of the users uses Java 1.4 and all the tasks that can be realized with 1.4 should be in the same jar file : xalan, xslp, swing, Some of our users run Kaffee with the swing classes for Java 1.1 from Sun. You may want to load the swing lib via a different classloader than main Ant. Same for TraX/Xalan and any JDK 1.4. 6) Get the properties from a target after antcall Would immediately break tons of builds that rely on throw-away properties during antcall if it became the default. You probably wouldn't want to keep all properties anyway, just a few of them. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANT 1.7 features suggestion
On Tue, 04 May 2004, Alexey N. Solofnenko [EMAIL PROTECTED] wrote: Could you please also update if and unless to accept a list of properties? if=A, B would mean A is set and B is set or A is set or B is set? You know that propertiy names are allowed to contain spaces and commas and any other separator char we would invent? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant task and nested table
On 06 May 2004, Le Rumeur Yves [EMAIL PROTECTED] wrote: I read quicly the ant task list, but i never found a task which have a nestedtable needed. I'm not sure I follow what you are saying. apply requires at least one nested fileset/dirset or filelist. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trapping RuntimeExceptions form Tasks
Stefan Bodewig wrote: On Wed, 05 May 2004, Peter Reilly [EMAIL PROTECTED] wrote: I see verify errors sometimes with beanshell and groovy scripts. Because you are reloading classes which is a problem in its own. I think you'd better find a way to avoid these VerifyErrors instead of swallowing/ignoring them. 8-) For the verify error, the problem was that groovy and beanshell were generating invalid bytecode - hence the verify error. The notion is not to swallow / ignore them (unless the build script author wants to) but to wrap them in a build exception to possibly provide some information as to where the error happened - the line number of the build script from where the error happened for example. From a build author, the seeing of an error is a problem wherer due to a file not being present (using the src attribute) or a verify error in the byte code. Peter Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trapping RuntimeExceptions form Tasks
On Tue, 11 May 2004, Peter Reilly [EMAIL PROTECTED] wrote: The notion is not to swallow / ignore them (unless the build script author wants to) but to wrap them in a build exception to possibly provide some information as to where the error happened - the line number of the build script from where the error happened for example. OK, so I must have partly misunderstood that. I have no problem with adding location information (and which task caused the Error). What I really wouldn't feel comfortable with would be if Ant even optionally would swallow such an error. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlibs and classloaders #2
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Mon, 10 May 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Would the following solve this problem generically? !-- This task is automatically available for every ANTLIB and its only function is to force the loading of the library if necessary. Force the lazy loading. -- mylib:antlibresolve/ looks like a reasonable compromise. The alternative would be a built-in task that takes the antlib URI, this wouldn't even require any magic taskname. antlibresolve uri=.../ or even antlibresolve prefix=.../. I have no problem, one way or another, as long as I do not have to type the whole URI again ;-) This is why I want to use the NS prefix instead. Is there an way for the task to get the information needed (the URI)? Since a lot of this is resolved by the parser (prefix--uri) mapping, I was trying to make sure we do not get bog by the design. So as long as we can get the info necessary by just saying: antlibresolve prefix=mylib/ or antlibresolve mylib:ns=ignored value / In this second, we get the URI from ns attribute which is in that space. the implementation could use the new NS aware features that were added recently. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Trapping RuntimeExceptions form Tasks
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Wed, 05 May 2004, Peter Reilly [EMAIL PROTECTED] wrote: I see verify errors sometimes with beanshell and groovy scripts. Because you are reloading classes which is a problem in its own. I think you'd better find a way to avoid these VerifyErrors instead of swallowing/ignoring them. 8-) The problems with scripting are more fundamental. I in particular have had to jump over hoops because I have a beenshell script that creates a class object. Originally, every execution of the script was recreating the same class and making the classloader blow-up. Ideally, what you would want for this kind of languages is to give them a throw-away classloader in which they can add their class and that we can dispose afterwards is necessary. Of course, all the ANT interfaces and supporting classes would come from its parent classloader. Instead, in todays scenario, I need to invent new names everytime which is not nice. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Trapping RuntimeExceptions form Tasks
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Tue, 11 May 2004, Peter Reilly [EMAIL PROTECTED] wrote: The notion is not to swallow / ignore them (unless the build script author wants to) but to wrap them in a build exception to possibly provide some information as to where the error happened - the line number of the build script from where the error happened for example. OK, so I must have partly misunderstood that. I have no problem with adding location information (and which task caused the Error). This looks like something specific to the script tasks to look at and dealt with. I.e., catch VerifyErrors and convert them into BuildExceptions with any additional info. What I really wouldn't feel comfortable with would be if Ant even optionally would swallow such an error. Agreed. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/docs/manual/OptionalTasks junit.html
bodewig 2004/05/11 04:46:49 Modified:docs/manual/CoreTasks java.html docs/manual/OptionalTasks junit.html Log: Assertions require fork Revision ChangesPath 1.32 +2 -0 ant/docs/manual/CoreTasks/java.html Index: java.html === RCS file: /home/cvs/ant/docs/manual/CoreTasks/java.html,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- java.html 20 Apr 2004 12:48:43 - 1.31 +++ java.html 11 May 2004 11:46:49 - 1.32 @@ -250,6 +250,8 @@ a href=../CoreTypes/assertions.htmlttlt;assertionsgt;/tt/a subelement./p +pAssertion statements are currently ignored in non-forked mode./p + pemsince Ant 1.6./em/p a name=redirectorh4redirector/h4/a 1.37 +2 -0 ant/docs/manual/OptionalTasks/junit.html Index: junit.html === RCS file: /home/cvs/ant/docs/manual/OptionalTasks/junit.html,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- junit.html27 Apr 2004 07:45:34 - 1.36 +++ junit.html11 May 2004 11:46:49 - 1.37 @@ -290,6 +290,8 @@ a href=../CoreTypes/assertions.htmlttlt;assertionsgt;/tt/a subelement./p +pAssertion statements are currently ignored in non-forked mode./p + pemsince Ant 1.6./em/p h4formatter/h4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: assertions
On Sat, 08 May 2004, Yuji Yamano [EMAIL PROTECTED] wrote: I think the description of assertions in docs/manual/CoreTasks/java.html is not clear. Because we can use assertions only if fork=true. Maybe JUnit tasks's manual has same problem. Fixed, thanks. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/docs/manual/Integration VAJAntTool.html
bodewig 2004/05/11 04:53:07 Modified:docs/manual/Integration VAJAntTool.html Log: 2004 Revision ChangesPath 1.22 +1 -1 ant/docs/manual/Integration/VAJAntTool.html Index: VAJAntTool.html === RCS file: /home/cvs/ant/docs/manual/Integration/VAJAntTool.html,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- VAJAntTool.html 6 May 2004 09:08:43 - 1.21 +++ VAJAntTool.html 11 May 2004 11:53:07 - 1.22 @@ -562,7 +562,7 @@ td valign=top PAdded documentation for haltonerror, * and ** version qualifiers./P/TD/TR/TABLE hr -centerCopyright copy 2001-2003 Apache Software +centerCopyright copy 2001-2004 The Apache Software Foundation. All rights Reserved./CENTER /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
Let me get this right.. this task would define the antlib classes the
moment it is invoked, and it should be used on the top level buildfile,
this way the subbuilds/subants/ant/antcall targets have the antlib
already loaded, right?
I explain a bit my build files structure for testing:
we have a local/tests directory were all tests modules reside (20+), we
have a build.xml at the top level for global cleans builds, runs, etc,
and at the module dir, anothere build.xml for single module runs. I use
an import file=${basedir}/include/xml/ to define stuff at the module
level, and a import file=${basedir}/server-include.xml/ for global
tests runs.
Up to this moment I need to define the tasks in boths includes using
typedef uri= loaderref=... classpathref=.../ because I
cannot pass classpath to antlibs. I also added in both includes an
ifnotisset property=antlibs.define//notthen...the typedef
stuff. /if to do this only once for all the builds.
I use a lot of subant, antcall, ants and it is very difficult to control
in all the builds that the do use inheritall=true, since otherwise the
if would not find the property and redefine the tasks.
Could you put this structure as it would be in 1.6.2 with the
antlibresolve and antlib classpath, at least what you imagine it might be?
I like the antlibresolve solution, as long as it does not redefine the
tasks, or at least there is an option not to do so. Would it be possible
to add to typedef that possibility?
Thanks for the help on this matter.
MAriano
Jose Alberto Fernandez wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 10 May 2004, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
Would the following solve this problem generically?
!--
This task is automatically available for every ANTLIB
and its only function is to force the loading of the library
if necessary. Force the lazy loading.
--
mylib:antlibresolve/
looks like a reasonable compromise.
The alternative would be a built-in task that takes the
antlib URI, this wouldn't even require any magic taskname.
antlibresolve uri=.../ or even antlibresolve prefix=.../.
I have no problem, one way or another, as long as I do not have to type
the whole URI again ;-) This is why I want to use the NS prefix instead.
Is there an way for the task to get the information needed (the URI)?
Since a lot of this is resolved by the parser (prefix--uri) mapping,
I was trying to make sure we do not get bog by the design. So as long as
we can get the info necessary by just saying:
antlibresolve prefix=mylib/
or
antlibresolve mylib:ns=ignored value /
In this second, we get the URI from ns attribute which is in that
space.
the implementation could use the new NS aware features that were added
recently.
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]
DO NOT REPLY [Bug 28897] New: - Enhance the Replace task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28897. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28897 Enhance the Replace task Summary: Enhance the Replace task Product: Ant Version: 1.6.1 Platform: PC OS/Version: Windows XP Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Hi, The other day, I add some problem with the Replace task because it's case sensitive. It would be really nice to have an option for the case sensitive. I guess the default should be Yes. This way, it will not affect the old code. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28897] - Enhance the Replace task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28897. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28897 Enhance the Replace task --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 13:00 --- Why not using the replaceregexp flags=i? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
native2ascii
Hi i'm using ant under eclipse and i want to use native2ascii task to convert some files but it doesn' work. this is what i write ?xml version=1.0 encoding=UTF-8? project name=native2ascii default=Native2ascii basedir=. taskdef name=native2ascii classname=org.apache.tools.ant.taskdefs.optional.Native2Ascii/ !--convert the file Application.properties from UTF8 encoding to ascii encoding -- target name=Native2ascii native2ascii encoding=UTF8 src=./src/etc/resources dest=. ext=.ascii/ /target !-- delete the file -- target name=clean delete file=./src/etc/resources/*/ /target /project thanks for help
Re: ANT 1.7 features suggestion
Frequently I need several properties to be checked to enable or disable a target. A boolean expression would be much better than a list of properties, but I would be happy with just a list. I think if should have inside and unless should have ||. - Alexey. Stefan Bodewig wrote: On Tue, 04 May 2004, Alexey N. Solofnenko [EMAIL PROTECTED] wrote: Could you please also update if and unless to accept a list of properties? if=A, B would mean A is set and B is set or A is set or B is set? You know that propertiy names are allowed to contain spaces and commas and any other separator char we would invent? 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: ANT 1.7 features suggestion
Ok, what is wrong with using if/? Besides, lookfeel. Jose Alberto -Original Message- From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED] Sent: 11 May 2004 15:33 To: Ant Developers List Subject: Re: ANT 1.7 features suggestion Frequently I need several properties to be checked to enable or disable a target. A boolean expression would be much better than a list of properties, but I would be happy with just a list. I think if should have inside and unless should have ||. - Alexey. Stefan Bodewig wrote: On Tue, 04 May 2004, Alexey N. Solofnenko [EMAIL PROTECTED] wrote: Could you please also update if and unless to accept a list of properties? if=A, B would mean A is set and B is set or A is set or B is set? You know that propertiy names are allowed to contain spaces and commas and any other separator char we would invent? 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANT 1.7 features suggestion
I do use it also. Do you know whether it will become a part of main ANT? - Alexey. Jose Alberto Fernandez wrote: Ok, what is wrong with using if/? Besides, lookfeel. Jose Alberto -Original Message- From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED] Sent: 11 May 2004 15:33 To: Ant Developers List Subject: Re: ANT 1.7 features suggestion Frequently I need several properties to be checked to enable or disable a target. A boolean expression would be much better than a list of properties, but I would be happy with just a list. I think if should have inside and unless should have ||. - Alexey. Stefan Bodewig wrote: On Tue, 04 May 2004, Alexey N. Solofnenko [EMAIL PROTECTED] wrote: Could you please also update if and unless to accept a list of properties? if=A, B would mean A is set and B is set or A is set or B is set? You know that propertiy names are allowed to contain spaces and commas and any other separator char we would invent? 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] - 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: antlibs and classloaders #2
From: Mariano Benitez [mailto:[EMAIL PROTECTED] Let me get this right.. this task would define the antlib classes the moment it is invoked, and it should be used on the top level buildfile, this way the subbuilds/subants/ant/antcall targets have the antlib already loaded, right? I explain a bit my build files structure for testing: [snip...] Up to this moment I need to define the tasks in boths includes using typedef uri= loaderref=... classpathref=.../ because I cannot pass classpath to antlibs. I also added in both includes an ifnotisset property=antlibs.define//notthen...the typedef stuff. /if to do this only once for all the builds. I use a lot of subant, antcall, ants and it is very difficult to control in all the builds that the do use inheritall=true, since otherwise the if would not find the property and redefine the tasks. Here I would advocate to have the new condition isDefined/ that I mentioned before. Which will not rely on inheritAll but will look at the definintion dictionalries directly. Could you put this structure as it would be in 1.6.2 with the antlibresolve and antlib classpath, at least what you imagine it might be? I like the antlibresolve solution, as long as it does not redefine the tasks, or at least there is an option not to do so. Would it be possible to add to typedef that possibility? antlibresolve/ the only thing it does is make sure the antlib URI gets processed. As if you were calling task in the space of the antlib. Actually on the incarnation as mylib:antlibresolve/ it would have been a noop task whose only side-effect is causing the loading of the antlib. If you call it 20 times it would only load the antlib the first time, like any other task would. (humm this may be still the best solution, just make every antlib define this task). How to deal with your classloaders, that is a different thing completely. - Is it possible to define them inside the antlib (or are they buildfile dependent)? - I had proposed in the past a naming convention to associate a classpath/loader with a particular URI. But all this is just open talk at the moment. - Maybe antlibresolve/ can do some of this, but then its definition is not as clean as one would want. Jose Alberto Thanks for the help on this matter. MAriano Jose Alberto Fernandez wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Mon, 10 May 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Would the following solve this problem generically? !-- This task is automatically available for every ANTLIB and its only function is to force the loading of the library if necessary. Force the lazy loading. -- mylib:antlibresolve/ looks like a reasonable compromise. The alternative would be a built-in task that takes the antlib URI, this wouldn't even require any magic taskname. antlibresolve uri=.../ or even antlibresolve prefix=.../. I have no problem, one way or another, as long as I do not have to type the whole URI again ;-) This is why I want to use the NS prefix instead. Is there an way for the task to get the information needed (the URI)? Since a lot of this is resolved by the parser (prefix--uri) mapping, I was trying to make sure we do not get bog by the design. So as long as we can get the info necessary by just saying: antlibresolve prefix=mylib/ or antlibresolve mylib:ns=ignored value / In this second, we get the URI from ns attribute which is in that space. the implementation could use the new NS aware features that were added recently. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ANT 1.7 features suggestion
From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED] I do use it also. Do you know whether it will become a part of main ANT? So why you feel unconfortable about using if/ is the fact that is not part of the supported CORE of ANT. Is that it? That may give some food for thought, to the committers (me included). Jose Alberto - Alexey. Jose Alberto Fernandez wrote: Ok, what is wrong with using if/? Besides, lookfeel. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/docs resources.html
jhm 2004/05/11 08:54:04 Modified:xdocsresources.xml docs resources.html Log: New article about Ant in Java-Spektrum 5/04. Revision ChangesPath 1.35 +20 -2 ant/xdocs/resources.xml Index: resources.xml === RCS file: /home/cvs/ant/xdocs/resources.xml,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- resources.xml 29 Feb 2004 08:43:54 - 1.34 +++ resources.xml 11 May 2004 15:54:04 - 1.35 @@ -253,8 +253,26 @@ section name=Articles - subsection name=Ant in Anger: Using Ant in a Production Development - System + subsection name=Programmieren für Ant +pThis article describes the main topics of programming your own tasks. +Description is done on five examples./p +pThis article is written in German and published in +a href=http://www.sigs-datacom.de/sd/publications/js/index.htm;Java-Spektrum/a +5/2004./p + +table class=externals + tr +thAuthor:/th +tdBernd Matzke/td + /tr + tr +thURL:/th +tda href=http://www.sigs-datacom.de/sd/news/document?PID=216;http://www.sigs-datacom.de/sd/news/document?PID=216/a/td + /tr +/table + /subsection + + subsection name=Ant in Anger: Using Ant in a Production Development System pThis document describes strategies and some basic examples of how to use Ant in larger team development projects./p 1.74 +33 -2 ant/docs/resources.html Index: resources.html === RCS file: /home/cvs/ant/docs/resources.html,v retrieving revision 1.73 retrieving revision 1.74 diff -u -r1.73 -r1.74 --- resources.html29 Feb 2004 08:43:54 - 1.73 +++ resources.html11 May 2004 15:54:04 - 1.74 @@ -509,8 +509,39 @@ Articles /h3 h4 class=subsection -a name=Ant in Anger: Using Ant in a Production Development System/a -Ant in Anger: Using Ant in a Production Development System +a name=Programmieren für Ant/a +Programmieren für Ant + /h4 +pThis article describes the main topics of programming your own tasks. +Description is done on five examples./p +pThis article is written in German and published in +a href=http://www.sigs-datacom.de/sd/publications/js/index.htm;Java-Spektrum/a +5/2004./p + table class=externals cellspacing=1 cellpadding=4 + tr + th colspan=1 rowspan=1 + valign=top align=left + Author: + /th + td colspan=1 rowspan=1 + valign=top align=left + Bernd Matzke + /td + /tr + tr + th colspan=1 rowspan=1 + valign=top align=left + URL: + /th + td colspan=1 rowspan=1 + valign=top align=left + a href=http://www.sigs-datacom.de/sd/news/document?PID=216;http://www.sigs-datacom.de/sd/news/document?PID=216/a + /td + /tr +/table +h4 class=subsection +a name=Ant in Anger: Using Ant in a Production Development System/a +Ant in Anger: Using Ant in a Production Development System /h4 pThis document describes strategies and some basic examples of how to use Ant in larger team development projects./p - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13652] - RFE: Permit that apply parameter output can be set to targetfile
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=13652. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=13652 RFE: Permit that apply parameter output can be set to targetfile [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6.2 --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 16:04 --- With the redirector in Ant 1.6.2 this issue can be laid at rest. mapper id=out type=glob from=*.m4 to=*.sql / apply executable=m4 dest=. fileset dir=. includes=*.m4/ mapper refid=out / redirector outputmapper refid=out / /redirector /apply should take care of all .m4 files. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANT 1.7 features suggestion
Actually if is too wordy. A mall target if=XXX is translated into target if isset property=XXX/ then /then /if /target Complex conditions are big. A small expression language like XXX YYY would be much nicer. - Alexey. Jose Alberto Fernandez wrote: From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED] I do use it also. Do you know whether it will become a part of main ANT? So why you feel unconfortable about using if/ is the fact that is not part of the supported CORE of ANT. Is that it? That may give some food for thought, to the committers (me included). Jose Alberto - Alexey. Jose Alberto Fernandez wrote: Ok, what is wrong with using if/? Besides, lookfeel. 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: ANT 1.7 features suggestion
From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED] Actually if is too wordy. A mall target if=XXX is translated into Complex conditions are big. A small expression language like XXX YYY would be much nicer. I so agree with you! That expression language could (should IMHO!) be XPath (JXpath or Jaxen are candidates, or the Xalan one?) where Ant properties would be available as XPath properties, and some of Ant's condition made into XPath functions. We'd be restricted to boolean XPath expressions only, and have no access to any DOM tree initially, allow I would actually like to be able to navigate the DOM of the build file (but that's another story). So Ant would have an XML friendly, very well defined and documented expression language. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlibs and classloaders #2
Jose Alberto Fernandez wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Mon, 10 May 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Would the following solve this problem generically? !-- This task is automatically available for every ANTLIB and its only function is to force the loading of the library if necessary. Force the lazy loading. -- mylib:antlibresolve/ looks like a reasonable compromise. The alternative would be a built-in task that takes the antlib URI, this wouldn't even require any magic taskname. antlibresolve uri=.../ or even antlibresolve prefix=.../. I have no problem, one way or another, as long as I do not have to type the whole URI again ;-) This is why I want to use the NS prefix instead. Is there an way for the task to get the information needed (the URI)? Since a lot of this is resolved by the parser (prefix--uri) mapping, I was trying to make sure we do not get bog by the design. So as long as we can get the info necessary by just saying: antlibresolve prefix=mylib/ This is not currently possible. The prefix-uri mapping is only retained for the element names and the tag names (using the NS dynamic con (The ant-type attribute is the only exception, but this is implemented by a horrid cludge, the parser knows about ant-type and substitutes the value in). or antlibresolve mylib:ns=ignored value / In this second, we get the URI from ns attribute which is in that space. the implementation could use the new NS aware features that were added recently. I assume you mean the NS aware dymanic configurator patch. The second form of the antlibresolve task could use to implement the antlib:ns style attribute, but it feels like a cludge. Peter 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]
cvs commit: ant/docs faq.html
jhm 2004/05/11 09:37:02
Modified:xdocsfaq.xml
docs faq.html
Log:
hint to projects.xml; os-specific configuration
Revision ChangesPath
1.54 +22 -1 ant/xdocs/faq.xml
Index: faq.xml
===
RCS file: /home/cvs/ant/xdocs/faq.xml,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- faq.xml 20 Apr 2004 07:27:21 - 1.53
+++ faq.xml 11 May 2004 16:37:02 - 1.54
@@ -223,6 +223,23 @@
/faqsection
faqsection title=How do I ...
+faq id=implement-os-specific-configuration
+ questionHow do I realize os--specific configurations?/question
+ answer
+pThe core idea is using property files which name accords to the
+os-name. Then simply use the build-in property ttos.name/tt./p
+pFor better use you should also provide a file with defaul values.
+But be careful with the correct os-names. For test simply
lt;echogt;
+the ${os.name} on all machines and you can be sure to use the right
+file names./p
+source![CDATA[
+ property file=${os.name}.properties/
+ property file=default.properties/
+]]/source
+ /answer
+/faq
+
+
faq id=adding-external-tasks
questionHow do I add an external task that Iapos;ve written to the
page quot;External Tools and Taskquot;?/question
@@ -252,8 +269,12 @@
href=http://cvs.apache.org/viewcvs.cgi/~checkout~/ant/xdocs/external.xml;this/a
document./p
+pIf you have written something bigger than a 'simple plugin' to
Ant it
+may be better to add the link to a
href=projects.htmlprojects.html/a.
+The procedure to add it is the same. The file to patch is a
+
href=http://cvs.apache.org/viewcvs.cgi/~checkout~/ant/xdocs/projects.xml;this/a
+document. The syntax of that file is the same./p
/answer
-
/faq
faq id=passing-cli-args
1.98 +21 -0 ant/docs/faq.html
Index: faq.html
===
RCS file: /home/cvs/ant/docs/faq.html,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -r1.97 -r1.98
--- faq.html 20 Apr 2004 07:27:20 - 1.97
+++ faq.html 11 May 2004 16:37:02 - 1.98
@@ -206,6 +206,9 @@
/ul
h4 class=tocHow do I .../h4
ul
+lia href=#implement-os-specific-configuration
+ How do I realize os--specific configurations?
+ /a/li
lia href=#adding-external-tasks
How do I add an external task that I've written to the
page External Tools and Task?
@@ -589,6 +592,20 @@
or use the zip archive instead (you can extract it using
codejar xf/code)./p
p class=faq
+ a name=implement-os-specific-configuration/a
+ How do I realize os--specific configurations?
+/p
+ pThe core idea is using property files which name
accords to the
+os-name. Then simply use the build-in property ttos.name/tt./p
+pFor better use you should also provide a file
with defaul values.
+But be careful with the correct os-names. For test simply
lt;echogt;
+the ${os.name} on all machines and you can be sure to use the right
+file names./p
+pre class=code
+ lt;property file=quot;${os.name}.propertiesquot;/gt;
+ lt;property file=quot;default.propertiesquot;/gt;
+/pre
+p class=faq
a name=adding-external-tasks/a
How do I add an external task that I've written to the
page External Tools and Task?
@@ -613,6 +630,10 @@
/ul
pThe preferred format for this information is a
patch to a
href=http://cvs.apache.org/viewcvs.cgi/~checkout~/ant/xdocs/external.xml;this/a
document./p
+pIf you have written something bigger than a
'simple plugin' to Ant it
+may be better to add the link to a
href=projects.htmlprojects.html/a.
+The procedure to add it is the same. The file to patch is a
href=http://cvs.apache.org/viewcvs.cgi/~checkout~/ant/xdocs/projects.xml;this/a
+document. The syntax of that file is the same./p
p class=faq
a name=passing-cli-args/a
How do I pass parameters from the command line to my
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs DefBase.java
peterreilly2004/05/11 09:49:48
Modified:src/main/org/apache/tools/ant/taskdefs DefBase.java
Log:
antlib: allow a typedef in an antlib to override the classpath
unittests to follow
Revision ChangesPath
1.11 +20 -13ant/src/main/org/apache/tools/ant/taskdefs/DefBase.java
Index: DefBase.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/DefBase.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- DefBase.java 9 Mar 2004 16:48:04 - 1.10
+++ DefBase.java 11 May 2004 16:49:48 - 1.11
@@ -42,7 +42,7 @@
* @ant.attribute ignore=true
*/
public void setReverseLoader(boolean reverseLoader) {
-this.cpDelegate.setReverseLoader(reverseLoader);
+getDelegate().setReverseLoader(reverseLoader);
log(The reverseloader attribute is DEPRECATED. It will be removed,
Project.MSG_WARN);
}
@@ -51,14 +51,14 @@
* @return the classpath for this definition
*/
public Path getClasspath() {
-return cpDelegate.getClasspath();
+return getDelegate().getClasspath();
}
/**
* @return the reverse loader attribute of the classpath delegate.
*/
public boolean isReverseLoader() {
-return cpDelegate.isReverseLoader();
+return getDelegate().isReverseLoader();
}
/**
@@ -66,7 +66,7 @@
* @return the loader id
*/
public String getLoaderId() {
-return cpDelegate.getClassLoadId();
+return getDelegate().getClassLoadId();
}
/**
@@ -74,7 +74,7 @@
* @return the class path id
*/
public String getClasspathId() {
-return cpDelegate.getClassLoadId();
+return getDelegate().getClassLoadId();
}
/**
@@ -83,7 +83,7 @@
* @param classpath an Ant Path object containing the classpath.
*/
public void setClasspath(Path classpath) {
-this.cpDelegate.setClasspath(classpath);
+getDelegate().setClasspath(classpath);
}
/**
@@ -92,7 +92,7 @@
* @return the classpath of the this definition
*/
public Path createClasspath() {
-return this.cpDelegate.createClasspath();
+return getDelegate().createClasspath();
}
/**
@@ -101,7 +101,7 @@
* @param r the reference to the classpath
*/
public void setClasspathRef(Reference r) {
-this.cpDelegate.setClasspathref(r);
+getDelegate().setClasspathref(r);
}
/**
@@ -117,7 +117,7 @@
* @since Ant 1.5
*/
public void setLoaderRef(Reference r) {
-this.cpDelegate.setLoaderRef(r);
+getDelegate().setLoaderRef(r);
}
/**
@@ -125,11 +125,14 @@
* @return the classloader from the cpDelegate
*/
protected ClassLoader createLoader() {
-if (getAntlibClassLoader() != null) {
+if (getAntlibClassLoader() != null cpDelegate == null) {
return getAntlibClassLoader();
}
+if (cpDelegate == null) {
+cpDelegate = ClasspathUtils.getDelegate(this);
+}
if (createdLoader == null) {
-createdLoader = this.cpDelegate.getClassLoader();
+createdLoader = cpDelegate.getClassLoader();
// need to load Task via system classloader or the new
// task we want to define will never be a Task but always
// be wrapped into a TaskAdapter.
@@ -144,9 +147,13 @@
* @since Ant 1.6
*/
public void init() throws BuildException {
-this.cpDelegate = ClasspathUtils.getDelegate(this);
super.init();
}
-
+private ClasspathUtils.Delegate getDelegate() {
+if (cpDelegate == null) {
+cpDelegate = ClasspathUtils.getDelegate(this);
+}
+return cpDelegate;
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: ANT 1.7 features suggestion
So, would something like:
ifThen test=isset('XXX') '${a}' = '${b}'
/ifThen
Not that I am proposing something concrete.
But this would require defining a proper expression evaluation language
for it.
This would be equivalent to the more verbose:
if
and
isset property=XXX/
equals arg1=${a} arg2=${b}/
/and
then
/then
/if
Or something simillar. But this is not something simple at all.
Jose Alberto
-Original Message-
From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
Sent: 11 May 2004 17:10
To: Ant Developers List
Subject: Re: ANT 1.7 features suggestion
Actually if is too wordy. A mall target if=XXX is
translated into
target
if
isset property=XXX/
then
/then
/if
/target
Complex conditions are big. A small expression language like XXX
YYY would be much nicer.
- Alexey.
Jose Alberto Fernandez wrote:
From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
I do use it also. Do you know whether it will become a part
of main ANT?
So why you feel unconfortable about using if/ is the fact
that is not
part of the supported CORE of ANT. Is that it?
That may give some food for thought, to the committers (me included).
Jose Alberto
- Alexey.
Jose Alberto Fernandez wrote:
Ok, what is wrong with using if/?
Besides, lookfeel.
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANT 1.7 features suggestion
It is also not that complex. I have done it before, but there are now a
lot of expression languages and we should not invent yet another. Maybe
something like this:
test=jython: isset('XXX') and '${a}'=='${b}'
could be used.
- Alexey.
Jose Alberto Fernandez wrote:
So, would something like:
ifThen test=isset('XXX') '${a}' = '${b}'
/ifThen
Not that I am proposing something concrete.
But this would require defining a proper expression evaluation language
for it.
This would be equivalent to the more verbose:
if
and
isset property=XXX/
equals arg1=${a} arg2=${b}/
/and
then
/then
/if
Or something simillar. But this is not something simple at all.
Jose Alberto
-Original Message-
From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
Sent: 11 May 2004 17:10
To: Ant Developers List
Subject: Re: ANT 1.7 features suggestion
Actually if is too wordy. A mall target if=XXX is
translated into
target
if
isset property=XXX/
then
/then
/if
/target
Complex conditions are big. A small expression language like XXX
YYY would be much nicer.
- Alexey.
Jose Alberto Fernandez wrote:
From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
I do use it also. Do you know whether it will become a part
of main ANT?
So why you feel unconfortable about using if/ is the fact
that is not
part of the supported CORE of ANT. Is that it?
That may give some food for thought, to the committers (me included).
Jose Alberto
- Alexey.
Jose Alberto Fernandez wrote:
Ok, what is wrong with using if/?
Besides, lookfeel.
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]
-
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 features suggestion
Jack J. Woehr wrote: Hmm, this is something interesting for Ant in itself. expr expression=27 / 3 = nine property=my.expression.result truevalue=yes was 9 / Is there an expression evaluating jar that could be added to optional? There's the Math task in Ant-Contrib which does part of this. And script -- Jack J. Woehr # We have gone from the horse and buggy Senior Consultant # to the moon rocket in one lifetime, but Purematrix, Inc. # there has not been a corresponding moral www.purematrix.com # growth in mankind. - Dwight D. Eisenhower - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28773] - .Net resource should accept fileset.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28773 .Net resource should accept fileset. --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 20:16 --- Created an attachment (id=11515) proposed patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28773] - .Net resource should accept fileset.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28773. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28773 .Net resource should accept fileset. --- Additional Comments From [EMAIL PROTECTED] 2004-05-11 20:17 --- This is a patch to look if approach is acceptable. There seems another problem - resources are not considered when checking dependencies. I will post another patch for that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
