DO NOT REPLY [Bug 18708] - outputproperty attribute of exec
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=18708.
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=18708
outputproperty attribute of exec
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WORKSFORME
--- Additional Comments From [EMAIL PROTECTED] 2003-04-07 04:14 ---
Works for me. I used this to test 1.5.3 Beta on Solaris.
project name=18708 default=test
target name=test
exec executable=/usr/bin/ls outputproperty=object_list
arg value=/tmp/
/exec
echo message=list is ${object_list}/
/target
/project
Re: VOTE: new committer: Jesse Stockall
Steve Loughran wrote: I nominate Jesse Stockall as a committer as he likes spending time fixing up and refactoring some of the neglected bits of the optional tasks, and if we commit his new patch to the xdocs stuff, we need somebody to go through all the attributes of all the tasks and add the new metadata :) Also he's been a long standing contributor to bits of the project, does all the due diligence on bugzilla and ant-user support, those being the things that matter as much as new code. The quality of the code is Here's my vote: +1 -steve +1 Costin
Re: Using files in classpath in task file=
On Fri, 4 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
I would like for ANT to do this for me, transparently.
property name=fileurl locationURL=${myfile}/
or somethig like that.
Sure, should be trivial using FileUtils#toURI together with
setLocationURL(File), I'm just not sure about the attribute name.
locationURL would imply that its value was an URL and not a location
that gets turned into an URI - at least to me.
Hmm, uriOfLocation=${myfile}? uriForLocation?
Attributes are case-insensitive in Ant.
Stefan
DO NOT REPLY [Bug 18754] New: - ant hangs, if the printsummary-attribute of a junit-task in a parallel task is wrong
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=18754.
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=18754
ant hangs, if the printsummary-attribute of a junit-task in a parallel task is
wrong
Summary: ant hangs, if the printsummary-attribute of a junit-task
in a parallel task is wrong
Product: Ant
Version: 1.5.2
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Minor
Priority: Other
Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Ant will hang with the following snippet (after starting the server):
target name=test2
parallel
antcall target=start_server
...
/antcall
sequential
junit fork=yes dir=${basedir} printsummary=bla
/junit
antcall target=stop_server/
/sequential
/parallel
/target
Expected is an error message like: bla is not a legal value for this attribute
(I'm using jdk 1.3.1)
DO NOT REPLY [Bug 18700] - Stange classpath problem
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=18700. 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=18700 Stange classpath problem [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-04-07 10:03 --- I understand your comments but I don't see that it is a 'big consistency problem'. There is a difference between not checking for the existence of a file and not knowing the file's name. If we were to defer the resolution of a property to the point of use, the path object could not be configured at all until use. Since the path elements take File arguments the File objects could not be constructed until the path is to be used whereupon it would have to be configured. We also would need to understand what is the point of use. You can argue that the path instance is a use of the properties and they therefore they should be resolved. If we decide to resolve on use of the path, we just shift the problem. Say there was another type that took a path as an argument. Should we defer the resolution of the path until the use of this new type. That might be possible. The rules of Ant configuration are currently that property resolution takes place at the point an object is configured, not where it is used. This is only an issue for datatypes (since they are likely to defined and then used - which doesn't happen for tasks) I can think of how to do it - it would involve leaving types as UnknownElements until a reference was fetched from the Project. That sort of change is pretty major - it would need some discussion on ant's dev list. I'm marking this as WONTFIX for now. If you want to discuss further, lets do it on ant dev.
RE: Using files in classpath in task file=
Pick the name you think it is more appropriate.
Some thoughts:
property name=x uriOfFile=${fileName}/
property name=x valueAsUri=${fileName}/
property name=x locationAsUri=${fileName}/
property name=x uriForLocation=${fileName}/
Alternatively, we could have something more general that you can pass a URI
and knows how to use it, but alternatively if the value if that of a file, then
it construct a URI for it.
property name=x uri=${fileName}/
As long as we get the expected behavior I do not mind.
Jose Alberto
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 07 April 2003 08:38
To: [EMAIL PROTECTED]
Subject: Re: Using files in classpath in task file=
On Fri, 4 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
I would like for ANT to do this for me, transparently.
property name=fileurl locationURL=${myfile}/
or somethig like that.
Sure, should be trivial using FileUtils#toURI together with
setLocationURL(File), I'm just not sure about the attribute name.
locationURL would imply that its value was an URL and not a location
that gets turned into an URI - at least to me.
Hmm, uriOfLocation=${myfile}? uriForLocation?
Attributes are case-insensitive in Ant.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using files in classpath in task file=
Nicola Ken Barozzi wrote, On 07/04/2003 9.11: ... After the replies and a bit of thought, maybe even setXYZUrl(URL) is not the right solution. We have a FTP task, a get task, etc... putting the URL as a parameter short-circuits the process of getting stuff and using it, and potentially makes Ant dwonload files at every run without devs knowing. So, AFA I'm concerned, I would need a styleResource= parameter, *or* overloading the file attribute *just* to get stuff from jars. That is, if the filename starts with resource:// or something like that, get the file as a resource. What should I send a patch for? Further note: I need this getting from resources in xslt and import tasks. Please advise WRT the easiest and most consistent solution. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: [Patch] trying solve w2k command line length limitations
I've solved that problem for my own purposes a few months ago, by just
hacking a bit at java.c, so it can read it's command line arguments from a
file, using the usual @file syntax (that Javac already supports, but
implemented in Java). Even enabled env. var. substitutions a la Ant, using
the ${env.VARNAME} syntax. You can even *set* env. var. within that command
line file, which is something I needed to debug JNI code from within Visual
Studio, to set the Path (using env. vars. to be location independent) to
find dependents of native libraries (since SUN apparently can't use
LoadLibraryEx as Steve L. pointed out). That hacked up java.exe (Windows
HACK only) find the right JDK as specified in the registry, which is just
normal behavior (didn't have to code that).
Never had a problem since... --DD
-Original Message-
From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 05, 2003 10:38 AM
To: '[EMAIL PROTECTED]'
Subject: [Patch] trying solve w2k command line length limitations
Hola a todos:
I'm trying to solve w2k command line length problems for gump.
what i've tried is to create a properties file from gump instead of
passing the classpath in the command line, make a Launcher class that
loads it in a URLclassloader and start ant's main, this approach by
itself doesnt work at all, javac needs real jars in a real classpath not
a CL with all the jars loaded..
Hence this patch, the Launcher in addition to create a UCL, adds a
system property ant.class.path and starts ant's Main.. i've modified ant
Path type to add this property to the classpath like it's done with
java.class.path ( this property is readonly ).., and if using
build.sysclasspath=only, this property contents are added in addition to
java.class.path..
Comments are welcomed..
Saludos,
Ignacio J. Ortega
Index: src/main/org/apache/tools/ant/types/Path.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/types/Path.java,v
retrieving revision 1.47
diff -u -r1.47 Path.java
--- src/main/org/apache/tools/ant/types/Path.java 11 Mar 2003
10:57:42 - 1.47
+++ src/main/org/apache/tools/ant/types/Path.java 5 Apr 2003
16:28:25 -
@@ -103,6 +103,9 @@
public static Path systemClasspath =
new Path(null, System.getProperty(java.class.path));
+public static Path antClasspath =
+new Path(null, System.getProperty(ant.classpath));
+
/**
* Helper class, holds the nested codelt;pathelementgt;/code
values.
@@ -556,7 +559,8 @@
if (order.equals(only)) {
// only: the developer knows what (s)he is doing
result.addExisting(Path.systemClasspath, true);
-
+result.addExisting(Path.antClasspath, true);
+
} else if (order.equals(first)) {
// first: developer could use a little help
result.addExisting(Path.systemClasspath, true);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Parallel.java
conor 2003/04/07 07:47:02
Modified:src/main/org/apache/tools/ant/taskdefs Parallel.java
Log:
Remove duplication in Parallel
Revision ChangesPath
1.16 +19 -82ant/src/main/org/apache/tools/ant/taskdefs/Parallel.java
Index: Parallel.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Parallel.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -w -u -r1.15 -r1.16
--- Parallel.java 11 Feb 2003 11:26:44 - 1.15
+++ Parallel.java 7 Apr 2003 14:47:02 - 1.16
@@ -150,13 +150,12 @@
public void execute() throws BuildException {
updateThreadCounts();
if (numThreads == 0) {
-spinAllThreads();
-} else {
-spinNumThreads();
+numThreads = nestedTasks.size();
}
+spinThreads();
}
-public void updateThreadCounts() {
+private void updateThreadCounts() {
if (numThreadsPerProcessor != 0) {
int numProcessors = getNumProcessors();
if (numProcessors != 0) {
@@ -168,18 +167,19 @@
/**
* Spin up threadCount threads.
*/
-public void spinNumThreads() throws BuildException {
-final int maxThreads = nestedTasks.size();
-Thread[] threads = new Thread[maxThreads];
-TaskThread[] taskThreads = new TaskThread[maxThreads];
+private void spinThreads() throws BuildException {
+final int numTasks = nestedTasks.size();
+Thread[] threads = new Thread[numTasks];
+TaskRunnable[] runnables = new TaskRunnable[numTasks];
int threadNumber = 0;
for (Enumeration e = nestedTasks.elements(); e.hasMoreElements();
threadNumber++) {
Task nestedTask = (Task) e.nextElement();
ThreadGroup group = new ThreadGroup(parallel);
-TaskThread taskThread = new TaskThread(threadNumber, nestedTask);
-taskThreads[threadNumber] = taskThread;
-threads[threadNumber] = new Thread(group, taskThread);
+TaskRunnable taskRunnable
+= new TaskRunnable(threadNumber, nestedTask);
+runnables[threadNumber] = taskRunnable;
+threads[threadNumber] = new Thread(group, taskRunnable);
}
final int maxRunning = numThreads;
@@ -188,7 +188,7 @@
// now run them in limited numbers...
outer:
-while (threadNumber maxThreads) {
+while (threadNumber numTasks) {
synchronized(semaphore) {
for (int i = 0; i maxRunning; i++) {
if (running[i] == null || !running[i].isAlive()) {
@@ -225,8 +225,8 @@
int numExceptions = 0;
Throwable firstException = null;
Location firstLocation = Location.UNKNOWN_LOCATION;;
-for (int i = 0; i maxThreads; ++i) {
-Throwable t = taskThreads[i].getException();
+for (int i = 0; i numTasks; ++i) {
+Throwable t = runnables[i].getException();
if (t != null) {
numExceptions++;
if (firstException == null) {
@@ -253,71 +253,7 @@
}
}
-/**
- * Spin up one thread per task.
- */
-public void spinAllThreads() throws BuildException {
-int numTasks = nestedTasks.size();
-Thread[] threads = new Thread[numTasks];
-TaskThread[] taskThreads = new TaskThread[numTasks];
-int threadNumber = 0;
-for (Enumeration e = nestedTasks.elements(); e.hasMoreElements();
- threadNumber++) {
-Task nestedTask = (Task) e.nextElement();
-ThreadGroup group = new ThreadGroup(parallel);
-TaskThread taskThread = new TaskThread(threadNumber, nestedTask);
-taskThreads[threadNumber] = taskThread;
-threads[threadNumber] = new Thread(group, taskThread);
-}
-
-// now start all threads
-for (int i = 0; i threads.length; ++i) {
-threads[i].start();
-}
-
-// now join to all the threads
-for (int i = 0; i threads.length; ++i) {
-try {
-threads[i].join();
-} catch (InterruptedException ie) {
-// who would interrupt me at a time like this?
-}
-}
-
-// now did any of the threads throw an exception
-StringBuffer exceptionMessage = new StringBuffer();
-int numExceptions = 0;
-Throwable firstException = null;
-Location firstLocation = Location.UNKNOWN_LOCATION;;
-for (int i = 0; i threads.length; ++i) {
-
Re: [Patch] trying solve w2k command line length limitations
Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Sat, 5 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: what i've tried is to create a properties file from gump instead of passing the classpath in the command line, make a Launcher class that loads it in a URLclassloader and start ant's main, Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? the problem i've found when using the URLCL approach, is more a problem of javac that didnt use resources loaded in the CL to compile, instead it needs a real classpath with jar or classfiles in it.. or i understand you badly? i've modified ant Path type to add this property to the classpath like it's done with java.class.path ( this property is readonly ).., and if using build.sysclasspath=only, this property contents are added in addition to java.class.path.. Which introduces a hole to defeat Gump, or any other setup that uses build.sysclasspath=only. I've not looked into the patch, but we'll have to ensure that ant.class.path will be set to java.class.path when the launcher has not been used - and do that before the user had a chance to set this property. How can i signal ant that is used by Launcher instead of directly? and the porpouse of the launcher is that precisely, to launch ant with a given classpath but not passing it in the command line, so how can ant set a property before the launcher ? -- Saludos, Ignacio J.Ortega Nevada Soft
RE: [Patch] trying solve w2k command line length limitations
FYI, Javac is not really using java.class.path, but env.class.path instead... By default, the former will be copied in the later by javac.c. Discovered this early 2001 when I wrote a little Java front-end to Javac to be Visual Studio friendly. Could be of use to the discussion??? --DD -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2003 9:41 AM To: [EMAIL PROTECTED] Subject: Re: [Patch] trying solve w2k command line length limitations Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Sat, 5 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: what i've tried is to create a properties file from gump instead of passing the classpath in the command line, make a Launcher class that loads it in a URLclassloader and start ant's main, Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? the problem i've found when using the URLCL approach, is more a problem of javac that didnt use resources loaded in the CL to compile, instead it needs a real classpath with jar or classfiles in it.. or i understand you badly? i've modified ant Path type to add this property to the classpath like it's done with java.class.path ( this property is readonly ).., and if using build.sysclasspath=only, this property contents are added in addition to java.class.path.. Which introduces a hole to defeat Gump, or any other setup that uses build.sysclasspath=only. I've not looked into the patch, but we'll have to ensure that ant.class.path will be set to java.class.path when the launcher has not been used - and do that before the user had a chance to set this property. How can i signal ant that is used by Launcher instead of directly? and the porpouse of the launcher is that precisely, to launch ant with a given classpath but not passing it in the command line, so how can ant set a property before the launcher ? -- Saludos, Ignacio J.Ortega Nevada Soft - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18768] New: - WAR task (or ZIP base ?) generates amazing archives
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=18768. 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=18768 WAR task (or ZIP base ?) generates amazing archives Summary: WAR task (or ZIP base ?) generates amazing archives Product: Ant Version: 1.5.2 Platform: PC OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've been using the V 1.5.1 alone and within Eclipse V2.0 without any problem. Since, i upgraded my Eclipse to V2.1 which includes a updated 1.5.2 version of ANT. My old well working build files dont work anymore !!! The generated WAR files seems ok when i list their content with jar, but with WinZip, all the WEB-INF directory and subdirectories are hidden. The global war file size is ok according the files added in the archive. When i activate the -v option, i can see the last operation the task does is adding the web.xml file, but, just before it does it, it adds the WEB-INF directory. The old 1.5.1 didn't add it (i verified it with the same run with -v option) : I bet this is the problem. Here the trace from eclipse console : web-axis-archive: [war] Building war: C:\DOCUME~1\MASERE~1\LOCALS~1 \Temp\Jonas2.tmp\SmsWebAxis.war [war] adding directory META-INF/ [war] adding entry META-INF/MANIFEST.MF [war] adding entry WEB-INF/jonas-web.xml [war] adding entry WEB-INF/server-config.wsdd [war] adding directory WEB-INF/classes/my/ [war] adding directory WEB-INF/classes/my/jonas/ [war] adding directory WEB-INF/classes/my/jonas/sms/ [war] adding directory WEB-INF/classes/my/jonas/sms/axis/ [war] adding directory WEB-INF/classes/my/jonas/sms/axis/client/ [war] adding directory WEB-INF/classes/my/jonas/sms/axis/server/ [war] adding entry WEB- INF/classes/my/jonas/sms/axis/client/IllegalParameterValueShortMessageSenderExce ption.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/client/ShortMessageSenderException.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/client/SMSPortType.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/client/SMSService.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/client/SMSServiceLocator.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/client/SMSWebServiceSoapBindingStub.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/client/SystemShortMessageSenderException.class [war] adding entry WEB-INF/classes/my/jonas/sms/axis/LogFilter.class [war] adding entry WEB-INF/classes/my/jonas/sms/axis/LogHandler.class [war] adding entry WEB-INF/classes/my/jonas/sms/axis/server/deploy.wsdd [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/IllegalParameterValueShortMessageSenderExce ption.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/ShortMessageSenderException.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/SMSPortType.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/SMSService.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/SMSServiceLocator.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/SMSWebServiceSoapBindingImpl.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/SMSWebServiceSoapBindingSkeleton.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/SMSWebServiceSoapBindingStub.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/SystemShortMessageSenderException.class [war] adding entry WEB- INF/classes/my/jonas/sms/axis/server/undeploy.wsdd [war] adding entry WEB- INF/classes/my/jonas/sms/axis/ShortMessageSenderEJBWrapper.class [war] adding entry WEB-INF/lib/axis.jar [war] adding entry WEB-INF/lib/commons-discovery.jar [war] adding entry WEB-INF/lib/commons-logging.jar [war] adding entry WEB-INF/lib/jaxrpc.jar [war] adding entry WEB-INF/lib/saaj.jar [war] adding entry WEB-INF/lib/wsdl4j.jar [war] adding entry fingerprint.jsp [war] adding entry happyaxis.jsp [war] adding entry index.html [war] adding entry SOAPMonitorApplet$ServiceFilterPanel.class [war] adding entry SOAPMonitorApplet$SOAPMonitorData.class [war] adding entry SOAPMonitorApplet$SOAPMonitorFilter.class [war] adding entry SOAPMonitorApplet$SOAPMonitorPage.class [war] adding entry
DO NOT REPLY [Bug 18667] - javah module no longer works with Java 1.4.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=18667. 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=18667 javah module no longer works with Java 1.4.2 --- Additional Comments From [EMAIL PROTECTED] 2003-04-07 15:47 --- btw I emailed Richard Beton back in February asking if he was still the javah maintainer because there was an up and coming change to javah. I never received a reply
cvs commit: ant/docs/manual/CoreTasks input.html
bodewig 2003/04/07 09:05:57 Modified:docs/manual/CoreTasks input.html Log: Document input's defaultvalue attribute. PR: 18717 Submitted by: Jan Matèrne jan at materne dot de Revision ChangesPath 1.8 +17 -1 ant/docs/manual/CoreTasks/input.html Index: input.html === RCS file: /home/cvs/ant/docs/manual/CoreTasks/input.html,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- input.html4 Sep 2002 11:05:16 - 1.7 +++ input.html7 Apr 2003 16:05:57 - 1.8 @@ -56,6 +56,13 @@ overriden./td td valign=top align=centerNo/td /tr + tr +td valign=topdefaultvalue/td +td valign=topDefines the default value of the property to be +created from input. Property value will be set to default if no +input is received./td +td valign=top align=centerNo/td + /tr /table h3Examples/h3 pre lt;input/gt;/pre @@ -95,8 +102,17 @@ pWill display the message quot;Please enter db-username:quot; and set the property codedb.user/code to the value entered by the user./p +pre lt;input +message=quot;Please enter db-username:quot; +addproperty=quot;db.userquot; +defaultvalue=quot;Scott-Tigerquot; + /gt;/pre +pSame as above, but will set codedb.user/code to the value +iScott- Tiger/i if the user enters no value (simply types +lt;returngt;)./p + hr -p align=centerCopyright copy; 2001-2002 Apache Software Foundation. All rights +p align=centerCopyright copy; 2001-2003 Apache Software Foundation. All rights Reserved./p /body /html
DO NOT REPLY [Bug 18717] - Missed defaultvalue attribute in input doc
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=18717. 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=18717 Missed defaultvalue attribute in input doc [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-04-07 16:08 --- committed, thanks.
DO NOT REPLY [Bug 18705] - Ant does not build: Java: UNIXProcess:forkAndExec: exec failed: Argument list too long
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=18705. 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=18705 Ant does not build: Java: UNIXProcess:forkAndExec: exec failed: Argument list too long [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-04-07 16:09 --- *** This bug has been marked as a duplicate of 17640 ***
DO NOT REPLY [Bug 17640] - building ant: chmod returned -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=17640. 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=17640 building ant: chmod returned -1 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-04-07 16:09 --- *** Bug 18705 has been marked as a duplicate of this bug. ***
DO NOT REPLY [Bug 18768] - WAR task (or ZIP base ?) generates amazing archives
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=18768. 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=18768 WAR task (or ZIP base ?) generates amazing archives --- Additional Comments From [EMAIL PROTECTED] 2003-04-07 16:12 --- OK ! I had a look to the duplicate 17648, but i don't understand if the bug has been fixed in 1.5.3 or not... Thanks again.
Re: [Patch] trying solve w2k command line length limitations
Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little IMHO This contradicts my experience of CLs, i think some places inside tomcat used Class.forName also, and never seen what you say.. Class.forName loads in the current loader and delegates to parent if needed AFAIK, but i'm little far from the code.. now.. so i can be worng.. i'm not arguing only very surprised, and trying to get to speed in the related facts.. -- Saludos, Ignacio J.Ortega Nevada Soft
RE: [Patch] trying solve w2k command line length limitations
Stefan is *of course* right! Class.forName always uses the system class loader, and not some current loader... As far as delegation happening, that's ClassLoader 101. Unless of course one uses the second form of Class.forName, that takes a classloader as argument, provided one doesn't pass null for it, that is. Stefan was referring the first form, that takes only a class name. --DD -Original Message- From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2003 11:23 AM To: [EMAIL PROTECTED] Subject: Re: [Patch] trying solve w2k command line length limitations Stefan Bodewig [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little IMHO This contradicts my experience of CLs, i think some places inside tomcat used Class.forName also, and never seen what you say.. Class.forName loads in the current loader and delegates to parent if needed AFAIK, but i'm little far from the code.. now.. so i can be worng.. i'm not arguing only very surprised, and trying to get to speed in the related facts.. -- Saludos, Ignacio J.Ortega Nevada Soft
RE: [Patch] trying solve w2k command line length limitations
Dominique Devienne writes: Stefan is *of course* right! Class.forName always uses the system class loader, and not some current loader. No it doesn't. It uses the defining class loader of the caller. http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Class.html#forName(java.lang.String) Andrew.
RE: [Patch] trying solve w2k command line length limitations
I stand corrected, and apologize. --DD -Original Message- From: Andrew Haley [mailto:[EMAIL PROTECTED] Sent: Monday, April 07, 2003 11:53 AM To: Ant Developers List Subject: RE: [Patch] trying solve w2k command line length limitations Dominique Devienne writes: Stefan is *of course* right! Class.forName always uses the system class loader, and not some current loader. No it doesn't. It uses the defining class loader of the caller. http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Class.html#forName(java.la ng.String) Andrew.
Re: [Patch] trying solve w2k command line length limitations
Costin Manolache [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] The problem seems to be that we need a way to pass a CLASSPATH but without using the env variable. And this needs to have the override properties of the CLASSPATH that are used in gump. Well, the problem is the maximun command line length, not only the env size, if i understand you well.., later the env var is use as part of java command that launches ant from gump, and passing -D for ant in the command line has the exact same problem.. but the later is easy to overcome with a simple -propertyfile args to ant.. well to comment a bit more, the stupid cmd.exe, adds a blank space after every echo routed to a file.. so is a little more complicated.. :(.. Wouldn't be simpler to just add a bit of code to set java.class.path from a file or property ? If you go with a wrapper that embeds ant, that would be pretty simple and not need any changes to ant. I think i've tried modifying java.class.path, and ended at nowhere, i thought it was controlled to be read-only, not found any reference in JDK to the use of java.class.path, but reviewing my patch another time and given the name of the property i propose, maybe i confused java.class.path with java.classpath, so i'll try another time.. :) to see what happens.. Thanks to point this obvious issue.. :) -- Saludos, Ignacio J.Ortega Nevada Soft
Re: [Patch] trying solve w2k command line length limitations
Stefan Bodewig wrote: On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little URLClassLoader your Launcher provides. Many places inside Ant use Class.forName, thereby assuming that everything from ANT_HOME/lib will be available on the system classloader. My understanding is that Class.forName uses the current loader - i.e. the defining loader for the class - which for most tasks is the main AntClassLoader. So far using the ClassLoader task ( which just adds jars to the main loader ) seems to work fine and never run into any problem with Class.forName not finding something. I would also add the JBoss class loading scheme - which is also adding jars, with few twists to support reloading - is also working fine with Class.forName. ( yes, I know I need to write the docs for the loader task - this is the first thing I'll do after I finish with the current tasks ). Costin
Re: VOTE: new committer: Jesse Stockall
On Sunday, April 6, 2003, at 01:13 AM, Steve Loughran wrote: I nominate Jesse Stockall as a committer Cool, so what happens now? Jesse Stockall - [EMAIL PROTECTED] CRYPTOCard Corp.
Re: VOTE: new committer: Jesse Stockall
At 11:13 PM 4/5/2003, Steve Loughran wrote: I nominate Jesse Stockall as a committer +1
Re: VOTE: new committer: Jesse Stockall
- Original Message - From: Jesse Stockall [EMAIL PROTECTED] To: Ant Developers List [EMAIL PROTECTED] Sent: Monday, April 07, 2003 11:49 Subject: Re: VOTE: new committer: Jesse Stockall On Sunday, April 6, 2003, at 01:13 AM, Steve Loughran wrote: I nominate Jesse Stockall as a committer Cool, so what happens now? you get to be the build manager for the next release and we add your home phone number to the install docs as the 7x24 support line :)
Re: [Patch] trying solve w2k command line length limitations
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 07, 2003 11:33 Subject: Re: [Patch] trying solve w2k command line length limitations Stefan Bodewig wrote: On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little URLClassLoader your Launcher provides. Many places inside Ant use Class.forName, thereby assuming that everything from ANT_HOME/lib will be available on the system classloader. My understanding is that Class.forName uses the current loader - i.e. the defining loader for the class - which for most tasks is the main AntClassLoader. So far using the ClassLoader task ( which just adds jars to the main loader ) seems to work fine and never run into any problem with Class.forName not finding something. Ted Newards Understanding Class.forName() doc on develop.com is the reference guide here. I recall that stuff in JRE/lib/ext is on a separate classloader, and of course you can't find stuff belonging to subsidiary classloaders. Then there is the issue of the thread context classloader (thread.getContextClassLoader()), that does not get set properly on Sun ONE app server. It's a 1.2 feature so we've ignored it in ant till now. I would also add the JBoss class loading scheme - which is also adding jars, with few twists to support reloading - is also working fine with Class.forName. ( yes, I know I need to write the docs for the loader task - this is the first thing I'll do after I finish with the current tasks ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18667] - javah module no longer works with Java 1.4.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=18667. 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=18667 javah module no longer works with Java 1.4.2 --- Additional Comments From [EMAIL PROTECTED] 2003-04-07 21:18 --- It looks like javah is now implemented as a doclet. I don't think any of the arguments hava changed. com.sun.tools.javah.Main no longer is constructed with the arguments to run against. The new implementation has a no arg constructor. The new main method verifies the arguments, appends to more arguments for javadoc(-private and -Xclasses, and invokes javadoc with the following command, com.sun.tools.javadoc.Main.execute( javadoc, com.sun.tools.javah.MainDoclet, args1); com.sun.tools.javah.MainDoclet does not appear to invoke System.exit, and I think the execute method of com.sun.tools.javadoc.Main will not call System.exit. I think invoking javadoc with the javah doclet it the way to go for 1.4.2.
DO NOT REPLY [Bug 18768] - WAR task (or ZIP base ?) generates amazing archives
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=18768. 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=18768 WAR task (or ZIP base ?) generates amazing archives --- Additional Comments From [EMAIL PROTECTED] 2003-04-07 22:31 --- Yes, it is fixed - we set the target milestone when a bug is fixed, in dicating in which release it will be available.
