Re: Another feature request - set jre for junit
On Wed, 14 May 2003, David Thielen [EMAIL PROTECTED] wrote: Another feature request - the ability to set the jre for a junit test. That's what junit's jvm attribute does. Stefan
Re: antlib / proposal of Peter Reilly
On Thu, 15 May 2003 12:56 am, peter reilly wrote: I have merged the ant-type code into my antlib code. However it uses a magic attribute name ant-type to achieve the effect and not as discussed before - the namesspaced attribute name like - ant:type. I can easily do a name-spaced attribute name for this, however if this is done there will be only one object in the xml name space uri - type. Would this be reasonable? I would prefer to use the XML schema attribute for this. I have done a quick review of you proposal. I wonder if we can split this into smaller chunks to make it easier to understand and review. For example, the onError stuff could be split out, as could the URL handling code for separate consideration. Smaller chunks are easier to handle. Anyway, it seems to me that you have combined the namespace URI and element names in certain places. Examples: In component helper changes, for method createComponent, you say the name of the component, if the component is in a namespace, the name is prefixed withe the namespace uri dropping the antlib: and adding :. Why not pass the URI and local name to the component helper and not have to parse it out in componentHelper. Your approach also precludes URIs that contain ':' (I know you disallow these elsewhere but I don't see any reason to combine these, anyway) I'm not sure where TaskAdapter went. createNewTask seems to return null if the class is not a Task - probably handled somewhere else. I'm not sure about addType methods. It usually limits only one element to being extensible - consider a task taking two filesets for different reasons. OTOH, I guess a lot can be done with it. The element names in IntrospectionHelper would need to have URIs as well, won't they? For the most part it looks OK to me. I'd need to look more closely to fully comprehend it but thought you might like some feedback. Conor
Re: antlib / proposal of Peter Reilly
On Thursday 15 May 2003 07:56, Conor MacNeill wrote:
On Thu, 15 May 2003 12:56 am, peter reilly wrote:
I have merged the ant-type code into my antlib code.
However it uses a magic attribute name ant-type to
achieve the effect and not as discussed before - the
namesspaced attribute name like - ant:type.
I can easily do a name-spaced attribute name for this,
however if this is done there will be only one object in
the xml name space uri - type. Would this be reasonable?
I would prefer to use the XML schema attribute for this.
Mmmm, this would be confusing as the XML schema attribute
has an associated URI http://www.w3.org/2001/XMLSchema; which
implies a lot more that a reference to an ant type.
I have done a quick review of you proposal. I wonder if we can split this
into smaller chunks to make it easier to understand and review. For
example, the onError stuff could be split out, as could the URL handling
code for separate consideration. Smaller chunks are easier to handle.
This is true, but difficult to do. Some of the implementations of the
different features change/improve if other features are present. For
example the implementation of onerror uses the new anttypedefintion
class. The implementation of the psuedo task antlib uses the add(Type)
mechanism rather than explicity stating addTypedef and addTaskdef, this
allowed other tasks that extend Definer to used in the antlib task (for
example a definer that wraps Runnable objects as ant tasks, or
a future implemation of roles).
Also from a practical point of view, I find it difficult to maintain multiple
patched ant versions.
Anyway, it seems to me that you have combined the namespace URI and element
names in certain places. Examples: In component helper changes, for method
createComponent, you say
the name of the component, if
the component is in a namespace, the
name is prefixed withe the namespace uri
dropping the antlib: and adding :.
Why not pass the URI and local name to the component helper and not have to
parse it out in componentHelper. Your approach also precludes URIs that
contain ':' (I know you disallow these elsewhere but I don't see any reason
to combine these, anyway)
Initially I was going to do this, but here is a lot of places in the code
that assume that a task/type is mapped from a string and not from the tuple
{ns uri, local name}.
J.Pietschmann suggested in
http://marc.theaimsgroup.com/?l=ant-devm=105233644225128w=2
that one can use a mapping of {uri, name} to a string ns-uri+^+name
when migrating a project to namespaced XML.
My current mapping is not good as it drops the antlib: prefix and thus
excludes other uri prefixes, so I will change this. The current code does
exclude URI that contain :, this is a combination of a bug and by design.
The bug is that I should have used lastindexof and the design is that
the code only deals with NS URIs that start with antlib: for type/task
definitions. The code for the mapping should be done in one place (maybe
as a static method in ProjectHelper).
I'm not sure where TaskAdapter went. createNewTask seems to return null if
the class is not a Task - probably handled somewhere else.
This is by design and for BC reasons. If the type class is not a Task, and
the type does not have an Adapter to a Task class, the CM#createNewTask()
will not create the class. taskdef/ will does this (for example the
condition task), and the unit tests contain an adapter for Runnable objects.
The code in CM does not treat TaskAdapter as a special case.
I'm not sure about addType methods. It usually limits only one element to
being extensible - consider a task taking two filesets for different
reasons. OTOH, I guess a lot can be done with it.
The add[Configured](Type) methods are meant more for container like objects -
like the antlib task, the filterchain type or the condition base class. It
also allows custom extensions (e.g. new conditions) to be dropped in by third
party classes without special treatment.
The polymorphic feature is I think to be used for fixed elements in objects
that are not containers - the javac src/ nested element for example.
javac...
src ant-type=... .../
(or
src poly:type=... .. xmlns:poly=ant poly uri/)
/javac
The element names in
IntrospectionHelper would need to have URIs as well, won't they?
UnknownElement converts the {uri,name} to a componentname before
calling IH#createElement()
For the most part it looks OK to me. I'd need to look more closely to fully
comprehend it but thought you might like some feedback.
Thanks, and cheers.
Peter
cvs commit: ant/docs/manual listeners.html
antoine 2003/05/15 04:30:27
Modified:docs/manual/CoreTasks mail.html
src/main/org/apache/tools/ant/taskdefs/email EmailTask.java
Mailer.java MimeMailer.java PlainMailer.java
src/main/org/apache/tools/ant/listener MailLogger.java
src/main/org/apache/tools/mail MailMessage.java
docs/manual listeners.html
Log:
implemented replyto in the EmailTask and the MailLogger.
I have implemented it similarly to the other lists of email addresses (To,
CC, Bcc)
because it might actually be easier that way
We might still need a generic parameter collection for other header elements
PR: 19141
Revision ChangesPath
1.18 +11 -4 ant/docs/manual/CoreTasks/mail.html
Index: mail.html
===
RCS file: /home/cvs/ant/docs/manual/CoreTasks/mail.html,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- mail.html 17 Apr 2003 17:09:35 - 1.17
+++ mail.html 15 May 2003 11:30:26 - 1.18
@@ -33,6 +33,11 @@
element./td
/tr
tr
+td valign=topreplyto/td
+td valign=topReplyto email address./td
+td align=center valign=topNo/td
+ /tr
+ tr
td valign=toptolist/td
td valign=topComma-separated list of recipients./td
td align=center valign=middle rowspan=3At least one of these, or
the
@@ -116,7 +121,7 @@
h3Parameters specified as nested elements/h3
-h4to / cc / bcc / from/h4
+h4to / cc / bcc / from/ replyto /h4
pAdds an email address element. It takes the following attributes:/p
table width=60% border=1 cellpadding=2 cellspacing=0
@@ -187,7 +192,8 @@
blockquotepre
lt;mail mailhost=quot;smtp.myisp.comquot; mailport=quot;1025quot;
subject=quot;Test buildquot;gt;
- lt;from address=quot;[EMAIL PROTECTED]quot;/gt;
+ lt;from address=quot;[EMAIL PROTECTED]quot;/gt;
+ lt;replyto address=quot;[EMAIL PROTECTED]quot;/gt;
lt;to address=quot;[EMAIL PROTECTED]quot;/gt;
lt;messagegt;The ${buildname} nightly build has completedlt;/messagegt;
lt;fileset dir=quot;distquot;gt;
@@ -196,8 +202,9 @@
lt;/mailgt;
/pre/blockquote
-pSends an eMail from i[EMAIL PROTECTED]/i to i[EMAIL PROTECTED]/i
with a subject of
-iTest Build/i and attaches any zip files from the dist directory.nbsp;
The
+pSends an eMail from i[EMAIL PROTECTED]/i to i[EMAIL PROTECTED]/i
with a subject of
+iTest Build/i. Replies to this email will go to i[EMAIL PROTECTED]/i.
+Any zip files from the dist directory are attached.nbsp; The
task will attempt to use JavaMail and fall back to UU encoding or no
encoding in
that order depending on what support classes are available.
code${buildname}/code
will be replaced with the codebuildname/code property's value./p
1.18 +32 -1
ant/src/main/org/apache/tools/ant/taskdefs/email/EmailTask.java
Index: EmailTask.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/email/EmailTask.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- EmailTask.java17 Apr 2003 17:09:35 - 1.17
+++ EmailTask.java15 May 2003 11:30:26 - 1.18
@@ -77,6 +77,7 @@
* @author [EMAIL PROTECTED] Paulo Gaspar
* @author [EMAIL PROTECTED] Rob Oxspring
* @author a href=mailto:[EMAIL PROTECTED]Aleksandr Ishutin/a
+ * @author a href=mailto:[EMAIL PROTECTED]Antoine Levy-Lambert/a
* @since Ant 1.5
* @ant.task name=mail category=network
*/
@@ -120,9 +121,11 @@
private boolean failOnError = true;
private boolean includeFileNames = false;
private String messageMimeType = null;
-
+/** special headers */
/** sender */
private EmailAddress from = null;
+/** replyto */
+private Vector replyToList = new Vector();
/** TO recipients */
private Vector toList = new Vector();
/** CC (Carbon Copy) recipients */
@@ -135,6 +138,10 @@
private Vector filesets = new Vector();
/** Character set for MimeMailer*/
private String charset=null;
+/** if set to true, the email will not be actually sent */
+private boolean debugonly=false;
+/** a location where to print the email message */
+private File debugoutput;
/**
@@ -266,6 +273,28 @@
/**
+ * Adds a replyto address element
+ *
+ * @param address The address to reply to
+ * @since ant 1.6
+ */
+public void addReplyTo(EmailAddress address) {
+this.replyToList.add(address);
+}
+
+
+/**
+ * Shorthand to set the replyto address element
+ *
+ * @param address The address to which replies should be directed
+ * @since ant 1.6
+ */
Re: antlib / proposal of Peter Reilly
This is true, but difficult to do. Some of the implementations of the different features change/improve if other features are present. For example the implementation of onerror uses the new anttypedefintion class. The implementation of the psuedo task antlib uses the add(Type) mechanism rather than explicity stating addTypedef and addTaskdef, this allowed other tasks that extend Definer to used in the antlib task (for example a definer that wraps Runnable objects as ant tasks, or a future implemation of roles). Also from a practical point of view, I find it difficult to maintain multiple patched ant versions. True The add[Configured](Type) methods are meant more for container like objects - like the antlib task, the filterchain type or the condition base class. It also allows custom extensions (e.g. new conditions) to be dropped in by third party classes without special treatment. This (addConfigured) is important for antlibs to work. Antoine
DO NOT REPLY [Bug 19829] - Entity Reference not expanding ../ in !Entity. No Protocol
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=19829. 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=19829 Entity Reference not expanding ../ in !Entity. No Protocol --- Additional Comments From [EMAIL PROTECTED] 2003-05-15 12:12 --- !ENTITY commonTargets SYSTEM ../common/targets.xml is the problem, it should be !ENTITY commonTargets SYSTEM file:../common/targets.xml
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/email Mailer.java
bodewig 2003/05/15 05:22:48 Modified:src/main/org/apache/tools/ant/taskdefs/email Mailer.java Log: 2003 Revision ChangesPath 1.9 +1 -1 ant/src/main/org/apache/tools/ant/taskdefs/email/Mailer.java Index: Mailer.java === RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/email/Mailer.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- Mailer.java 15 May 2003 11:30:26 - 1.8 +++ Mailer.java 15 May 2003 12:22:47 - 1.9 @@ -1,7 +1,7 @@ /* * The Apache Software License, Version 1.1 * - * Copyright (c) 2002 The Apache Software Foundation. All rights + * Copyright (c) 2002-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/compilers DefaultCompilerAdapter.java Gcj.java Jikes.java Jvc.java Sj.java
bodewig 2003/05/15 05:44:01
Modified:.WHATSNEW
docs/manual/CoreTasks javac.html
src/main/org/apache/tools/ant/taskdefs Javac.java
src/main/org/apache/tools/ant/taskdefs/compilers
DefaultCompilerAdapter.java Gcj.java Jikes.java
Jvc.java Sj.java
Log:
javac's executable attribute can now also be used to specify the
executable for jikes, jvc, sj or gcj.
PR: 13814
javac has a new attribute tempdir that can control the placement of
temporary files.
PR: 19765
A new magic property build.compiler.jvc.extensions has been added that
can be used to turn of Microsoft extensions while using the jvc
compiler.
PR: 19826
Submitted by: Joseph Walton joe at kafsemo dot org
Revision ChangesPath
1.419 +10 -0 ant/WHATSNEW
Index: WHATSNEW
===
RCS file: /home/cvs/ant/WHATSNEW,v
retrieving revision 1.418
retrieving revision 1.419
diff -u -r1.418 -r1.419
--- WHATSNEW 14 May 2003 15:01:12 - 1.418
+++ WHATSNEW 15 May 2003 12:44:00 - 1.419
@@ -331,6 +331,16 @@
* javadoc now supports the -noqualifier switch. Bugzilla Report 19288.
+* javac's executable attribute can now also be used to specify the
+ executable for jikes, jvc, sj or gcj. Bugzilla Report 13814.
+
+* javac has a new attribute tempdir that can control the placement
+ of temporary files. Bugzilla Report 19765.
+
+* A new magic property build.compiler.jvc.extensions has been added
+ that can be used to turn of Microsoft extensions while using the jvc
+ compiler. Bugzilla Report 19826.
+
Changes from Ant 1.5.2 to Ant 1.5.3
===
1.40 +16 -1 ant/docs/manual/CoreTasks/javac.html
Index: javac.html
===
RCS file: /home/cvs/ant/docs/manual/CoreTasks/javac.html,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- javac.html19 Mar 2003 08:26:58 - 1.39
+++ javac.html15 May 2003 12:44:00 - 1.40
@@ -276,7 +276,9 @@
td valign=topComplete path to the codejavac/code
executable to use in case of codefork=quot;yesquot;/code.
Defaults to the compiler of the Java version that is currently
- running Ant. Ignored if codefork=quot;noquot;/code/td
+ running Ant. Ignored if codefork=quot;noquot;/code.br
+ Since Ant 1.6 this attribute can also be used to specify the
+ path to the executable when using jikes, jvc, gcj or sj./td
td align=center valign=topNo/td
/tr
tr
@@ -334,6 +336,13 @@
be listed; defaults to codeno/code./td
td align=center valign=topNo/td
/tr
+ tr
+td valign=toptempdir/td
+td valign=topWhere Ant should place temporary files.
+ emSince Ant 1.6/em./td
+td align=center valign=topNo; default is the current working
+ directory./td
+ /tr
/table
h3Parameters specified as nested elements/h3
@@ -562,6 +571,12 @@
/td
/tr
/table
+
+h3Jvc Notes/h3
+
+pJvc will enable Microsoft extensions unless you set the property
+codebuild.compiler.jvc.extensions/code to false before invoking
+codelt;javacgt;/code./p
hr
p align=centerCopyright copy; 2000-2003 Apache Software Foundation.
1.111 +37 -2 ant/src/main/org/apache/tools/ant/taskdefs/Javac.java
Index: Javac.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Javac.java,v
retrieving revision 1.110
retrieving revision 1.111
diff -u -r1.110 -r1.111
--- Javac.java7 Mar 2003 11:23:01 - 1.110
+++ Javac.java15 May 2003 12:44:01 - 1.111
@@ -1,7 +1,7 @@
/*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2000-2002 The Apache Software Foundation. All rights
+ * Copyright (c) 2000-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -141,6 +141,7 @@
private String source;
private String debugLevel;
+private File tmpDir;
/**
* Javac task for compilation of Java files.
@@ -596,6 +597,15 @@
}
/**
+ * The value of the executable attribute, if any.
+ *
+ * @since Ant 1.6
+ */
+public String getExecutable() {
+return forkedExecutable;
+}
+
+/**
* Is this a forked invocation of JDK's javac?
*/
public boolean isForkedJavac() {
@@ -604,6 +614,14 @@
/**
* The name of the javac executable to use in fork-mode.
+ *
+ * pThis is either the name
DO NOT REPLY [Bug 19826] - jvc java compiler should support compilation symbols
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=19826. 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=19826 jvc java compiler should support compilation symbols [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-05-15 12:47 --- build.compiler.jvc.extensions is in nightly build 2003-05-16, for the /D switch, please use nested compilerargs.
DO NOT REPLY [Bug 19765] - Compile tasks should not use ${user.dir} for temp 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=19765.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19765
Compile tasks should not use ${user.dir} for temp files
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
Target Milestone|--- |1.6
--- Additional Comments From [EMAIL PROTECTED] 2003-05-15 12:47 ---
tempdir attribute in javac appears in nightly build 2003-05-16.
DO NOT REPLY [Bug 19953] - junit timeouts and formatter not found
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=19953. 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=19953 junit timeouts and formatter not found --- Additional Comments From [EMAIL PROTECTED] 2003-05-15 13:27 --- I already have the fix in my machine, I had to modify JUnitTask, FormatterElement and JUnitTestRunner. I had to add the ClassLoader to the createFormater method of the formatter element.
DO NOT REPLY [Bug 18715] - [PATCH] subant to specify basedir to ant
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=18715. 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=18715 [PATCH] subant to specify basedir to ant [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
DO NOT REPLY [Bug 19959] New: - Selecting loggers listeners in build file
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=19959. 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=19959 Selecting loggers listeners in build file Summary: Selecting loggers listeners in build file Product: Ant Version: 1.5.3 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Enhancement Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I use the IDE Oracle JDeveloper 9.0.3.1 with Ant as the build system. In JDeveloper, Ant command line parameters are passed in through the project settings which are stored in a file that is in CVS. Since JDeveloper doesn't honor ANT_ARGS, the only option to change loggers / listeners is through modifying the project file. And this means that the modified project file will not be automatically updated from the CVS server. So whenever we change the project file (which contains some frequently changing parameters) we send out an email to everybody to do a clean update of the project file and possibly reapplying the logger / listener to the updated project file. That's a bit inconvenient. It would be nice if one could set the logger through properties or a special target.
DO NOT REPLY [Bug 19964] New: - system property for a default timeout for tests
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=19964.
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=19964
system property for a default timeout for tests
Summary: system property for a default timeout for tests
Product: Ant
Version: 1.5.3
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
we already have a lots of junit tasks in our test system, and now we would
like to add a timeout, but since it is painfull to change and maintain a lot of
build files, it would be cool to have a property junit.default.timeout to set
the timeout for ALL tests that do not specify it explicitly.
the only change is in the class JUnitTask and is:
/**
* @return ttnull/tt if there is a timeout value, otherwise the
* watchdog instance.
*
* @since Ant 1.2
*/
protected ExecuteWatchdog createWatchdog() throws BuildException {
if (timeout == null){
String defaultTimeout =
getProject().getProperty(junit.default.timeout);
if (defaultTimeout == null) {
return null;
}
else {
log(using junit default timeout, Project.MSG_VERBOSE);
timeout = Integer.valueOf(defaultTimeout);
}
}
return new ExecuteWatchdog(timeout.intValue());
}
Re: Testing for an abstract method
Stefan Bodewig wrote: Any chance to get the available task a bit extended so that it can also be used to check for methods, fields, implemented interfaces etc. and specific properties... Doesn't sound too hard. I wouldn't augment available with it but rather create a new condition, though. Any suggestions for a name? What are the particular rationales to create a new condition rather than extending available? I thought that putting in declarations for further conditions would be a straightforward extension: available class foo with method foobar(int, int) and protected static field bar (any type) and implementing interface xyzzy Hm, one problem is the syntax for any method named bar and method bar(void). People will probably assume that no declarations for parameter types mean the the latter and will wonder how to do the former. We can just omit the first case though. J.Pietschmann
RE: Testing for an abstract method
The fact that the meaning of available was overloaded in the past doesn't mean we should continue doing so... And still, available currently looks for files/streams (on file-system, classpath, path, etc...), which is quite different than looking for particular characteristic of whatever's described in these streams... Condition names that could be used: classHasMethod classHasField classHasInnerClass classIsAssigneableFrom etc... Having separate conditions allows to associate them with and, or, etc... as needed. As far as allowing to check for particular method signature, when looking for just the method name is not enough, then the simplest thing is to use the JNI signature, as in main([java.lang.String)V, and have an optional modifiers attribute. This is well documented, and avoids having to parse the signature as written in a Java source file. Of course if you really want the ability to say public static void main(String[]), you're welcome to write the parser for it ;-) --DD -Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] Sent: Thursday, May 15, 2003 1:49 PM To: Ant Developers List Subject: Re: Testing for an abstract method Stefan Bodewig wrote: Any chance to get the available task a bit extended so that it can also be used to check for methods, fields, implemented interfaces etc. and specific properties... Doesn't sound too hard. I wouldn't augment available with it but rather create a new condition, though. Any suggestions for a name? What are the particular rationales to create a new condition rather than extending available? I thought that putting in declarations for further conditions would be a straightforward extension: available class foo with method foobar(int, int) and protected static field bar (any type) and implementing interface xyzzy Hm, one problem is the syntax for any method named bar and method bar(void). People will probably assume that no declarations for parameter types mean the the latter and will wonder how to do the former. We can just omit the first case though. J.Pietschmann
DO NOT REPLY [Bug 19967] New: - Skip input task if property already set
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=19967. 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=19967 Skip input task if property already set Summary: Skip input task if property already set Product: Ant Version: 1.5.3 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The input task should not prompt for user input if the property that has been specified for it to set has already been set. If the property has already been set, the user's input doesn't have any impact anyways, as documented. This would allow the input task to be used as a fallback mechanism for properties that were intentionally or accidently not specified anywhere else, without causing any interruptions if everything has been properly set.
Re: Testing for an abstract method
Dominique Devienne wrote: The fact that the meaning of available was overloaded in the past doesn't mean we should continue doing so... And still, available currently looks for files/streams (on file-system, classpath, path, etc...), which is quite different than looking for particular characteristic of whatever's described in these streams... Ah, I missed this. Condition names that could be used: classHasMethod classHasField classHasInnerClass classIsAssigneableFrom etc... Having separate conditions allows to associate them with and, or, etc... as needed. I see. I'm still wrangling with ideas about how to make it easy to test multiple conditions of this kind on the same class. Repeating the fully qualified class name every time seems to be a bit bothersome, even though it's probably tolerable. As far as allowing to check for particular method signature, when looking for just the method name is not enough, then the simplest thing is to use the JNI signature, as in main([java.lang.String)V, and have an optional modifiers attribute. This is well documented, and avoids having to parse the signature as written in a Java source file. Of course if you really want the ability to say public static void main(String[]), you're welcome to write the parser for it ;-) I'd thought of using XML structures and using introspection rather than looking up some string in the source: classHasMethod class=foo method=bar parameter type=int/ parameter type=BazClass/ /classHasMethod could be roughly handled by this wild pseudocode clazz=Class.forName(@class); parameterTypes = new Class[count(parameter)]; for-each parameter parameterTypes[position()] = built-in-classes(@type) if parameterTypes[position()]==null parameterTypes[position()] = Class.forName(@type) method=clazz.getMethod(@method,parameterTypes); J.Pietschmann
DO NOT REPLY [Bug 19829] - Entity Reference not expanding ../ in !Entity. No Protocol
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=19829. 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=19829 Entity Reference not expanding ../ in !Entity. No Protocol --- Additional Comments From [EMAIL PROTECTED] 2003-05-15 21:28 --- OK, thanks for that I'm sorry for fileing a bug if its my fault. What made me think it was a bug way the the same file's built in one directory and not in another, to expand on the example I gave: cd tutorial/examples cd jaxrpc/hello ant success cd ../../ cp jaxrpc new location cd new location/jaxrpc ls common hello cd hello Ant fail Any way if file ENTITY's should always have the file: identifer thats problem sovle. Thanks once more for your time David
DO NOT REPLY [Bug 18633] - starteam checkin task ignores the includes parameter for files not in repository
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=18633. 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=18633 starteam checkin task ignores the includes parameter for files not in repository --- Additional Comments From [EMAIL PROTECTED] 2003-05-15 22:31 --- Actually I already have both. adduncontrolled=yes includes=*.java and excludes=*.class and it still adds the .class files
