DO NOT REPLY [Bug 24024] New: - Definer could load all antlibs matching a resource path
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=24024. 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=24024 Definer could load all antlibs matching a resource path Summary: Definer could load all antlibs matching a resource path Product: Ant Version: 1.6Beta Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If you call taskdef classpath=... resource=foo/antlib.xml uri=antlib:foo/ or just start using sometask xmlns=antlib:foo/ with foo/antlib.xml in the classpath, currently it seems that Definer will only look for one instance of the resource foo/antlib.xml. If there are multiple JARs in the classpath containing foo/antlib.xml, only one of them (acc. to classpath order) will actually be loaded. IMHO probably all of them should be loaded. But I am not sure if the current behavior is intentional or simply an oversight. If an oversight, I would be willing to supply a patch. Should be pretty trivial: Definer.resourceToURL should call ClassLoader.getAllResources() and return EnumerationURL and Definer.execute() should simply iterate over each URL and otherwise behave as now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23987] - scp task doesn't complain if remote directory is not specified
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=23987. 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=23987 scp task doesn't complain if remote directory is not specified --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 01:39 --- I'm using jsch 0.1.8, ant1.6beta2. I've tried running this with a win2k client and a redhat7.3 client with the same result. Both are connecting to a rh7.3 machine. ssh -V on the server machine gives: OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f I'll see if I can find another version to test against. What version are you using? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23987] - scp task doesn't complain if remote directory is not specified
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=23987. 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=23987 scp task doesn't complain if remote directory is not specified --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 02:07 --- The behaviour is the same to debian woody remote host, where ssh -V gives: OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3, SSH protocols 1.5/2.0, OpenSSL 0x0090603f - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22904] - [Patch] to download some third party libraries (not complete)
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=22904. 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=22904 [Patch] to download some third party libraries (not complete) --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 03:30 --- Created an attachment (id=8684) Updated patch with new URLs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote: local for 1.6
I agree that property doesn't work well with macro and some other
use cases.
I'm +1 on local if we can keep it separated from property, so the
behavior of property doesn't change. I think it may be a good idea to
even throw an exception if some name is used with both local and property.
I wouldn't mind even a var that is local + modifiable.
I don't like the second example where local seems to be used to declare
filepath that is later defined as a property.
Another approach is to use namespaces for properties - IMO that's a cleaner
solution, but has the disadvantage that overloads property behavior.
( a local:foo property name will imply a local lifecycle, a att:foo could
be used for a modifiable property, etc ). I know this isn't very popular :-)
Costin
peter reilly wrote:
On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
On 22 Oct 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
I haven't made up my mind on the feature itself
OK, re-reading the description first, I don't like the
,
| The value part of local is optional, and the local
| property may be set by a subsequent property, property
| will only set it if the value is not set.
`
part. This means that whenever I find a property task I'll have to
search all possible scopes for a local element and can't rely on it
being global.
What is the benefit of making property adhere to the scoping set up
by local?
The point is that all tasks including property see the local
properties as normal properties.
It means that the macro attributes are now seen as normal
properties by the tasks that are contained within the sequential
nested element.
The local makes a property of the same kind as the macro attribute.
A common use case for this is when converting an antcall to a macro:
I had a target that was used as an antcall target, it used a property
suite.pattern to contain a regex what was used a number of times
in the target and as an ant call was done to invoke the target, this
was not seen outside the target. On conversion to a macrodef, the
property suite.pattern is now a global property and the macrodef
may fail unexpectly.
With local the macro now looks like this:
!--
macro to generate test suites registing
@param gen.dir the dir to place the register_suites.h and .cpp
files @param unit.dir the dir that the unit_*.cpp files are located
--
macrodef name=gen-register-suites
attribute name=gen.dir/
attribute name=unit.dir/
sequential
local name=suite.pattern value=^ *SUITE\(.*,\s*(.*)\s*\)/
mkdir dir=${gen.dir}/
...
/sequential
/macrodef
Another common use case is use of a local to pass information from one
task to another without messing up global properties or similar properties
used in other targets (say in a complicated build with a number of imports
and lots of targets).
local name=filepath/
pathconvert property=filepath targetos=unix
refid=files.path/
echothe files in files.path are ${filepath}/echo
However I can see the problem of looking at a script and not knowing if
the property is local or global.
The last patch allowed [sub]ant[call] to inherit the local properties.
I propose to change the local so that this inheriatance is removed and
also that macro instances do not inherit the local properites - i.e.
the local properties are staticlly scoped in the build script.
So currently the following is the case:
property name=p value=global/
macrodef name=inner
sequential
echop is ${p}/echo
/sequential
/macrodef
macrodef name=outer
attribute name=p/
sequential
inner/
/sequential
/macrodef
outer p=from macro/
Will generate p is from macro which is probally not expected as
inner was not explicilty passed the property by outer and inner
may be in another file or in an antlib.xml.
Peter
I don't have any strong objections against the rest or the
implementation.
So +0.5 (which can be turned into a +0.9 by explaining why property
should care about scopes 8-).
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: Vote: local for 1.6
On Wed, 22 Oct 2003, Steve Loughran [EMAIL PROTECTED] wrote: How about we make the sshexec timeouts seconds instead of ms? We are inconsistent with the timeout attribute between different tasks. exec, java, junit and sshexec use milliseconds, telnet uses seconds. I understand that some people may migrate from telnet to sshexec and may get bitten by the difference, but milliseconds is what the majority of other Ant tasks use. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24024] - Definer could load all antlibs matching a resource path
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=24024. 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=24024 Definer could load all antlibs matching a resource path --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 08:07 --- This was something that I was thinking of doing in the 1.7 timeframe, but it was an oversight.. The change could/would affect taskdef/typedef resource=x / as this is the mechanism that does the loading. This would affect current scripts that use resources to load in definitions (this is most likely a good thing). It may be a useful thing to do now for 1.6. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML, XSL, and Ant
On Wed, 22 Oct 2003, Kyle Adams [EMAIL PROTECTED] wrote: 1) xmlcatalog only applies to source XML document - if there are entities/dtds in the stylesheet, these can't be resolved by xmlcatalog. Confirmed on Ant 1.5.3/Xalan 2.2, D11/Xerces 2.3.0 and Ant 1.6, B2/Xalan 2.5.1/Xerces 2.5.0/10-22-2003 snapshot of commons-resolver. 2) Any XML documents accessed via the document() function in the XSL will not have their entities/dtds resolved. Confirmed on Ant 1.5.3/Xalan 2.2, D11/Xerces 2.3.0 I've read a thread (on [EMAIL PROTECTED] or [EMAIL PROTECTED]) that talked about which resolver gets used under what circumstances. You can set the URIResolver at the TransformerFactory level as well as at the Transformer level (and Ant should set it at both levels on my reading of the code). My JDK 1.4 javadocs (a bit outdated) state , | is used by default during the transformation to resolve URIs used in | xsl:import, or xsl:include. ` at TransformerFactory#setURIResolver and , | is used by default during the transformation to resolve URIs used in | document(), xsl:import, or xsl:include. ` at TransformerFactory#getURIResolver - so it contradicts itself when it comes to document(). I have no idea how it is implemented in Xalan. The methods in Transformer both state it would be used for document() only. Neither says anything about entities. We set the catalog as entity resolver for the document explicitly but currently use a StreamSource for the stylesheet which doesn't give us a chance to plug in the entity resolver. We should be able to change this if SAXSource is supported, I'll take a stab at it - but I will need testers before I'm willing to merge my changes into the 1.6 branch. If I'd send you a changed ant-trax.jar, could you test it in your Ant 1.6beta environment? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional TraXLiaison.java
bodewig 2003/10/23 01:43:22
Modified:src/main/org/apache/tools/ant/taskdefs/optional
TraXLiaison.java
Log:
Register xmlcatalog as entity resolver for the stylesheet as well
Revision ChangesPath
1.31 +9 -8
ant/src/main/org/apache/tools/ant/taskdefs/optional/TraXLiaison.java
Index: TraXLiaison.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/TraXLiaison.java,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- TraXLiaison.java 17 Sep 2003 20:11:43 - 1.30
+++ TraXLiaison.java 23 Oct 2003 08:43:22 - 1.31
@@ -64,6 +64,7 @@
import java.io.OutputStream;
import java.util.Vector;
import java.util.Enumeration;
+import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import javax.xml.transform.ErrorListener;
import javax.xml.transform.Source;
@@ -86,6 +87,7 @@
import org.apache.tools.ant.util.JAXPUtils;
import org.xml.sax.EntityResolver;
import org.xml.sax.InputSource;
+import org.xml.sax.SAXException;
import org.xml.sax.XMLReader;
/**
@@ -199,7 +201,8 @@
* @return the configured source instance matching the stylesheet.
* @throws Exception if there is a problem creating the source.
*/
-private Source getSource(InputStream is, File infile) throws Exception {
+private Source getSource(InputStream is, File infile)
+throws ParserConfigurationException, SAXException {
// todo: is this comment still relevant ??
// FIXME: need to use a SAXSource as the source for the transform
// so we can plug in our own entity resolver
@@ -216,6 +219,8 @@
+ parser doesn't support SAX);
}
} else {
+// WARN: Don't use the StreamSource(File) ctor. It won't work
with
+// xalan prior to 2.2 because of systemid bugs.
src = new StreamSource(is);
}
src.setSystemId(JAXPUtils.getSystemId(infile));
@@ -226,9 +231,8 @@
* Read in templates from the stylesheet
*/
private void readTemplates()
-throws IOException, TransformerConfigurationException {
-// WARN: Don't use the StreamSource(File) ctor. It won't work with
-// xalan prior to 2.2 because of systemid bugs.
+throws IOException, TransformerConfigurationException,
+ ParserConfigurationException, SAXException {
// Use a stream so that you can close it yourself quickly
// and avoid keeping the handle until the object is garbaged.
@@ -239,10 +243,7 @@
xslStream
= new BufferedInputStream(new FileInputStream(stylesheet));
templatesModTime = stylesheet.lastModified();
-StreamSource src = new StreamSource(xslStream);
-// Always set the systemid to the source for imports, includes...
-// in xsl and xml...
-src.setSystemId(JAXPUtils.getSystemId(stylesheet));
+Source src = getSource(xslStream, stylesheet);
templates = getFactory().newTemplates(src);
} finally {
if (xslStream != null) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/xdocs external.xml
bodewig 2003/10/23 02:01:30 Modified:docs external.html xdocsexternal.xml Log: Add pointer to ImTask, Submitted by Jon Madison Revision ChangesPath 1.143 +48 -0 ant/docs/external.html Index: external.html === RCS file: /home/cvs/ant/docs/external.html,v retrieving revision 1.142 retrieving revision 1.143 diff -u -r1.142 -r1.143 --- external.html 21 Oct 2003 05:38:36 - 1.142 +++ external.html 23 Oct 2003 09:01:30 - 1.143 @@ -1249,6 +1249,54 @@ /tr /table h4 class=subsection +a name=ImTask/a +ImTask + /h4 +pImTask is a task to allow one to send an Instant +Message. Currently supports yahoo!, AIM, and Jabber/p + table class=externals cellspacing=1 cellpadding=4 + tr + th colspan=1 rowspan=1 + valign=top align=left + Compatibility: + /th + td colspan=1 rowspan=1 + valign=top align=left + Ant 1.5 or higher + /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://imtask.sourceforge.net/;http://imtask.sourceforge.net/a + /td + /tr + tr + th colspan=1 rowspan=1 + valign=top align=left + Contact: + /th + td colspan=1 rowspan=1 + valign=top align=left + a href=mailto:[EMAIL PROTECTED]Jon Madison/a + /td + /tr + tr + th colspan=1 rowspan=1 + valign=top align=left + License: + /th + td colspan=1 rowspan=1 + valign=top align=left + GNU LGPL + /td + /tr +/table +h4 class=subsection a name=Interactive/a Interactive /h4 1.105 +26 -0 ant/xdocs/external.xml Index: external.xml === RCS file: /home/cvs/ant/xdocs/external.xml,v retrieving revision 1.104 retrieving revision 1.105 diff -u -r1.104 -r1.105 --- external.xml 21 Oct 2003 05:38:36 - 1.104 +++ external.xml 23 Oct 2003 09:01:30 - 1.105 @@ -607,6 +607,32 @@ /table /subsection + subsection name=ImTask + +pImTask is a task to allow one to send an Instant +Message. Currently supports yahoo!, AIM, and Jabber/p + + +table class=externals + tr +thCompatibility:/th +tdAnt 1.5 or higher/td + /tr + tr +thURL:/th +tda href=http://imtask.sourceforge.net/;http://imtask.sourceforge.net/a/td + /tr + tr +thContact:/th +tda href=mailto:[EMAIL PROTECTED]Jon Madison/a/td + /tr + tr +thLicense:/th +tdGNU LGPL/td + /tr +/table + /subsection + subsection name=Interactive pTask allowing to run a dialog within a build used to setup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/xdocs external.xml
bodewig 2003/10/23 02:02:24 Modified:docs Tag: ANT_16_BRANCH external.html xdocsTag: ANT_16_BRANCH external.xml Log: Merge from HEAD Revision ChangesPath No revision No revision 1.136.2.1 +48 -0 ant/docs/external.html Index: external.html === RCS file: /home/cvs/ant/docs/external.html,v retrieving revision 1.136 retrieving revision 1.136.2.1 diff -u -r1.136 -r1.136.2.1 --- external.html 19 Sep 2003 12:44:15 - 1.136 +++ external.html 23 Oct 2003 09:02:24 - 1.136.2.1 @@ -1188,6 +1188,54 @@ /tr /table h4 class=subsection +a name=ImTask/a +ImTask + /h4 +pImTask is a task to allow one to send an Instant +Message. Currently supports yahoo!, AIM, and Jabber/p + table class=externals cellspacing=1 cellpadding=4 + tr + th colspan=1 rowspan=1 + valign=top align=left + Compatibility: + /th + td colspan=1 rowspan=1 + valign=top align=left + Ant 1.5 or higher + /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://imtask.sourceforge.net/;http://imtask.sourceforge.net/a + /td + /tr + tr + th colspan=1 rowspan=1 + valign=top align=left + Contact: + /th + td colspan=1 rowspan=1 + valign=top align=left + a href=mailto:[EMAIL PROTECTED]Jon Madison/a + /td + /tr + tr + th colspan=1 rowspan=1 + valign=top align=left + License: + /th + td colspan=1 rowspan=1 + valign=top align=left + GNU LGPL + /td + /tr +/table +h4 class=subsection a name=Interactive/a Interactive /h4 No revision No revision 1.100.2.1 +26 -0 ant/xdocs/external.xml Index: external.xml === RCS file: /home/cvs/ant/xdocs/external.xml,v retrieving revision 1.100 retrieving revision 1.100.2.1 diff -u -r1.100 -r1.100.2.1 --- external.xml 19 Sep 2003 12:43:49 - 1.100 +++ external.xml 23 Oct 2003 09:02:24 - 1.100.2.1 @@ -574,6 +574,32 @@ /table /subsection + subsection name=ImTask + +pImTask is a task to allow one to send an Instant +Message. Currently supports yahoo!, AIM, and Jabber/p + + +table class=externals + tr +thCompatibility:/th +tdAnt 1.5 or higher/td + /tr + tr +thURL:/th +tda href=http://imtask.sourceforge.net/;http://imtask.sourceforge.net/a/td + /tr + tr +thContact:/th +tda href=mailto:[EMAIL PROTECTED]Jon Madison/a/td + /tr + tr +thLicense:/th +tdGNU LGPL/td + /tr +/table + /subsection + subsection name=Interactive pTask allowing to run a dialog within a build used to setup - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net TelnetTask.java
bodewig 2003/10/23 02:06:43
Modified:src/main/org/apache/tools/ant/taskdefs/optional/net
TelnetTask.java
Log:
Better support for people debugging timed out reads in telnet, Submitted by
Larry Shatzer
Revision ChangesPath
1.21 +3 -1
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/TelnetTask.java
Index: TelnetTask.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/TelnetTask.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- TelnetTask.java 13 May 2003 14:37:04 - 1.20
+++ TelnetTask.java 23 Oct 2003 09:06:43 - 1.21
@@ -342,6 +342,8 @@
Thread.sleep(250);
}
if (is.available() == 0) {
+log(Read before running into timeout:
++ sb.toString(), Project.MSG_DEBUG);
throw new BuildException(
Response timed-out waiting for \ + s +
'\',
getLocation());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/net TelnetTask.java
bodewig 2003/10/23 02:07:46
Modified:src/main/org/apache/tools/ant/taskdefs/optional/net Tag:
ANT_16_BRANCH TelnetTask.java
Log:
Merge from HEAD
Revision ChangesPath
No revision
No revision
1.20.2.1 +3 -1
ant/src/main/org/apache/tools/ant/taskdefs/optional/net/TelnetTask.java
Index: TelnetTask.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/net/TelnetTask.java,v
retrieving revision 1.20
retrieving revision 1.20.2.1
diff -u -r1.20 -r1.20.2.1
--- TelnetTask.java 13 May 2003 14:37:04 - 1.20
+++ TelnetTask.java 23 Oct 2003 09:07:46 - 1.20.2.1
@@ -342,6 +342,8 @@
Thread.sleep(250);
}
if (is.available() == 0) {
+log(Read before running into timeout:
++ sb.toString(), Project.MSG_DEBUG);
throw new BuildException(
Response timed-out waiting for \ + s +
'\',
getLocation());
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] Telnet task
committed, thanks Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
new external task
hello this mail is to add a new external ant task: kanaputsExternalTask.xml Description: Kanaputs is a parser for java based scripting. It is an interpreter for Java. With Kanaputs you can use Java as an interpreted language: no more compilation, each instruction is executed when you write it. It is a small programmation language to make script files above Java. Kanaputs Ant Task provides a way to add any kind of programmatic features in your Ant script. The code you insert stays OS independent (because Kanaputs uses Java) and is completely integrated with Ant as you can give Ant properties to the Kanaputs code and get back the results in other properties. Moreover, as you can invoke any kind of Java code with Kanaputs, you can popup windows from your Ant file to ask the user to do a choice. Compatibility: Ant 1.4 and above URL: http://www.kanaputs.org http://www.kanaputs.org/ant.html Contact: [EMAIL PROTECTED] best regards Patrick Duverger subsection name=Kanaputs pKanaputs is a parser for java based scripting. It is an interpreter for Java. With Kanaputs you can use Java as an interpreted language: no more compilation, each instruction is executed when you write it. It is a small programmation language to make script files above Java./p pKanaputs Ant Task provides a way to add any kind of programmatic features in your Ant script. The code you insert stays OS independent (because Kanaputs uses Java) and is completely integrated with Ant as you can give Ant properties to the Kanaputs code and get back the results in other properties./p pMoreover, as you can invoke any kind of Java code with Kanaputs, you can popup windows from your Ant file to ask the user to do a choice./p table class=externals tr thCompatibility:/th tdAnt 1.2 and above/td /tr tr thURL:/th td a href=http://www.kanaputs.org;http://www.kanaputs.org/a a href=http://www.kanaputs.org/ant.html;http://www.kanaputs.org/ant.html/a /td /tr tr thContact:/th td a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a /td /tr tr thLicense:/th tdFreeware/td /tr /table /subsection - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Vote: local for 1.6
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On 22 Oct 2003, Stefan Bodewig [EMAIL PROTECTED] wrote: I haven't made up my mind on the feature itself OK, re-reading the description first, I don't like the , | The value part of local is optional, and the local property may be | set by a subsequent property, property will only set it if the | value is not set. ` part. This means that whenever I find a property task I'll have to search all possible scopes for a local element and can't rely on it being global. What is the benefit of making property adhere to the scoping set up by local? Stefan, this is the whole point of local. If you do not have this feature you can not use local properties in conjunction with any task capable of setting a property (not only property but condition and a million more that make some computation and then decide whether to set a property or not). local is local, it cannot trasend targets since it is limitted in scope. The only way to get out of the scope of a target is by using one of the derived tasks from ant (antcall, subant, foreach, etc) but when this happens in the subproject the property is just as global as any other inherited property (AM I WRONG HERE PETER?). The only way you are in a situation where you may be using a local out of context is when invoking a macrodef which is actually expanding in place at the point of execution (i.e., within the body of the local). I cannot see what is the real situation that you were referring to, when would you be in a case where you find a property task and will have to search all possible scopes for a local what are all these possible scopes. Can you sketch an example? I don't have any strong objections against the rest or the implementation. The only point of the rest of the implementation is to support the feature above. So +0.5 (which can be turned into a +0.9 by explaining why property should care about scopes 8-). Stefan Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23862] - Cannot use overriden TestCase.getName() method in junit task
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=23862. 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=23862 Cannot use overriden TestCase.getName() method in junit task [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 09:44 --- Turned out Jason was using a version of JUnit that didn't have TestCase#getName so TestCase#name was called, bypassing his getName method. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23919] - [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2
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=23919. 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=23919 [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2 --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 09:45 --- FWIW, I agree with Stever that we'd better try to keep our sources to ASCII only. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23987] - scp task doesn't complain if remote directory is not specified
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=23987. 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=23987 scp task doesn't complain if remote directory is not specified --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 09:46 --- OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f on RedHat 7.3. Strange. Does it work with . as directory? We could make that the default if the directory has been omited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23960] - add catalog resolver to style task
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=23960. 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=23960 add catalog resolver to style task [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 Version|unspecified |1.5.4 --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 10:02 --- Try 1.6beta2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23919] - [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2
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=23919. 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=23919 [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2 --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 10:05 --- I have no problems either to keep the sources to ASCII only. In this case, we would change the build.xml again to say encoding=US-ASCII and remove all accentuated characters from the sources. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 23919] - [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2
On 23 Oct 2003, [EMAIL PROTECTED] wrote: In this case, we would change the build.xml again to say encoding=US-ASCII rather drop the encoding attribute IMHO. and remove all accentuated characters from the sources. replace them with Unicode escapes. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
milliseconds versus seconds[was: Vote: local for 1.6]
milliseconds are simply more powerful. In telnet the timeout is defined as an integer, so it not possible to say timeout=0.002 for 2 milliseconds. Even if it were possible, it would be a problem because of locales (ie the build file writer would have to wonder whether he should write timeout=0.002 or timeout=0,002 depending on the locale of the computer where his build will run. Antoine -Ursprungliche Nachricht- Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 23. Oktober 2003 09:57 An: [EMAIL PROTECTED] Betreff: Re: Vote: local for 1.6 On Wed, 22 Oct 2003, Steve Loughran [EMAIL PROTECTED] wrote: How about we make the sshexec timeouts seconds instead of ms? We are inconsistent with the timeout attribute between different tasks. exec, java, junit and sshexec use milliseconds, telnet uses seconds. I understand that some people may migrate from telnet to sshexec and may get bitten by the difference, but milliseconds is what the majority of other Ant tasks use. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Vote: local for 1.6
Ok, I think I will try to go back to the drawing board and try
to provide my simple definition of local as I originally
proposed. I guess I did not look close enough your implementation.
From your example bellow I see that local does not define a proper
nesting context (which I think is wrong). In my original proposal
local extended sequential and as such the life of the local
was restricted to that nesting. For what I see in your example
local is not defined as a nesting task and that concerns me.
As per the attribute of macrodef, I tend to agree with you
that probably it is not a good idea to treat it as a local
since its expansion should be just on the expansion of the macro
itself. But I think the issue here is in macrodef and not in the
definition of local.
Finally, I would argue that the burden of using ThreadLocals or
watever should be on parallel and not is some other task or
the CORE as a whole. If you want to parallelize tasks that
interfere with one another, it should be upto to parallel
to allow for independent computations. This should be
a completely separate issue from that of local it should
be an enhancement request on parallel.
So lets talk this over some more,
Jose Alberto
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 18:36
To: Ant Developers List
Subject: Re: Vote: local for 1.6
On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
On 22 Oct 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
I haven't made up my mind on the feature itself
OK, re-reading the description first, I don't like the
,
| The value part of local is optional, and the local
property may
| be set by a subsequent property, property will only set it if
| the value is not set.
`
part. This means that whenever I find a property task
I'll have to
search all possible scopes for a local element and can't
rely on it
being global.
What is the benefit of making property adhere to the
scoping set up
by local?
The point is that all tasks including property see the
local properties as normal properties.
It means that the macro attributes are now seen as normal
properties by the tasks that are contained within the
sequential nested element.
The local makes a property of the same kind as the macro attribute.
A common use case for this is when converting an antcall to a
macro: I had a target that was used as an antcall target, it
used a property suite.pattern to contain a regex what was
used a number of times in the target and as an ant call was
done to invoke the target, this was not seen outside the
target. On conversion to a macrodef, the property
suite.pattern is now a global property and the macrodef may
fail unexpectly.
With local the macro now looks like this:
!--
macro to generate test suites registing
@param gen.dir the dir to place the register_suites.h
and .cpp files
@param unit.dir the dir that the unit_*.cpp files are located
--
macrodef name=gen-register-suites
attribute name=gen.dir/
attribute name=unit.dir/
sequential
local name=suite.pattern value=^ *SUITE\(.*,\s*(.*)\s*\)/
mkdir dir=${gen.dir}/
...
/sequential
/macrodef
Another common use case is use of a local to pass information
from one task to another without messing up global properties
or similar properties used in other targets (say in a
complicated build with a number of imports and lots of targets).
local name=filepath/
pathconvert property=filepath targetos=unix
refid=files.path/
echothe files in files.path are ${filepath}/echo
However I can see the problem of looking at a script and not
knowing if the property is local or global.
The last patch allowed [sub]ant[call] to inherit the local properties.
I propose to change the local so that this inheriatance is
removed and also that macro instances do not inherit the
local properites - i.e. the local properties are staticlly
scoped in the build script.
So currently the following is the case:
property name=p value=global/
macrodef name=inner
sequential
echop is ${p}/echo
/sequential
/macrodef
macrodef name=outer
attribute name=p/
sequential
inner/
/sequential
/macrodef
outer p=from macro/
Will generate p is from macro which is probally not
expected as inner was not explicilty passed the property by
outer and inner may be in another file or in an antlib.xml.
Peter
I don't have any strong objections against the rest or the
implementation.
So +0.5 (which can be turned into a +0.9 by explaining why
property
should care about scopes 8-).
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: Vote: local for 1.6
On Wed, 22 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote: What is the benefit of making property adhere to the scoping set up by local? The point is that all tasks including property see the local properties as normal properties. So it is supposed to behave like all other property setting tasks, I understand. Currently I tend to agree with Jose Alberto that using a local container would be more intuitive. Your approach gets very confusing if you add dynamic extent to it, i.e. if you make *ant* inherit local values (as you say yourself). So I agree with you that local - if implemented the way you have implemented it - should be lexically scoped much like a local variable in a method. I wouldn't want to hunt several levels of build files to find whether one local has been shadowing my global value. I haven't checked, but does you current implementation allow local to shadow use properties? IMHO it shouldn't. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote: local for 1.6
On Thu, 23 Oct 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: I cannot see what is the real situation that you were referring to, when would you be in a case where you find a property task and will have to search all possible scopes for a local what are all these possible scopes. Can you sketch an example? Peter refered to the Bugzilla entry which also contains patches for the various ant tasks. If you have several nested ants, you'd have to check each level for a local that was in place shadowing your global value. AFAIU he doesn't plan to commit that part. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote: local for 1.6
On Thursday 23 October 2003 11:09, Jose Alberto Fernandez wrote:
Ok, I think I will try to go back to the drawing board and try
to provide my simple definition of local as I originally
proposed. I guess I did not look close enough your implementation.
From your example bellow I see that local does not define a proper
nesting context (which I think is wrong). In my original proposal
local extended sequential and as such the life of the local
was restricted to that nesting. For what I see in your example
local is not defined as a nesting task and that concerns me.
The nesting is for the enclosing target, sequential or target.
When the nesting task ends, the local's are removed. To support
multiple locals in the same scope, a solution would look much
like the current one. One example would be the way lisp does things.
(let ((here (point))
(ignore-depth 0)
(tag-info context))
bla.. bla..
)
Converted to ant-xml, this would look something like:
let
locals
local name=here value=point/
local name=ignore-depth value=0/
local name=tag-info value=context/
/locals
echohere is ${here}/echo
/let
Dropping the locals (as local should be sufficient information)
let
local name=here value=point/
local name=ignore-depth value=0/
local name=tag-info value=context/
echohere is ${here}/echo
/let
But this is not much different from:
sequential
local name=here value=point/
local name=ignore-depth value=0/
local name=tag-info value=context/
echohere is ${here}/echo
/sequential
or:
target name=sample
local name=here value=point/
local name=ignore-depth value=0/
local name=tag-info value=context/
echohere is ${here}/echo
/target
As per the attribute of macrodef, I tend to agree with you
that probably it is not a good idea to treat it as a local
since its expansion should be just on the expansion of the macro
itself. But I think the issue here is in macrodef and not in the
definition of local.
I think that the same argument applies to [sub]ant[call] - a
solution should deal with them and macro instances in the same way.
Finally, I would argue that the burden of using ThreadLocals or
watever should be on parallel and not is some other task or
the CORE as a whole. If you want to parallelize tasks that
interfere with one another, it should be upto to parallel
to allow for independent computations. This should be
a completely separate issue from that of local it should
be an enhancement request on parallel.
(This is also in reply to Conor's e-mail yesterday about ).
The code needs to handle a number of different situations. But
one thing needs to be kept in mind. As the local properties are
seen as normal properties by tasks, they use project[Helper] to access
the property. This project pointer is the same for all the threads in
a parallel - so if the threads need to see different properties for the
same name the only way projectHelper knowns this is by the thread id.
Java provides ThreadLocal for this situation.
An example of this is:
macrodef name=example
attribute name=val/
sequential
echoval is ${val}/echo
/sequential
/macrodef
parallel
example val=1/
example val=2/
example val=3/
/parallel
So the echo task whould need to see 1, 2 and 3 in the different threads
at the same time using getProject().getProperty(val);
The PropertyHelper code does this by using InheritableThreadLocal and
makes a copy for each thread.
As this is done, why does parallel have code to also copy ?
This is done to support the following:
local name=x/
parallel
sequential
property name=x value=1/
echox is ${x}/echo
/sequential
sequential
property name=x value=2/
echox is ${x}/echo
/sequential
sequential
property name=x value=3/
echox is ${x}/echo
/sequential
/parallel
One should see x is 1 and x is 2 etc (in some order).
parallel makes use of a thread pool, and so unless it copies the locals, some
of the sequentials would have the x set in their context.
So if this is the case, why does PropertyHelper copy the local variables?
This is done because the code is paranoid. A third party implemention
of something like parallel may not copy the local properties.
Peter
So lets talk this over some more,
Jose Alberto
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 18:36
To: Ant Developers List
Subject: Re: Vote: local for 1.6
On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
On 22 Oct 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
I haven't made up my mind on the feature itself
OK, re-reading the description first, I don't like the
,
| The value part of local is optional, and the local
property may
| be set by a subsequent property, property will only set it if
| the value is not set.
`
part. This means that whenever I find a property task
Re: Vote: local for 1.6
On Thursday 23 October 2003 12:31, Stefan Bodewig wrote: On Wed, 22 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote: What is the benefit of making property adhere to the scoping set up by local? The point is that all tasks including property see the local properties as normal properties. So it is supposed to behave like all other property setting tasks, I understand. Currently I tend to agree with Jose Alberto that using a local container would be more intuitive. See my lastest e-mail, I do not think a local container is necessary, as it needs to hold multiple local's winding up looking like sequential. Your approach gets very confusing if you add dynamic extent to it, i.e. if you make *ant* inherit local values (as you say yourself). So I agree with you that local - if implemented the way you have implemented it - should be lexically scoped much like a local variable in a method. I wouldn't want to hunt several levels of build files to find whether one local has been shadowing my global value. Yep, I think that local should be staticly scoped as far as possible. I haven't checked, but does you current implementation allow local to shadow use properties? IMHO it shouldn't. It does shadow user properties. The reason is to support macrodef attributes. It would be confusing if a macrodef attribute were overridden by a user -Dx=y command line. However, I could change the implemenation so that local did not shadow user properties, and macrodef attributes did. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Vote: local for 1.6
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Thu, 23 Oct 2003, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
I cannot see what is the real situation that you were referring to,
when would you be in a case where you find a property
task and will
have to search all possible scopes for a local what are all these
possible scopes. Can you sketch an example?
Peter refered to the Bugzilla entry which also contains
patches for the various ant tasks. If you have several
nested ants, you'd have to check each level for a local
that was in place shadowing your global value.
But this is no more or less shadowing than me making one of the
ant calls passing a param with the value of the local. The
effect is exactly the same. And as any changes made by the ant
execution will have no effect on the caller, I see no issue.
AFAIU he doesn't plan to commit that part.
I think it is a mistake that local if local is not visible across
ant, if that were the case then it should not be visible across
macrodef either. If it is visible in one case, so it should in the
other.
Otherwise you get this extremely wird behavior:
macrodef name=m
echo${p}/echo
if
equals arg1=${p} arg2=my local p/
then
antcall target=tm/
/then
/if
/macrodef
target name=x
local name=p value=my local p
m/
/local
/target
target name=tm
echo${p}/echo
/target
property name=p value=my global p/
[echo] my local p
[echo] my global p
How on earth by looking at m can you even realize what will
happen in the antcall? You may have done many checks to properties
to decide whether the antcall should be made or not, and then once you
do the call, it turns out the antcall receives completely different
properties than the one you tested. I do not know how such behavior can
make sense to anyone.
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote: local for 1.6
On Thu, 23 Oct 2003, peter reilly [EMAIL PROTECTED] wrote:
One example would be the way lisp does things.
(let ((here (point))
(ignore-depth 0)
(tag-info context))
bla.. bla..
)
At least Emacs Lisp uses dynamic extent here, i.e. with
(setq here bar)
(let ((here foo))
(some-method))
the function some-method would see the value foo for 'here.
I'm not familiar enough with other Lisp dialects. So if you want to
draw this parallel, ant would have to inherit the local shadows.
And macrodef would see the same problems (defmacro) has and we'd
have to introduce uninterned symbols to solve some issues,
(i.e. properties that are no properties at all). In a sense,
macrodef's current attributes are such uninterned symbols.
Incidentally I was reminded of (let) myself when I looked at the
local container.
let
local name=here value=point/
local name=ignore-depth value=0/
local name=tag-info value=context/
echohere is ${here}/echo
/let
But this is not much different from:
sequential
local name=here value=point/
local name=ignore-depth value=0/
local name=tag-info value=context/
echohere is ${here}/echo
/sequential
Except that sequential has never provided any sort of scoping at
all, neither has target. Making it explicit may help people to
understand the concept.
This is done to support the following:
local name=x/
parallel
sequential
property name=x value=1/
echox is ${x}/echo
/sequential
sequential
property name=x value=2/
echox is ${x}/echo
/sequential
sequential
property name=x value=3/
echox is ${x}/echo
/sequential
/parallel
Feels wrong. Each sequential should be/contain a local IMHO. If
you want to have different local scopes withon the sequentials then
you have to create them.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote: local for 1.6
On Thu, 23 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: On Thursday 23 October 2003 12:31, Stefan Bodewig wrote: I haven't checked, but does you current implementation allow local to shadow use properties? IMHO it shouldn't. It does shadow user properties. The reason is to support macrodef attributes. It would be confusing if a macrodef attribute were overridden by a user -Dx=y command line. When attributes don't create locals this is no issue, is it? However, I could change the implemenation so that local did not shadow user properties, and macrodef attributes did. Yes. target name=i-have-won-over-gump local name=build.sysclasspath value=ignore/ javac / /target would create undesirable results for a certain part of our user base otherwise ;-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote: local for 1.6
On Thu, 23 Oct 2003, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
If you have several nested ants, you'd have to check each level
for a local that was in place shadowing your global value.
But this is no more or less shadowing than me making one of the
ant calls passing a param with the value of the local.
Except that param is explicit and doesn't happen by accident.
I think it is a mistake that local if local is not visible across
ant, if that were the case then it should not be visible across
macrodef either.
You have a compelling example here
macrodef name=m
echo${p}/echo
if
equals arg1=${p} arg2=my local p/
then
antcall target=tm/
/then
/if
/macrodef
target name=x
local name=p value=my local p
m/
/local
/target
target name=tm
echo${p}/echo
/target
property name=p value=my global p/
[echo] my local p
[echo] my global p
and I currently don't have an answer for this.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote: local for 1.6
On Thursday 23 October 2003 13:44, Stefan Bodewig wrote:
On Thu, 23 Oct 2003, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
If you have several nested ants, you'd have to check each level
for a local that was in place shadowing your global value.
But this is no more or less shadowing than me making one of the
ant calls passing a param with the value of the local.
Except that param is explicit and doesn't happen by accident.
I think it is a mistake that local if local is not visible across
ant, if that were the case then it should not be visible across
macrodef either.
This is my point. The local should be visible for both or for none.
You have a compelling example here
macrodef name=m
echo${p}/echo
if
equals arg1=${p} arg2=my local p/
then
antcall target=tm/
/then
/if
/macrodef
target name=x
local name=p value=my local p
m/
/local
/target
target name=tm
echo${p}/echo
/target
property name=p value=my global p/
[echo] my local p
[echo] my global p
and I currently don't have an answer for this.
If m/ and antcall do not make local p visible,
then one simply gets:
x:
[echo] my global p
macrodef name=m
sequential
echo${p}/echo
antcontrib:if
equals arg1=${p} arg2=my local p/
then
antcall target=tm/
/then
/antcontrib:if
/sequential
/macrodef
target name=x
local name=p value=my local p/
m/
/target
target name=tm
echo${p}/echo
/target
property name=p value=my global p/
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: Vote: local for 1.6
On Thursday 23 October 2003 13:39, Stefan Bodewig wrote:
On Thu, 23 Oct 2003, peter reilly [EMAIL PROTECTED] wrote:
On Thursday 23 October 2003 12:31, Stefan Bodewig wrote:
I haven't checked, but does you current implementation allow
local to shadow use properties? IMHO it shouldn't.
It does shadow user properties. The reason is to support macrodef
attributes. It would be confusing if a macrodef attribute
were overridden by a user -Dx=y command line.
When attributes don't create locals this is no issue, is it?
However, I could change the implemenation so that local did not
shadow user properties, and macrodef attributes did.
Yes.
target name=i-have-won-over-gump
local name=build.sysclasspath value=ignore/
javac /
/target
The following does the same ..
target name=i-have-won-over-gump
antcall target=j
param name=build.sysclasspath value=ignore/
/antcall
/target
target name=j
echobuild.sysclasspath is ${build.sysclasspath}/echo
/target
Peter
would create undesirable results for a certain part of our user base
otherwise ;-)
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: Vote: local for 1.6
On Thu, 23 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: The following does the same .. target name=i-have-won-over-gump antcall target=j param name=build.sysclasspath value=ignore/ /antcall /target It doesn't - if build.sysclasspath is a user property of course. Try it with ant -Dbuild.sysclasspath=only and you'll see. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vote: local for 1.6
Hi Costin,
The idea is to make local properties appear
like normal properties.
Using something like local:foo to designate
local properties could be possible, however one
whould need to handle scoping issues like:
sequential
property name=local:x value=outer x/
property name=local:y value=outer y/
sequential
property name=local:x value=inner x/ ? new local here ?
echolocal:x is ${local:x}/echo
echolocal:y is ${local:y}/echo
/sequential
/sequential
Both the local task and the local container make the scoping
explicit.
Peter
p.s.
It would be nice to get an example of property chaining
in the unit tests to make sure that the modifications
to PropertyHelper do not break property chaining.
On Thursday 23 October 2003 06:55, [EMAIL PROTECTED] wrote:
I agree that property doesn't work well with macro and some other
use cases.
I'm +1 on local if we can keep it separated from property, so the
behavior of property doesn't change. I think it may be a good idea to
even throw an exception if some name is used with both local and property.
I wouldn't mind even a var that is local + modifiable.
I don't like the second example where local seems to be used to declare
filepath that is later defined as a property.
Another approach is to use namespaces for properties - IMO that's a cleaner
solution, but has the disadvantage that overloads property behavior.
( a local:foo property name will imply a local lifecycle, a att:foo could
be used for a modifiable property, etc ). I know this isn't very popular
:-)
Costin
peter reilly wrote:
On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
On 22 Oct 2003, Stefan Bodewig [EMAIL PROTECTED] wrote:
I haven't made up my mind on the feature itself
OK, re-reading the description first, I don't like the
,
| The value part of local is optional, and the local
| property may be set by a subsequent property, property
| will only set it if the value is not set.
`
part. This means that whenever I find a property task I'll have to
search all possible scopes for a local element and can't rely on it
being global.
What is the benefit of making property adhere to the scoping set up
by local?
The point is that all tasks including property see the local
properties as normal properties.
It means that the macro attributes are now seen as normal
properties by the tasks that are contained within the sequential
nested element.
The local makes a property of the same kind as the macro attribute.
A common use case for this is when converting an antcall to a macro:
I had a target that was used as an antcall target, it used a property
suite.pattern to contain a regex what was used a number of times
in the target and as an ant call was done to invoke the target, this
was not seen outside the target. On conversion to a macrodef, the
property suite.pattern is now a global property and the macrodef
may fail unexpectly.
With local the macro now looks like this:
!--
macro to generate test suites registing
@param gen.dir the dir to place the register_suites.h and .cpp
files @param unit.dir the dir that the unit_*.cpp files are
located --
macrodef name=gen-register-suites
attribute name=gen.dir/
attribute name=unit.dir/
sequential
local name=suite.pattern value=^ *SUITE\(.*,\s*(.*)\s*\)/
mkdir dir=${gen.dir}/
...
/sequential
/macrodef
Another common use case is use of a local to pass information from one
task to another without messing up global properties or similar
properties used in other targets (say in a complicated build with a
number of imports and lots of targets).
local name=filepath/
pathconvert property=filepath targetos=unix
refid=files.path/
echothe files in files.path are ${filepath}/echo
However I can see the problem of looking at a script and not knowing if
the property is local or global.
The last patch allowed [sub]ant[call] to inherit the local properties.
I propose to change the local so that this inheriatance is removed and
also that macro instances do not inherit the local properites - i.e.
the local properties are staticlly scoped in the build script.
So currently the following is the case:
property name=p value=global/
macrodef name=inner
sequential
echop is ${p}/echo
/sequential
/macrodef
macrodef name=outer
attribute name=p/
sequential
inner/
/sequential
/macrodef
outer p=from macro/
Will generate p is from macro which is probally not expected as
inner was not explicilty passed the property by outer and inner
may be in another file or in an antlib.xml.
Peter
I don't have any strong objections against the rest or the
implementation.
So +0.5 (which can be turned into a
Re: Vote: local for 1.6
On Thursday 23 October 2003 14:09, Stefan Bodewig wrote:
On Thu, 23 Oct 2003, peter reilly [EMAIL PROTECTED] wrote:
The following does the same ..
target name=i-have-won-over-gump
antcall target=j
param name=build.sysclasspath value=ignore/
/antcall
/target
It doesn't - if build.sysclasspath is a user property of course. Try
it with ant -Dbuild.sysclasspath=only and you'll see.
Opps..
You are right.
In this case, dynamic extent for local/attributes does not make
sense if attributes allow shadowing of user properties.
target name=i-have-won-over-gump
macrodef name=shadow
attribute name=build.sysclasspath default=ignore/
attribute name=target/
sequential
antcall target=${target}/
/sequential
/macrodef
shadow target=j/
/target
At least Emacs Lisp uses dynamic extent here, i.e. with
(setq here bar)
(let ((here foo))
(some-method))
the function some-method would see the value foo for 'here.
Oh, yes that must be true from a lisp point of view.
I'm not familiar enough with other Lisp dialects. So if you want to
draw this parallel, ant would have to inherit the local shadows.
And macrodef would see the same problems (defmacro) has and we'd
have to introduce uninterned symbols to solve some issues,
(i.e. properties that are no properties at all). In a sense,
macrodef's current attributes are such uninterned symbols.
Yikes, that sounds complicated.
This is done to support the following:
local name=x/
parallel
sequential
property name=x value=1/
echox is ${x}/echo
/sequential
sequential
property name=x value=2/
echox is ${x}/echo
/sequential
sequential
property name=x value=3/
echox is ${x}/echo
/sequential
/parallel
Feels wrong. Each sequential should be/contain a local IMHO. If
you want to have different local scopes withon the sequentials then
you have to create them.
Ok, that makes sense, implementation may however be difficult.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Vote: local for 1.6
On Wednesday 22 October 2003 08:41, Antoine Lévy-Lambert wrote: I am OK for the third beta. In the third beta we should have : - the local properties, - a new xml-apis.jar (probably the one which is distributed with Xerces-Java 2.5) - can we also have the endorsed libraries ? - other points ? * there was some discussion on the namespace support - - should the default uri be antlib:org.apache.tools.ant to be consistent with other antlib uri's + I had argued before that it should not, but now I think it should. - should the uris of introspection discovered nested elements be the same as the containing task + I am not too sure about this, the current state is more readable and easy to get right but the proposed change would be easier to automate for syntax directed editors. * antlib support - should typedef resource=x/ look for all instances of x or just the first one. + I think it should. Once these changes are done - hopefully soon - we will set new dates (for the third beta and for 1.6.0) Cheers, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AW: Vote: local for 1.6
From: peter reilly [mailto:[EMAIL PROTECTED] On Wednesday 22 October 2003 08:41, Antoine Lévy-Lambert wrote: I am OK for the third beta. In the third beta we should have : - the local properties, - a new xml-apis.jar (probably the one which is distributed with Xerces-Java 2.5) - can we also have the endorsed libraries ? - other points ? * there was some discussion on the namespace support - - should the default uri be antlib:org.apache.tools.ant to be consistent with other antlib uri's + I had argued before that it should not, but now I think it should. * antlib support - should typedef resource=x/ look for all instances of x or just the first one. + I think it should. Two remarks: 1) If, as I hope, the Ant namespace URI changes to antlib:org.apache.tools.ant, then an antlib.xml would be available there. For consistency's sake, but also because of (2) below... 2) This Ant antlib.xml would of course reference the existing tasks/types properties files, but *additionally* declare all the little types, like selectors, mappers, etc... Without (2), I cannot right a custom task with a new add(FilenameSelector) introspection point (or add(Condition), etc..), and be able to use the built-in Ant selectors, conditions, etc... (at least not without an explicit declaration for them somewhere.) It would be really strange to be able to use such custom types (selectors, mappers, conditions, etc...) as usual in Ant 1.6, but not the Ant built-in ones. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Vote: local for 1.6
From: peter reilly [mailto:[EMAIL PROTECTED]
On Thursday 23 October 2003 13:44, Stefan Bodewig wrote:
On Thu, 23 Oct 2003, Jose Alberto Fernandez
This is my point. The local should be visible for both or for none.
You have a compelling example here
macrodef name=m
echo${p}/echo
if
equals arg1=${p} arg2=my local p/
then
antcall target=tm/
/then
/if
/macrodef
target name=x
local name=p value=my local p
m/
/local
/target
target name=tm
echo${p}/echo
/target
property name=p value=my global p/
[echo] my local p
[echo] my global p
and I currently don't have an answer for this.
If m/ and antcall do not make local p visible,
then one simply gets:
x:
[echo] my global p
Notice that following this path (not making locals visible) means
that macrodef defined tasks will behave differently than java written
tasks, more over it means that macrodef is not really the same as having
the code in place. Ex:
macrodef name=m
echo${a}/echo
/macrodef
property name=a value=G/
target name=x
local name=a value=L/
echo${a}/echo
/target
target name=y
local name=a value=L/
m/
/target
Targets x and y are suppose to do the same thing, at least
that is what a macro is supposed to do. But here the behavior
changes in unexpected ways depending on whether a is local or global.
If I had written m/ in java, I would see the local value, but since
I wrote it using macrodef/ that is not the same. So I can forget
about writing new tasks by just composing existing tasks toguether. :-(
macrodef name=m
sequential
echo${p}/echo
antcontrib:if
equals arg1=${p} arg2=my local p/
then
antcall target=tm/
/then
/antcontrib:if
/sequential
/macrodef
target name=x
local name=p value=my local p/
m/
/target
target name=tm
echo${p}/echo
/target
property name=p value=my global p/
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Vote: local for 1.6
On Thursday 23 October 2003 15:16, Dominique Devienne wrote: From: peter reilly [mailto:[EMAIL PROTECTED] On Wednesday 22 October 2003 08:41, Antoine Lévy-Lambert wrote: I am OK for the third beta. In the third beta we should have : - the local properties, - a new xml-apis.jar (probably the one which is distributed with Xerces-Java 2.5) - can we also have the endorsed libraries ? - other points ? * there was some discussion on the namespace support - - should the default uri be antlib:org.apache.tools.ant to be consistent with other antlib uri's + I had argued before that it should not, but now I think it should. * antlib support - should typedef resource=x/ look for all instances of x or just the first one. + I think it should. Two remarks: 1) If, as I hope, the Ant namespace URI changes to antlib:org.apache.tools.ant, then an antlib.xml would be available there. For consistency's sake, but also because of (2) below... 2) This Ant antlib.xml would of course reference the existing tasks/types properties files, but *additionally* declare all the little types, like selectors, mappers, etc... A couple of proplems with this: * roles are not implemented in ant 1.6 so there is no way to disguish or as a condition, or as a selector - etc * mappers are not yet implemented in this way * antlib.xml for ant core/optional would be quite large and some work would need to be done to speed up loading from and antlib. Without (2), I cannot right a custom task with a new add(FilenameSelector) introspection point (or add(Condition), etc..), and be able to use the built-in Ant selectors, conditions, etc... (at least not without an explicit declaration for them somewhere.) One needs to extend the current container base classes (o.a.t.ant.taskdefs.condition.ConditionBase) or implement the current container interfaces ( (o.a.t.ant.types.selector.SelectorContainer). But this is not a nice situation... Peter It would be really strange to be able to use such custom types (selectors, mappers, conditions, etc...) as usual in Ant 1.6, but not the Ant built-in ones. --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: local for 1.6
On Thursday 23 October 2003 15:42, Jose Alberto Fernandez wrote:
Notice that following this path (not making locals visible) means
that macrodef defined tasks will behave differently than java written
tasks, more over it means that macrodef is not really the same as having
the code in place. Ex:
Yes this is true,
which is why I had macrodef make the locals visible to the macro
instance in the first place.
However I have felt uneasy about it, used to as I am pascal
/algol8/c/c++/java's static scopping for local variables and not
lisp's dynamic extent.
The code to do this was in and out a number of times over the weekend.
One could argue that as macrodef is a macro, the dynamic extent should
be the case (the macro expands into the current element).
However, I think that a static scope as seen from an ant xml script
point of view is the way of least suprise.
Peter
macrodef name=m
echo${a}/echo
/macrodef
property name=a value=G/
target name=x
local name=a value=L/
echo${a}/echo
/target
target name=y
local name=a value=L/
m/
/target
Targets x and y are suppose to do the same thing, at least
that is what a macro is supposed to do. But here the behavior
changes in unexpected ways depending on whether a is local or global.
If I had written m/ in java, I would see the local value, but since
I wrote it using macrodef/ that is not the same. So I can forget
about writing new tasks by just composing existing tasks toguether. :-(
macrodef name=m
sequential
echo${p}/echo
antcontrib:if
equals arg1=${p} arg2=my local p/
then
antcall target=tm/
/then
/antcontrib:if
/sequential
/macrodef
target name=x
local name=p value=my local p/
m/
/target
target name=tm
echo${p}/echo
/target
property name=p value=my global p/
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]
-
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 24058] New: - jsharpc task is documented as jsharp (without 'c' at the end)
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=24058. 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=24058 jsharpc task is documented as jsharp (without 'c' at the end) Summary: jsharpc task is documented as jsharp (without 'c' at the end) Product: Ant Version: 1.6Beta Platform: Other URL: http://ant.apache.org/manual- 1.6beta/OptionalTasks/dotnet.html OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It took me some time to figure out why csc works, but jsharp does not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24059] New: - [PATCH] Minor edits to xmlproperty docs
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=24059. 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=24059 [PATCH] Minor edits to xmlproperty docs Summary: [PATCH] Minor edits to xmlproperty docs Product: Ant Version: 1.6Beta Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Cleaning up terminology - XML well-formedness is a weaker constraint than validity. Couple of other trivial HTML edits too. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML, XSL, and Ant
We should be able to change this if SAXSource is supported, I'll take a stab at it - but I will need testers before I'm willing to merge my changes into the 1.6 branch. If I'd send you a changed ant-trax.jar, could you test it in your Ant 1.6beta environment? No problem - I've got a simple test case already setup that's currently failing, so I'm all set for testing :-) Kyle _ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24059] - [PATCH] Minor edits to xmlproperty docs
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=24059. 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=24059 [PATCH] Minor edits to xmlproperty docs --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 15:32 --- Created an attachment (id=8692) Suggested patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24060] New: - [PATCH] Typo in subant.html
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=24060. 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=24060 [PATCH] Typo in subant.html Summary: [PATCH] Typo in subant.html Product: Ant Version: 1.6Beta Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Trivial. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24060] - [PATCH] Typo in subant.html
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=24060. 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=24060 [PATCH] Typo in subant.html --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 15:34 --- Created an attachment (id=8693) Suggested patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24061] New: - jsharpc does not work well with a big number of source files.
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=24061. 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=24061 jsharpc does not work well with a big number of source files. Summary: jsharpc does not work well with a big number of source files. Product: Ant Version: 1.6Beta Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] jsharpc (and most likely csc too) fails to start vjc because of a big number (640 in my case) of source files specified on vjc command line. This makes the task not very useful. Unless it is done already, maybe it is better to pass parameters as array of strings, not just in one string. To reduce the limitation maybe it is possible to pass all paths relative to srcDir and launch vjc in that directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24062] New: - replace does not look as other tasks - it does not supported nested fileset(s)
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=24062. 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=24062 replace does not look as other tasks - it does not supported nested fileset(s) Summary: replace does not look as other tasks - it does not supported nested fileset(s) Product: Ant Version: 1.6Beta Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML, XSL, and Ant
Hi, -Original Message- From: Kyle Adams [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 8:30 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] We should be able to change this if SAXSource is supported, I'll take a stab at it - but I will need testers before I'm willing to merge my changes into the 1.6 branch. If I'd send you a changed ant-trax.jar, could you test it in your Ant 1.6beta environment? No problem - I've got a simple test case already setup that's currently failing, so I'm all set for testing :-) I have not downloaded ANT's source, so I don't know how it works. But, does it use XMLFilters for the transformation? If so, you can set the EntityResolver there. Otherwise, I believe you would need to run the Transformer resolved Sources through an XMLReader or XMLFilter that has an EntityResolver set. Best, -Rob Kyle _ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 - 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/xdocs external.xml
[EMAIL PROTECTED] wrote: + subsection name=ImTask + +pImTask is a task to allow one to send an Instant +Message. Currently supports yahoo!, AIM, and Jabber/p Oh, this is cool. We run a jabber net here and now maybe we can get cruise control to send hate messages. This will work well for people like me who dont check their email when coding - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24058] - jsharpc task is documented as jsharp (without 'c' at the end)
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=24058. 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=24058 jsharpc task is documented as jsharp (without 'c' at the end) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 16:19 --- sorry; will fix. Let us know how well this task works BTW, it has not been broadly tested yet. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24061] - jsharpc does not work well with a big number of source files.
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=24061. 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=24061 jsharpc does not work well with a big number of source files. --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 16:31 --- Ok. This is probably a duplicate of a complaint related to CSC. The problem is that the command line is too big. The fix would be to pump all the commands filenames into an @file response file and then exec it; a bit of cleanup of NetCommand will put all the changes into one place. but here is a problem related to the C# side of things; I dont think mono handles the @file inclusion of long commands, so we run a risk of breaking things there. ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24061] - jsharpc does not work well with a big number of source files.
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=24061. 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=24061 jsharpc does not work well with a big number of source files. --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 16:37 --- Then do as CppTasks does (or apply I think), and break the command into several commands, no? --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML, XSL, and Ant
On Thu, 23 Oct 2003, Robert Koberg [EMAIL PROTECTED] wrote: Otherwise, I believe you would need to run the Transformer resolved Sources through an XMLReader or XMLFilter that has an EntityResolver set. We are passing a SAXSource to the Transformer that has been created by an XMLReader with entity resolver set now. Kyle should receive an updated jar any time now. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 24061] - jsharpc does not work well with a big number of source files.
On 23 Oct 2003, [EMAIL PROTECTED] wrote: but here is a problem related to the C# side of things; I dont think mono handles the @file inclusion of long commands, so we run a risk of breaking things there. [EMAIL PROTECTED] jsps]$ mcs --help Mono C# compiler, (C) 2001 - 2003 Ximian, Inc. mcs [options] source-files --aboutAbout the Mono C# compiler -checked[+|-] Set default context to checked -codepage:ID Sets code page to the one in ID (number, `utf8' or `reset') -define:S1[;S2]Defines one or more symbols (short: /d:) -debug[+-] Generate debugging information -doc:FILE XML Documentation file to generate -g Generate debugging information --fatalMakes errors fatal -lib:PATH1,PATH2 Adds the paths to the assembly link path -main:classSpecified the class that contains the entry point -noconfig[+|-] Disables implicit references to assemblies -nostdlib[+|-] Does not load core libraries -nowarn:W1[,W2]Disables one or more warnings -out:FNAME Specifies output file --parseOnly parses the source file --expect-error X Expect that error X will be encountered -recurse:SPEC Recursively compiles the files in SPEC ([dir]/file) -reference:ASS References the specified assembly (-r:ASS) --stacktrace Shows stack trace at error location -target:KIND Specifies the target (KIND is one of: exe, winexe, library, module), (short: /t:) --timestampDisplays time stamps of various compiler events -unsafe[+|-] Allows unsafe code -warnaserror[+|-] Treat warnings as errors -warn:LEVELSets warning level (the highest is 4, the default) -v Verbose parsing (for debugging the parser) Resources: -linkresource:FILE[,ID] Links FILE as a resource -resource:FILE[,ID] Embed FILE as a resource --mcs-debug X Sets MCS debugging level to X @file Read response file for more options Options can be of the form -option or /option Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24067] New: - [PATCH] propertyfile should not touch a file it will not change semantically
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=24067. 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=24067 [PATCH] propertyfile should not touch a file it will not change semantically Summary: [PATCH] propertyfile should not touch a file it will not change semantically Product: Ant Version: 1.6Beta Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If after running propertyfile you have made no actual changes to the properties contained in it, it should avoid rewriting the file: changing the timestamp might cause other tasks to think they are out-of-date etc. Important in a big incremental build where the .properties file is used as an upstream dependency. There are three cases: 1. Property file did not exist before. Whether or not any keys are being added, create the .properties file, and log a message (INFO). 2. Existed before, and we are making changes. Rewrite, log a message (INFO). 3. Existed before, and we are not making any changes. Just log a message (VERBOSE). Patch includes added unit test. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24067] - [PATCH] propertyfile should not touch a file it will not change semantically
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=24067. 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=24067 [PATCH] propertyfile should not touch a file it will not change semantically --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 16:50 --- Created an attachment (id=8695) Suggested patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24069] New: - [PATCH] Email addr change
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=24069. 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=24069 [PATCH] Email addr change Summary: [PATCH] Email addr change Product: Ant Version: 1.6Beta Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Sorry, trivial. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24069] - [PATCH] Email addr change
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=24069. 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=24069 [PATCH] Email addr change --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 16:54 --- Created an attachment (id=8696) Requested patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24070] New: - [PATCH] Debugging tweaks for ApacheCatalogResolver
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=24070. 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=24070 [PATCH] Debugging tweaks for ApacheCatalogResolver Summary: [PATCH] Debugging tweaks for ApacheCatalogResolver Product: Ant Version: 1.6Beta Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Minor things that I found useful when trying to debug why resolver.jar was not being used correctly at one point. Produces more helpful errors. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23919] - [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2
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=23919. 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=23919 [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2 --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 17:38 --- Created an attachment (id=8699) The 1 other class that did not comply to ASCII translated to ASCII - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML, XSL, and Ant
Stefan Bodewig wrote: My JDK 1.4 javadocs ... contradicts itself when it comes to document(). I have no idea how it is implemented in Xalan. Yeah, a famous discrepancy. The question is whether the Transformer inherits the URIResolver from the factory or whether it is created with the default one. I remember Saxon and Xalan handled this differently for a long time, a reccurent source of confusion. If the custom URIResolver is set on both the factory and the created transformers, no ambiguities remain. Neither says anything about entities. That's because entities are resolved by the parser... Fortunately, the resolver from XML commons implements both the URIResolver and the EntityResolver interface. James Clark rules! a chance to plug in the entity resolver... We should be able to change this if SAXSource is supported, I'll take a stab at it Great! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23919] - [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2
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=23919. 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=23919 [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2 --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 17:55 --- When the patch 10/19/03 11:57, 10/19/03 13:03 and 10/23/03 17:38 all non ASCII characters are removed from the java sources. Translations have been done from an alternative form of ' to ' and names have been spelled with non accented characters. To be explicit about the names Jan Materne and Aslak Hellesoy I missed the src/main/org/apache/tools/ant/taskdefs/optional/IContract.java file probably because it is not touched in a basic build of ant. Please also apply patch 10/19/03 14:25 as it makes a testcase pass on jdk 1.2.2 which would otherwise fail. This leaves only one testcase open for jdk 1.2.2 which has been described in the bug report 23920 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24074] - [PATCH] Bogus URL in zipfileset.html
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=24074. 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=24074 [PATCH] Bogus URL in zipfileset.html --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 18:22 --- Created an attachment (id=8702) Suggested patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23919] - [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2
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=23919. 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=23919 [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2 --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 19:09 --- I Just read the mail of Stefan suggesting to use the escapes, I made a new patch which replaces all patches except for the patch 8619 10/19/03 14:25 which does replace the e and the o from the names by unicode escape sequences but replaces \u00b4 by ' to avoid constructs like don\u00b4t I am currently verifying the patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23919] - [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2
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=23919. 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=23919 [PATCH] nightly build and ant 1.6 not buildable with jdk 1.2.2 --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 19:18 --- Created an attachment (id=8705) \u00b4 replaced by ' e from materne replaced by \u00e8 and o from hellesoy replaced by \u00f8. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8031] - [PATCH] Suggest ProjectHelperImpl use File.toURI().toURL().toExternalForm()
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=8031. 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=8031 [PATCH] Suggest ProjectHelperImpl use File.toURI().toURL().toExternalForm() [EMAIL PROTECTED] changed: What|Removed |Added Summary|Suggest ProjectHelperImpl |[PATCH] Suggest |use |ProjectHelperImpl use |File.toURI().toURL().toExter|File.toURI().toURL().toExter |nalForm() |nalForm() --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 19:44 --- Well I have a patch now, which uses URI on JDK 1.4 and otherwise uses the old logic. All unit tests seem to pass for me on Linux, JDK 1.4.2, offline=true; otherwise YMMV. Not sure how safe this is for 1.6, might be more appropriate for 1.7 - up to judgement of the committers. Of especial interest: 1. A couple of unit tests were IMHO incorrect and I changed them enough to pass (hopefully still asserting what should be true). Please inspect carefully. Note that Java does *not* specify what precise form file: URIs should take on various platforms, only some aspects of their behavior, so the unit tests have to live on the edge a bit. 2. I don't know where the convention of using URLs such as file:./foo.xml or file:foo.xml (rather than simply foo.xml) for entity includes came from, but it certainly looks like it violates common sense as well as the URI specification. (Relative URIs have no protocol and are resolved from a base URI which does.) JDK 1.4's new File(URI) rejects such URIs (correctly IMHO, though I could imagine them being resolved relative to the JVM's current working directory, however useless that might be). Ant's faq.xml used to recommend this file:./etc style for whatever reason. The patch corrects the FAQ. However, for compatibility with existing (IMHO erroneous) build scripts, file: URIs which do not have an absolute path beginning with '/' (and are thus illegal) are just passed through to the old parsing mechanism even on JDK 1.4. IncludeTest thus continues to pass using both syntaxes. 2a. While fromURI thus accepts relative paths for compatibility, toURI attempts to always produce a URI encoding an absolute path for safety. 3. Fixed up some places in the codebase that were failing to use the FileUtils methods to create or interpret file: URLs and were thus in danger of behaving incorrectly for some pathnames. 4. Removed obsolete FILE_PROTOCOL_PREFIX from the XSLTLiaison interface. It was not being used anywhere, and was not really correct anyway. (F_P_P + file.getAbsolutePath() is not a safe way to make URIs, and the extra // at the end of the prefix is gratuitous since there will never be an authority for a file URI.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8031] - [PATCH] Suggest ProjectHelperImpl use File.toURI().toURL().toExternalForm()
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=8031. 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=8031 [PATCH] Suggest ProjectHelperImpl use File.toURI().toURL().toExternalForm() --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 19:44 --- Created an attachment (id=8706) Suggested patch (needs review) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23920] - Contains selector test fails on JDK 1.2.2 and IBM JDK 1.4.1
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=23920. 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=23920 Contains selector test fails on JDK 1.2.2 and IBM JDK 1.4.1 --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 19:47 --- Well, as it is hard to validate a file against a certain encoding (being it default or another, relying on Readers one just gets an IOException on certain JDK's), I thought of encoding the string to be sought by the provided encoding (default if not provided) and then binary match the file. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24024] - Definer could load all antlibs matching a resource path
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=24024. 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=24024 Definer could load all antlibs matching a resource path --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 20:11 --- Hmm, seems 'resource' attr of Definer is not covered by unit tests at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23987] - scp task doesn't complain if remote directory is not specified
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=23987. 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=23987 scp task doesn't complain if remote directory is not specified --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 20:33 --- The error you are getting says that ant cannot find your known_hosts file. Do you have a known_hosts file in C:\Documents and Settings\user\.ssh\known_hosts ?? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8031] - [PATCH] Suggest ProjectHelperImpl use File.toURI().toURL().toExternalForm()
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=8031. 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=8031 [PATCH] Suggest ProjectHelperImpl use File.toURI().toURL().toExternalForm() --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 20:33 --- See also: http://developer.java.sun.com/developer/bugParade/bugs/4273532.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24024] - [PATCH] Definer could load all antlibs matching a resource path
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=24024. 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=24024 [PATCH] Definer could load all antlibs matching a resource path [EMAIL PROTECTED] changed: What|Removed |Added Summary|Definer could load all |[PATCH] Definer could load |antlibs matching a resource |all antlibs matching a |path|resource path --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 21:07 --- Try the attached patch (with unit case). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24024] - [PATCH] Definer could load all antlibs matching a resource path
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=24024. 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=24024 [PATCH] Definer could load all antlibs matching a resource path --- Additional Comments From [EMAIL PROTECTED] 2003-10-23 21:08 --- Created an attachment (id=8710) Suggested patch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
