DO NOT REPLY [Bug 19259] - Ant projects should support init and final project/ attributes
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=19259. 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=19259 Ant projects should support init and final project/ attributes --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 00:57 --- In ant 1.5 you can put a taskdef outside of any target to have it run first; in ant1.6 anything goes. This is an implicit init target. project init=init default=all final=end taskdef name=foo classname=my.custom.class/ target name=all echo message=Hello World/ /target /project
DO NOT REPLY [Bug 19187] - ReplaceRegExp cannot handle multi-byte encodings
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=19187. 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=19187 ReplaceRegExp cannot handle multi-byte encodings --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 05:59 --- It must still be broken in 1.5.3, because there were no code changes in ReplaceRegExp.java from 1.5.1. But I don't know about 1.6, and an encoding attribute sounds good!
DO NOT REPLY [Bug 19252] - untar does not untar symbolic links properly
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=19252. 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=19252 untar does not untar symbolic links properly [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Version|1.5.1 |1.5.3 --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 06:08 --- I guess you are aware of the fact that Java doesn't know about symlinks at all. It may be possible to check whether ln is available as a command and execute it if a symbolic link inside the archive is encountered, that's why I didn't close this report as WONTFIX right away. If you want to take a stab at it, look into the new symlink task in Ant's CVS repository to get an idea of what is involved here.
DO NOT REPLY [Bug 19150] - Command-line argument jvmarg attribute file not working.
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=19150. 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=19150 Command-line argument jvmarg attribute file not working. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID
DO NOT REPLY [Bug 19187] - ReplaceRegExp cannot handle multi-byte encodings
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=19187. 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=19187 ReplaceRegExp cannot handle multi-byte encodings [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 06:12 --- You are correct, the changes didn't get merged over. Moreover, I just rechecked CVS HEAD and realized that the branch where the byline has been set to false still has this problem for multibyte encodings and - even worse - ignores the encoding attribute.
DO NOT REPLY [Bug 19187] - ReplaceRegExp cannot handle multi-byte encodings
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=19187. 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=19187 ReplaceRegExp cannot handle multi-byte encodings [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|REOPENED|NEW Version|1.5.1 |1.5.3
DO NOT REPLY [Bug 19150] - Command-line argument jvmarg attribute file not working.
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=19150. 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=19150 Command-line argument jvmarg attribute file not working. --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 06:14 --- Created an attachment (id=5985) Simple example of the problem
DO NOT REPLY [Bug 19150] - Command-line argument jvmarg attribute file not working.
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=19150. 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=19150 Command-line argument jvmarg attribute file not working. --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 06:23 --- Pls expand the zip directly under c:\ Otherwise you will have to edit the scripts. Opena command promt in the c:\build\prj\ folder. Type setenv Type ant This gives the errormessage: C:\build\prjant Buildfile: build.xml init: [java] java.lang.NoClassDefFoundError: C:\build\cfg\compile/properties [java] Exception in thread main [java] Java Result: 1 BUILD SUCCESSFUL Total time: 1 second
DO NOT REPLY [Bug 19150] - Command-line argument jvmarg attribute file not working.
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=19150. 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=19150 Command-line argument jvmarg attribute file not working. --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 07:58 --- My assumption of the file attribute, was that the underlying code reads the cmdline args in the file, and puts on the cmdline. (2) The file attribute of jvmarg means that you want to pass the absolute path of the file on the command line - it does not read the file at all. I don't understand. Can you please give an example of the usage ?
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional ReplaceRegExp.java
bodewig 2003/04/24 02:11:39
Modified:.WHATSNEW
src/main/org/apache/tools/ant/taskdefs/optional
ReplaceRegExp.java
Log:
Properly deal with multi-byte encodings by reusing existing code that does.
PR: 19187
Revision ChangesPath
1.404 +3 -0 ant/WHATSNEW
Index: WHATSNEW
===
RCS file: /home/cvs/ant/WHATSNEW,v
retrieving revision 1.403
retrieving revision 1.404
diff -u -r1.403 -r1.404
--- WHATSNEW 23 Apr 2003 16:00:59 - 1.403
+++ WHATSNEW 24 Apr 2003 09:11:38 - 1.404
@@ -106,6 +106,9 @@
* build.sh install had a problem on cygwin (with REALANTHOME).
Bugzilla Report 17257
+* replaceregexp didn't work for multi-byte encodings if byline was false.
+ Bugzilla Report 19187.
+
Other changes:
--
* Six new Clearcase tasks added.
1.19 +1 -11
ant/src/main/org/apache/tools/ant/taskdefs/optional/ReplaceRegExp.java
Index: ReplaceRegExp.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/ReplaceRegExp.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ReplaceRegExp.java4 Apr 2003 13:51:11 - 1.18
+++ ReplaceRegExp.java24 Apr 2003 09:11:38 - 1.19
@@ -416,17 +416,7 @@
pw.flush();
} else {
-int flen = (int) f.length();
-char tmpBuf[] = new char[flen];
-int numread = 0;
-int totread = 0;
-
-while (numread != -1 totread flen) {
-numread = br.read(tmpBuf, totread, flen);
-totread += numread;
-}
-
-String buf = new String(tmpBuf);
+String buf = fileUtils.readFully(br);
String res = doReplace(regex, subs, buf, options);
DO NOT REPLY [Bug 19150] - Command-line argument jvmarg attribute file not working.
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=19150. 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=19150 Command-line argument jvmarg attribute file not working. --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 09:19 --- I think I've understood pretty well what you thought the attribute would do. I don't have a use case for this attribute in the jvmarg context. jvmarg supports this attribute as it is implemented by the same code that also implements arg - and there are tons of use-cases where you want to pass the absolute path of a file as a command line argument to an arbitrary executable.
DO NOT REPLY [Bug 17844] - Standardized deployment files for Ant optional task jars (drag + drop tasks)
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=17844. 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=17844 Standardized deployment files for Ant optional task jars (drag + drop tasks) --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 09:32 --- Created an attachment (id=5991) fixes to get unit tests working
cvs commit: ant/src/main/org/apache/tools/ant/filters TokenFilter.java
bodewig 2003/04/24 02:37:48
Modified:src/main/org/apache/tools/ant/filters TokenFilter.java
Log:
More code reuse
Revision ChangesPath
1.3 +2 -11
ant/src/main/org/apache/tools/ant/filters/TokenFilter.java
Index: TokenFilter.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/filters/TokenFilter.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TokenFilter.java 22 Apr 2003 18:23:54 - 1.2
+++ TokenFilter.java 24 Apr 2003 09:37:48 - 1.3
@@ -65,6 +65,7 @@
import org.apache.tools.ant.types.Parameter;
import org.apache.tools.ant.types.RegularExpression;
import org.apache.tools.ant.types.Substitution;
+import org.apache.tools.ant.util.FileUtils;
import org.apache.tools.ant.util.regexp.Regexp;
/**
@@ -358,17 +359,7 @@
public String getToken(Reader in)
throws IOException
{
-StringBuffer output = new StringBuffer();
-char[] buffer = new char[8192];
-while (true) {
-int nread = in.read(buffer, 0, 8192);
-if (nread == -1)
-break;
-output.append(buffer, 0, nread);
-}
-if (output.length() == 0)
-return null;
-return output.toString();
+return FileUtils.readFully(in);
}
/**
DO NOT REPLY [Bug 17844] - Standardized deployment files for Ant optional task jars (drag + drop tasks)
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=17844. 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=17844 Standardized deployment files for Ant optional task jars (drag + drop tasks) --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 09:50 --- I am looking at patch id = 5838. It is really cool. However it does place a new requirement on the use of the Project object. One needs to call Project#setCoreLoader() to get the taskdefs and the typedefs, or one needs to clone the taskdefs and the typedefs from a parent Project. The second is done by the Ant Task, (and thus by antcall and subant), but for the unit tests a Project Object is created without a parent project. Patch id=5991, adds a call to setCoreLoader() for BuildFileTest and for ProjectTest
DO NOT REPLY [Bug 19150] - Command-line argument jvmarg attribute file not working.
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=19150. 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=19150 Command-line argument jvmarg attribute file not working. --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 11:41 --- Is it wrong to say then, that if you ever use the file attribute of the jvmarg task, it will always render the error: [java] java.lang.NoClassDefFoundError: C:\build\cfg\compile , no matter how you use it, making the file attribute useless !?
DO NOT REPLY [Bug 19150] - Command-line argument jvmarg attribute file not working.
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=19150. 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=19150 Command-line argument jvmarg attribute file not working. --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 11:56 --- It may depend on the Java VM. It could be that java in some future version will have a command line option that takes an additional file argument. OK, this has lead me to construct an esoteric use-case: java classname=... jvmarg value=-classpath/ jvmarg file=build/my.jar/ /java will invoke java with the arguments -classpath FULL-PATH-TO/build/my.jar. In this case, it will not lead to the error message you've seen. It is not a good use-case (and I don't know of any good one, I already said so), but it is an expamle where the outcome is not the NoClassDefFoundError. If Java 47.11 is going to have an option -paramfile that expects a filename as additional parameter, the file attribute of jvmarg has suddenly become useful.
Re: antlib
On Thu, 24 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Two years ago (or was it three?) One. this proposal got nowhere because it got picked appart to death. I've seen the danger myself, this is why I've delayed my responses today. In the end we are not that far apart at all. Let's get the things together then. * antlib needs a way to define mappings between names and classes. Costin prefers a properties file. Most others prefer XML. My argument for XML is the extensibility. We will need versioning, we will need some statement of pre-reqs (like this antlib requires log4j), we will need additional capabilities we do not see now. We certainly could put this into MANIFEST.MF, but it would be hard to put all of this into a properties file. I like to keep the information in a single place, so properties plus manifest is no good idea IMHO. * if we are having problems with roles right now, lets start small. Let's make a version of antlib that knows about two predefined roles, task and data-type. I think this is already feature complete in the proposal (which does even more). Let's move this code with the restriction to tasks and types into the main branch ASAP. Let's sort out the classloading requirements as well as the interplay of antlib with taskdef and typedef here. After this flies, I'd expect us to get roles sorted out. If we feel like removing the difference between tasks and types, we can do so then as well. Stefan
DO NOT REPLY [Bug 19150] - Command-line argument jvmarg attribute file not working.
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=19150. 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=19150 Command-line argument jvmarg attribute file not working. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 12:59 --- Thanks, now I get it. The Ant documentation currently has no examples of how to use the file attribute in this context.
cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs UnzipTest.java
bodewig 2003/04/24 06:02:57
Modified:.WHATSNEW
src/etc/testcases/taskdefs unzip.xml
src/main/org/apache/tools/ant/taskdefs Expand.java
src/testcases/org/apache/tools/ant/taskdefs UnzipTest.java
Added: src/etc/testcases/taskdefs/zip test.exe
Log:
unzip can now deal with self-extracting archives.
PR: 16213
Submitted by: Jason Salter jasonsalter at hotmail dot com
Revision ChangesPath
1.405 +3 -0 ant/WHATSNEW
Index: WHATSNEW
===
RCS file: /home/cvs/ant/WHATSNEW,v
retrieving revision 1.404
retrieving revision 1.405
diff -u -r1.404 -r1.405
--- WHATSNEW 24 Apr 2003 09:11:38 - 1.404
+++ WHATSNEW 24 Apr 2003 13:02:53 - 1.405
@@ -273,6 +273,9 @@
* A wrapper script for OS/2 has been added.
+* unzip will now detect and successfully extract self-extracting
+ archives. Bugzilla Report 16213.
+
Changes from Ant 1.5.2 to Ant 1.5.3
===
1.5 +5 -0 ant/src/etc/testcases/taskdefs/unzip.xml
Index: unzip.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/unzip.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- unzip.xml 7 Feb 2003 14:59:06 - 1.4
+++ unzip.xml 24 Apr 2003 13:02:56 - 1.5
@@ -63,4 +63,9 @@
/patternset
/unzip
/target
+
+ target name=selfExtractingArchive
+mkdir dir=unziptestout/
+unzip dest=unziptestout src=zip/test.exe/
+ /target
/project
1.1 ant/src/etc/testcases/taskdefs/zip/test.exe
Binary file
1.42 +40 -7 ant/src/main/org/apache/tools/ant/taskdefs/Expand.java
Index: Expand.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Expand.java,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -r1.41 -r1.42
--- Expand.java 7 Mar 2003 11:23:01 - 1.41
+++ Expand.java 24 Apr 2003 13:02:56 - 1.42
@@ -56,14 +56,16 @@
import java.io.File;
import java.io.FileInputStream;
-import java.io.FileNotFoundException;
+import java.io.RandomAccessFile;
import java.io.FileOutputStream;
-import java.io.IOException;
+import java.io.FileNotFoundException;
import java.io.InputStream;
+import java.io.IOException;
+import java.util.Arrays;
import java.util.Date;
import java.util.Vector;
-import java.util.zip.ZipEntry;
import java.util.zip.ZipInputStream;
+import java.util.zip.ZipEntry;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.DirectoryScanner;
import org.apache.tools.ant.Project;
@@ -78,6 +80,7 @@
* @author [EMAIL PROTECTED]
* @author Stefan Bodewig
* @author Magesh Umasankar
+ * @author a href=mailto:[EMAIL PROTECTED]Jason Salter/a
*
* @since Ant 1.1
*
@@ -92,6 +95,9 @@
private boolean overwrite = true;
private Vector patternsets = new Vector();
private Vector filesets = new Vector();
+private static final byte[] ZIPMARKER = {0x50, 0x4b, 0x03, 0x04};
+private static final int MARKER_SIZE = ZIPMARKER.length;
+private static final int MAX_LOOKAHEAD = 50 * 1024; // 50K.
/**
* Do the work.
@@ -148,11 +154,34 @@
protected void expandFile(FileUtils fileUtils, File srcF, File dir) {
log(Expanding: + srcF + into + dir, Project.MSG_INFO);
ZipInputStream zis = null;
+FileInputStream fis = null;
+RandomAccessFile raf = null;
+byte[] buff = new byte[MARKER_SIZE];
try {
-// code from WarExpand
-zis = new ZipInputStream(new FileInputStream(srcF));
-ZipEntry ze = null;
+raf = new RandomAccessFile(srcF, r);
+long offset = 0;
+int more = raf.read(buff);
+boolean foundMarker = false;
+while (more != -1 || offset MAX_LOOKAHEAD) {
+if (Arrays.equals(buff, ZIPMARKER)) {
+foundMarker = true;
+break;
+}
+raf.seek(++offset);
+more = raf.read(buff);
+}
+raf.close();
+raf = null;
+fis = new FileInputStream(srcF);
+if (foundMarker offset 0) {
+log(found a preamble of + offset
++ bytes, probably a self-extracting archive);
+fis.skip(offset);
+}
+
+zis = new ZipInputStream(fis);
+ZipEntry ze = null;
while ((ze = zis.getNextEntry()) !=
DO NOT REPLY [Bug 19275] New: - junit fails when test classes load native code
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=19275.
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=19275
junit fails when test classes load native code
Summary: junit fails when test classes load native code
Product: Ant
Version: 1.5.3
Platform: PC
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: Optional Tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The following code snippet is from a build file, it tests with Junit one class
that loads a native library with JNI under Linux, so the fork=yes attribute is
necessary:
junit fork=yes haltonfailure=off printsummary=on dir=${test.dir}
classpath
path refid=test.classpath/
pathelement location=${release.dir}/ianhd-test.jar/
/classpath
formatter type=xml/
formatter type=plain/
test name=es.interactivity.nhd.HardDiskTest
todir=${test.reports.dir}/
/junit
The result I get is:
[junit] Running es.interactivity.nhd.HardDiskTest
BUILD SUCCESSFUL
So the test did not run (the number of failed and passed tests is missing). When
I change the fork attribute to no the test runs:
[junit] Tests run: 34, Failures: 0, Errors: 0, Time elapsed: 3.649 sec
BUILD SUCCESSFUL
But this is not a valid workaround because adding a second test with fork=no
will fail when loading the native library (java.lang.UnsatisfiedLinkError:
Native Library /usr/lib/libianhd.so.1.0.0 already loaded in another
classloader).
Re: antlib
On Thu, 24 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: I'm not fond of this pre-req thing you're describing, I didn't make myself clear, that's obvious. In good old Ant terms: available classname=org.apache.log4j.Category property=Log4j.present/ failThe antlib requires log4j version XYZ to run/fail Maps to the idea of reusing Ant's existing vocabulary. I want to enable the antlib to state what it needs, I didn't think of a way to satisfy the pre-reqs (at least not yet). I think classloading issues would be greatly simplified if Ant loaded only its core in the system CL, and everything else in child AntLoaders. It would simplify a lot but break backwards compatibility - the impact depends on how broad you define what belongs to the core 8-) Is the Java task part of the core? There are several optional tasks that create Java task internally in Ant itself, much more to be expected outside of Ant. Sequential? ExecTask? Mkdir? Soon you'll end up having almost everything back on the system classloader (or at least on a classloader common to all tasks). We should enable such a mechanism, but we need to keep the door open for the old mechanism. We may even be forced to make the old classloading scheme the default for everything that could be loaded from the system classloader in Ant 1.5.3. Stefan
Re: antlib
On Thursday 24 April 2003 11:47, Jose Alberto Fernandez wrote:
Obviously (b) is much better. So they define their antlib as follows:
antlib
condition name=cpuusage
classname=com.amazing.queries.CpuUsage
adaptor=com.amazing.ant.ConditionAdaptor/
condition name=latency
classname=com.amazing.queries.NetLatency
adaptor=com.amazing.ant.ConditionAdaptor/
condition name=diskfull
classname=com.amazing.queries.DiskFull
adaptor=com.amazing.ant.ConditionAdaptor/
/antlib
This is not the way antlib works at the moment. The adapator class is
associated with the role and not a role instance. One could however
make an amazing.condition :-
role name=amazing.condition
class=o.a.t.a.taskdefs.condition.Condition
proxy=com.amazing.ant.ConditionAdaptor/
and then
amazing.condition name=cpuusage
classname=com.amazing.queries.CpuUsage/
etc..
and then use them (with dynamicElement in ConditionBase)
public void dynamicElement(o.a.t.a.types.Condition c) {}
No need to add code to if or pollute the namespace with cpuusage
(i.e. a task of the name cpuusage could be defined using a different class
or the same class with a different adaptor).
As regards the XML language usage, I feel that Costin is correct, we should
not invent a new xml languge, the xml file should be ant tasks and types -
like the contents of a target/.
role/ should be an ant task that can be used in the antlib xml file or in
a normal build.xml. typedef/ and taskdef/ should be used to define
tasks and types, and a define role=x/ should be used to define role
instances (can replace typedef/taskdef) - so the above example becomes
define role=amazing.condition name=cpuusage
classname=com.amazing.queries.CpuUsage/
define role=task name=copy classname=o.,// (same as taskdef)
define name=,,, classname=,,,/ (same as typedef)
Peter
RE: antlib
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2003 11:39 AM J2SDK1.2 + defines a mechanism for declaring dependencies. Which is actually required for servlet containers and j2ee. (i.e. the manifest ). Why would we want to invent our own ? JDK only defines a mechanism to indicate which other jars are need to be loaded to find additional classes (which are located relatively to the current jar) This is not dependency declarations. There's the extension mechanism though... --DD
RE: antlib
Jose Alberto Fernandez wrote: If we are to use XML, let's at least use ant syntax - i.e. antlib taskdef typedef ... /antlib Things people already know and understand, we have all the code to process it, and if we want to extend - it's quite easy. Please, don't invent a new language. But we are. To start with the top element in antlib and not project your things inside are not the taskdef tasks, they are something different (for example the file, resource, classpath, classpathref and loaderRef attributes are meaningless here) What I meant is the antlib descriptor would be an XML file that is a subset of the ant syntax. We can restrict this to taskdef, typeded, condition and few other that we need, and add more later. It will confuse people more than anything else if the two things have the same name. The 2 things will be the same thing. In particular the language that is in the proposal - which IMO is the worst part in it. Sorry to here that. The language was trying to make writing antlibs easier you really only have one basic declaration which defines the elements available to you: role name=X classname=x.y.Z adaptor=p.q.R/ every declaration like this, implicitly makes available a new element tag: X name=Xname classname=Xa.Xb.XC/ That's it. The DTD is dynamic just like the DTD of ANT is dynamic. The only think that the implementation gives you is that the role declarations for task and type are implicitly declared incide the antlib element. That's it. I thought that was as simple as I could do. The problem is that: - instead of only defining the ant lib, it also adds concepts of role. If everyone but me wants roles - I could live with it, but _not_ if they are added as a side effect of the antlib. - do you call this simpler or easier than the properties file that we use currently ? The common use case is defining tasks and datatypes. I support properties because: - that's what people already do. If we need XML later for extra fancy things, very easy to add. - it keeps the overhead to a minimum at runtime - it is _not_ easy to bloat it. Properties files are the most abuse thing in java, tryings to encode as much information as possible in the name of the key. If you take a look at things like log4j and such their P-file configurations are just as full of this.that.1.here=X this.that.1.there=Y The fact that others abuse properties doesn't mean they are wrong. There are a lot of abuses on XML ( far more than properties ). ( I haven't tried the new MSFT office - but I heard that it has some very easy use of XML ). Again - I have no problem if we don't use properties and use XML instead. My requirement ( and I'm going to fight as much as I can for this ) is to keep things _simple_. J2SDK1.2 + defines a mechanism for declaring dependencies. Which is actually required for servlet containers and j2ee. (i.e. the manifest ). Why would we want to invent our own ? JDK only defines a mechanism to indicate which other jars are need to be loaded to find additional classes (which are located relatively to the current jar) I assume you're talking about the ClassPath, which is just a way to specify the CLASSPATH, and has nothing to do with dependencies. I was talking about the real dependency part - with Requires-XXX. This is not dependency declarations. Costin
Re: antlib
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 24, 2003 7:33 PM Subject: Re: antlib Can you give us some pointers so that we can learn about these Extension-Name and Extension-List elements and understand how they help out for antlib ? To avoid other missunderstandings - I am not refering to the ClassPath manifest element, but to the Extension-Name and Extension-List elements in the manifest. It defines a hook that allows you to plug your own component factory. You get a namespace and element name as parameter, and you can return any ProjectComponent. It is used like the PropertyHelper ( i.e. a chain, any task can add hooks ). Nothing fancy. Can you supply some Hello World examples of what can be done with the ComponentHelper task or give us pointers to such examples. I have no problem with using XML syntax and not properties- if it's a subset of ant, or something close enough. I'm -1 on combining antlib with roles and using the syntax in the proposal. Which problem do you see with this notion of roles ? For me it is clear. Antoine
DO NOT REPLY [Bug 19252] - untar does not untar symbolic links properly
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=19252. 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=19252 untar does not untar symbolic links properly --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 18:04 --- You may also want to note bug 15244, and read the old bug 1550.
DO NOT REPLY [Bug 19280] New: - add the ability to echo the classpath
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=19280. 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=19280 add the ability to echo the classpath Summary: add the ability to echo the classpath Product: Ant Version: 1.5 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I may be missing something, as I am not an ant guru -- but if there isn't a way to echo the classpath (the stuff you gather up in your classpath element inside your javac task) when doing a compile, then there should be. And I couldn't figure out how to do this, so I'll assume that you can't. Now I know that you can set up your classpath in a property, and then echo out that property, but if you have to do things that way just to be able to know for sure what your classpath really is, then the value of the classpath element is greatly reduced. As far as why this should be added, it is widely known that a great number of compilation troubles involve an incorrectly set classpath. So it is of obvious basic utility to everyone to be able to see what classpath their compiler actually ran against. They say design for the common case, and this is it! For example, maybe someone misused the syntax of a pathelement in some way and they are assuming that a jar has been added to the classpath that ant couldn't find. It would immediately clue them in that something was wrong with how they used that pathelement if they looked at what their actual classpath was and saw that the class they thought they included wasn't there. There are at least a million and one other situations in which this would be helpful.
RE: antlib
From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2003 12:23 PM The common use case is defining tasks and datatypes. So you -1 roles because you don't need them, at the expense of all the people who need to declare more than tasks and datatypes, but conditions, filters, mappers, and for me my own custom extension like the buildpathresolver??? You must be kidding, right? So how do *you* propose we plug in custom implementations of all the things mentioned above, if not with roles? --DD
DO NOT REPLY [Bug 19280] - add the ability to echo the classpath
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=19280. 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=19280 add the ability to echo the classpath --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 18:21 --- Two ways to print a path, both littering the archives... See property refid=pathID/ and pathconvert for a nicely formatted version. --DD
Re: antlib
Antoine Levy-Lambert wrote: Can you give us some pointers so that we can learn about these Extension-Name and Extension-List elements and understand how they help out for antlib ? http://java.sun.com/j2se/1.4.1/docs/guide/jar/jar.html#Main%20Attributes http://java.sun.com/j2se/1.4.1/docs/guide/extensions/versioning.html Servlet 2.3+ required containers to support this, there are many servers that use this information, many packages already include a manifest and are starting to support this. I'm not saying this is perfect - but it is a reasonable and standard solution, and better than us inventing our own. It defines a hook that allows you to plug your own component factory. You get a namespace and element name as parameter, and you can return any ProjectComponent. It is used like the PropertyHelper ( i.e. a chain, any task can add hooks ). Nothing fancy. Can you supply some Hello World examples of what can be done with the ComponentHelper task or give us pointers to such examples. I'll try to add more documentations and an example. I have no problem with using XML syntax and not properties- if it's a subset of ant, or something close enough. I'm -1 on combining antlib with roles and using the syntax in the proposal. Which problem do you see with this notion of roles ? For me it is clear. Look - adding roles concept to ant, and adding antlib are 2 separate issues. If everyone else except me wants to add roles - and doesn't want to use interfaces, but explicit declarations - I could change my vote to -0 on roles. Using XML for descriptor - fine, as long as it is not a completely new format. Using a subset of ant is IMO a very good solution, and it would allow us to easily enhance it later on. Mixing roles with antlib proposal - that's where I'm strongly -1. Costin
DO NOT REPLY [Bug 18581] - ClearCase ChangeLog 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=18581. 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=18581 ClearCase ChangeLog Task --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 18:27 --- I've submitted this task awhile back, and haven't heard much. I am wondering what's the process of submitting new tasks and having them approved or rejected. I think its a nifty task, but not exactly very complicated to create. I would be glad to modify it or enhance it if there is a need for something like that in ant. I guess I am looking for closure. :) Vadim
Re: antlib
Erik Hatcher wrote: We don't really need to get hung up on the syntax of a descriptor at this stage. Let's get something working in HEAD and work with it. XDoclet can be used to generate these descriptors anyway, and it likely be considered the best practice way to do it anyway. I think the syntax of the descriptor is pretty important. Xdoclet is great - but the fact that it can generate any descriptor shouldn't mean the syntax of the XML can be anything. The biggest problem with XML is that people just throw away new syntaxes, and claim some tools will support it anyway so it doesn't matter what's inside. Just look at the dozens of RSS versions, or the office XML, or the dozens of configuration XML formats. That's it. The DTD is dynamic just like the DTD of ANT is dynamic. This is where I differ. I like what I've heard so far, but I really don't like the total looseness of Ant build files, and I don't think we should propagate that same scheme. I understand how it evolved and that ease of use was one of the primary factors for Ant's looseness, not to mention that it was around before namespaces were really solidified. The looseness is pretty fundamental in ant, and at least IMO is one of the reasons it works so well. We don't need these descriptors to have dynamic element names, do we? Again, lets not get hung up on the descriptor syntax. Working implementation first - then we can debate the details. We can make it the defining goal for an Ant 1.6 release when all the fiddly details have been ironed out! :) We have had working implementation(s) for quite a while. It's the fiddly details that are the problem. Costin
DO NOT REPLY [Bug 19280] - add the ability to echo the classpath
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=19280. 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=19280 add the ability to echo the classpath --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 18:32 --- Dominique's suggestions require defining a classpath outside of javac and reusing it there. But you can also run with the -debug (maybe even -verbose works?) switch and it will output the details of javac.
DO NOT REPLY [Bug 19280] - add the ability to echo the classpath
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=19280. 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=19280 add the ability to echo the classpath --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 18:38 --- Yeah, sure, it must be declared outside, and refid'd inside javac. Also forgot to mention echopath that I posted, and should be thus in the archives as well. --DD
Re: antlib
On Thursday, April 24, 2003, at 02:23 PM, Costin Manolache wrote: Erik Hatcher wrote: We don't really need to get hung up on the syntax of a descriptor at this stage. Let's get something working in HEAD and work with it. XDoclet can be used to generate these descriptors anyway, and it likely be considered the best practice way to do it anyway. I think the syntax of the descriptor is pretty important. Obviously I disagree, but not terribly strongly. This is where I differ. I like what I've heard so far, but I really don't like the total looseness of Ant build files, and I don't think we should propagate that same scheme. I understand how it evolved and that ease of use was one of the primary factors for Ant's looseness, not to mention that it was around before namespaces were really solidified. The looseness is pretty fundamental in ant, and at least IMO is one of the reasons it works so well. My take is that since we are using XML for build file syntax that we should embrace all of the features of XML like namespaces and schemas. Currently we are playing fast and loose with it and tools are not typically happy with build.xml files. I know in my build file IDEA hilites tons of errors (that are not really errors). You are proposing that we use Java's standard MANIFEST features, but why not stick to standard XML features like a schema? Don't get me wrong though - I think its quite cool that Ant is as extensible as it is and I've learned a lot of cool things with reflection and how it plays with the build file format thanks to working with Ant. I'm the one that added the DyanmicConfigurator - so I can be blamed for making schema compliance even more impossible to obtain. Again, lets not get hung up on the descriptor syntax. Working implementation first - then we can debate the details. We can make it the defining goal for an Ant 1.6 release when all the fiddly details have been ironed out! :) We have had working implementation(s) for quite a while. But the current one does not support adding other components like conditions, mappers, filters, and selectors. Erik
RE: antlib
Dominique Devienne wrote: From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2003 12:23 PM The common use case is defining tasks and datatypes. So you -1 roles because you don't need them, at the expense of all the people who need to declare more than tasks and datatypes, but conditions, filters, mappers, and for me my own custom extension like the buildpathresolver??? No, because they add complexity to the simple case and to the lower layer. I have nothing against roles - if implemented at a higher layer ( using interfaces, declarations, introspection - or any other means ). I am -1 on bundling the roles with the antlib. You want roles ? Make a proposal for roles. You should be able to use roles without antlib, and you should be able to use antlib without roles. So how do *you* propose we plug in custom implementations of all the things mentioned above, if not with roles? --DD Add them as project compoenents ( or types if we don't merge tasks+type ), and use interfaces, or introspection, or any other form of metadata. Costin
DO NOT REPLY [Bug 19284] New: - Jar files created by Ant 1.5.3 are not viewable by WinZip
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=19284. 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=19284 Jar files created by Ant 1.5.3 are not viewable by WinZip Summary: Jar files created by Ant 1.5.3 are not viewable by WinZip Product: Ant Version: 1.5.3 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am the builder for a 100% Java product. I use and love Ant. When I upgraded to Ant 1.5.3, the development community informed me that they were not able to view the Ant-generated Jar files using WinZip, a utility installed on everyone's desktop (http://www.winzip.com). I reverted back to Ant 1.5.2 and all was OK.
DO NOT REPLY [Bug 19284] - Jar files created by Ant 1.5.3 are not viewable by WinZip
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=19284. 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=19284 Jar files created by Ant 1.5.3 are not viewable by WinZip --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 19:29 --- That's really strange, because it's 1.5.2 which had this bug, and 1.5.3 that fixes it (and 1.5.1 was OK too, but had other problems). Could it be you interverted your two Ant installs? Check ant.jar's manifest of both your installs maybe? --DD
DO NOT REPLY [Bug 19285] - Invalid path when using javac with fork=true
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=19285. 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=19285 Invalid path when using javac with fork=true --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 19:35 --- Sounds like a bug... Could you try with a nested src instead of 'srcdir', just in case. Thanks, --DD
DO NOT REPLY [Bug 16928] - Can not delete JAR 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=16928. 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=16928 Can not delete JAR files --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 19:39 --- I have the same problem when using JDK 1.4, but JDK 1.4.1_02 works well. And fork=yes helps. This problem is actually documented under javac task.
Re: antlib
On Thursday, April 24, 2003, at 03:06 PM, Costin Manolache wrote: Erik Hatcher wrote: I think the syntax of the descriptor is pretty important. Obviously I disagree, but ngot terribly strongly. So you believe that anything can go in the XML tags, no design or thinking is needed - because you could translate it with XSL or some tools will process it ? This is getting a bit exaggerated but I don't feel the syntax of an XML descriptor is that relevant right now given the other issues on the table. That's the main point I'm making with this. But the current one does not support adding other components like conditions, mappers, filters, and selectors. Does ant support this ? No, not currently in a pluggable manner. Isn't that the goal for antlib? Erik
RE: antlib
Dominique Devienne wrote: Tell me what's the point of AntLib if it's just to define tasks/types? That's what currently supports tasks and types. There is no notion of role at this moment in ant. I don't know how you twisted my words into I don't want roles. I just don't want roles implemented this way, and I want the antlib to do one thing well, When roles are added to ant, in one form or another, we can add them to antlib. Are you saying that those roles can't be used without antlib ? Sounds like you have never needed to write anything but custom tasks and types Costin, but it is a major deficiency of Ant not be able to plug in a consistent manner all these other 'types' of typed bean you so easily dismiss. --DD I don't dismiss the the types, nor the consistency. I dismiss bundling the concept of roles with that of antlib, and the idea that there is only one possible implementation for that ( i.e. what's now in antlib ). You can have the same role using interfaces or using introspection or using external metadata. And you can have an antlib that deals with loading components - without caring what kind of components they are, and this is a simpler and better implementation ( IMO ) Costin
Re: antlib
Erik Hatcher wrote: So you believe that anything can go in the XML tags, no design or thinking is needed - because you could translate it with XSL or some tools will process it ? This is getting a bit exaggerated but I don't feel the syntax of an XML descriptor is that relevant right now given the other issues on the table. That's the main point I'm making with this. For Antlib ( i.e. having the task/types loaded ) - the only remaining issues that I know are the descriptor syntax and format ( and it seems most people want the XML, so the syntax remain the only problem in this space ), and the use of namespaces. For NS - it seems we can do it later. For roles - that's IMO a different problem. But the current one does not support adding other components like conditions, mappers, filters, and selectors. Does ant support this ? No, not currently in a pluggable manner. Isn't that the goal for antlib? To load collections of ant components ( whatever ant define as component ). Not to define new component types. Are you saying that all those nice filters, selectors, etc can only be used if loaded by antlib ? You can define a task with taskdef in a regular ant file - why wouldn't you be able to define the condition without using an antlib ? Costin
RE: antlib
-Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2003 2:47 PM But the current one does not support adding other components like conditions, mappers, filters, and selectors. Does ant support this ? No, not currently in a pluggable manner. Isn't that the goal for antlib? To load collections of ant components ( whatever ant define as component ). Not to define new component types. Are you saying that all those nice filters, selectors, etc can only be used if loaded by antlib ? You can define a task with taskdef in a regular ant file - why wouldn't you be able to define the condition without using an antlib ? Because: 1) Having an xyzdef for every single one adds new elements for nothing, and is not extensible to custom types (like buildpath) to define its own new typed role/interface (buildpathresolver). 2) antlib supercedes taskdef/typedef (which remain for backward compatibility), adding extensibility to other types (within Ant or not)! Why are you getting hang on antlib per se? What's bad about having an in-build-file antlib? It's not worse than a taskdef, and better because extensible to new roles/types/interfaces/beans, whatever! The point being that AntLib doesn't define new component types, it allows *me* and *every other* build file writer to define my own new component types and/or implementation of existing component types. I don't care how you want to implement it! I want the functionality AntLib provides ASAP, so if you don't provide a 'better' proposal that solves the same issue, namely being able to plug in not just types/tasks to Ant which are configured like regular types/tasks, then your -1 squarely goes against my *need*, and the needs of quite a few others; a need I hope you agree is important... --DD
DO NOT REPLY [Bug 19288] New: - Add noqualifier attribute to javadoc 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=19288. 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=19288 Add noqualifier attribute to javadoc task Summary: Add noqualifier attribute to javadoc task 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] This allows the user to specify packages that should not be prefixed to any class names. A common example (using the command line javadoc tool) would be: javadoc -noqualifier java.lang ...
RE: antlib
Dominique Devienne wrote: Because: 1) Having an xyzdef for every single one adds new elements for nothing, and is not extensible to custom types (like buildpath) to define its own new typed role/interface (buildpathresolver). You only need a componentdef ( or just use the existing typedef ) - and have class implement whatever interface you need. You can define any role you want by having an interface and classes implementing this interface. Costin 2) antlib supercedes taskdef/typedef (which remain for backward compatibility), adding extensibility to other types (within Ant or not)! Why are you getting hang on antlib per se? What's bad about having an in-build-file antlib? It's not worse than a taskdef, and better because extensible to new roles/types/interfaces/beans, whatever! The point being that AntLib doesn't define new component types, it allows *me* and *every other* build file writer to define my own new component types and/or implementation of existing component types. I don't care how you want to implement it! I want the functionality AntLib provides ASAP, so if you don't provide a 'better' proposal that solves the same issue, namely being able to plug in not just types/tasks to Ant which are configured like regular types/tasks, then your -1 squarely goes against my *need*, and the needs of quite a few others; a need I hope you agree is important... --DD
DO NOT REPLY [Bug 19293] - jar task does not remove obsolete entries
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=19293. 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=19293 jar task does not remove obsolete entries --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 21:31 --- I see that as completely normal... Your are not syncing the JAR with what's in your directory, you are updating the JAR, i.e. entries (as picked up by the fileset) not already in your JAR are added, and the ones in both that are newer are updated. The third kind of entries is left as is, by design. If you really want to sync, recreate the JAR from scratch. --DD
DO NOT REPLY [Bug 19293] - jar task does not remove obsolete entries
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=19293. 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=19293 jar task does not remove obsolete entries [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 21:46 --- Couldn't the jar task be made to scan jar files after adding missing or updated files, and remove entries that no longer exist in the file system? I realize this could be tricky if the jar file is assembled from several sources, and of course there is no point in doing so if this procedure would be slower than simply recreating the jar file from scratch, as you suggest.
DO NOT REPLY [Bug 19293] - jar task does not remove obsolete entries
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=19293. 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=19293 jar task does not remove obsolete entries [EMAIL PROTECTED] changed: What|Removed |Added Severity|Enhancement |Normal Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-04-24 21:55 --- Actually, there's no such thing as a real JAR update. Ant is forced to fully recreate a new JAR under the scene. As far as doing a real sync, it's technically possible, but would be changing the semantic of the JAR task, and breaking backward compatibility, so will not be done. Regards, --DD
