cvs commit: ant/src/etc/testcases/taskdefs war.xml
antoine 2003/04/22 16:16:30
Modified:src/main/org/apache/tools/ant/types ZipFileSet.java
src/etc/testcases/taskdefs war.xml
Log:
avoid backward compatibility problems for lib attribute of war task, so relax
ZipFileSet#getRef
Revision ChangesPath
1.17 +11 -10ant/src/main/org/apache/tools/ant/types/ZipFileSet.java
Index: ZipFileSet.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/types/ZipFileSet.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- ZipFileSet.java 18 Apr 2003 22:02:59 - 1.16
+++ ZipFileSet.java 22 Apr 2003 23:16:30 - 1.17
@@ -234,8 +234,8 @@
}
/**
- * A 3 digit octal string, specify the user, group and
- * other modes in the standard Unix fashion;
+ * A 3 digit octal string, specify the user, group and
+ * other modes in the standard Unix fashion;
* optional, default=0644
*
* @since Ant 1.5.2
@@ -247,7 +247,7 @@
this.fileMode =
UnixStat.FILE_FLAG | Integer.parseInt(octalString, 8);
}
-
+
/**
* @since Ant 1.5.2
*/
@@ -257,10 +257,10 @@
}
return fileMode;
}
-
+
/**
- * A 3 digit octal string, specify the user, group and
- * other modes in the standard Unix fashion;
+ * A 3 digit octal string, specify the user, group and
+ * other modes in the standard Unix fashion;
* optional, default=0755
*
* @since Ant 1.6
@@ -272,7 +272,7 @@
this.dirMode =
UnixStat.DIR_FLAG | Integer.parseInt(octalString, 8);
}
-
+
/**
* @since Ant 1.6
*/
@@ -284,7 +284,8 @@
}
/**
- * A ZipFileset accepts only another ZipFileSet as reference
+ * A ZipFileset accepts another ZipFileSet or a FileSet as reference
+ * FileSets are often used by the war task for the lib attribute
*/
protected AbstractFileSet getRef(Project p) {
if (!isChecked()) {
@@ -294,8 +295,8 @@
}
Object o = getRefid().getReferencedObject(p);
-if (!(o instanceof ZipFileSet)) {
-String msg = getRefid().getRefId() + doesn\'t denote a
zipfileset;
+if (!(o instanceof ZipFileSet) !(o instanceof FileSet)) {
+String msg = getRefid().getRefId() + doesn\'t denote a
zipfileset or a fileset;
throw new BuildException(msg);
} else {
return (AbstractFileSet) o;
1.3 +1 -1 ant/src/etc/testcases/taskdefs/war.xml
Index: war.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/taskdefs/war.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- war.xml 19 Apr 2003 17:10:26 - 1.2
+++ war.xml 22 Apr 2003 23:16:30 - 1.3
@@ -12,7 +12,7 @@
/target
target name=testlibrefs depends=setup
-zipfileset id=test dir=. includes=foobar/
+fileset id=test dir=. includes=foobar/
war webxml=war.xml destfile=${working.dir}/test.war
lib refid=test/
/war
Re: Backward incompatible change in war task?
I have fixed the problem.
Antoine
- Original Message -
From: Gianugo Rabellino [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, April 23, 2003 12:11 AM
Subject: Backward incompatible change in war task?
Hi there,
probably some of you are already aware of this problem since I posted
about it on the Gump ML. I've never been a power ant user, and I never
participated in the ant development process so please forgive me if this
discussion has been already done in the past (apart from
http://marc.theaimsgroup.com/?l=ant-devm=105077339807455w=2 I was
unable to find a particular reference to that).
In short, our beloved friend Gump found while building Xindice what I'd
label as a backward incompatible change in the war task. In
Xindice-land we are using the war task together with a lib subtask
that points (refid) to a fileset:
war
destfile=${dist.dir}/${project.filename}-${project.version}.war
update=false
webxml=config/web.xml
classes dir=${src.build.dir}/
webinf dir=config
include name=system.xml/
/webinf
lib refid=core.jars /
where core.jars is defined as a plain fileset in the project section.
Needless to say, this label is used elsewhere in the file so having it
as a refid makes it more mantainable for us: I don't consider a real
option to expand it inside the war target.
Unfortunately the Ant CVS version seems to accept only zipfilesets as
the argument to the lib element:
/home/rubys/jakarta/xml-xindice/build.xml:336: core.jars doesn't denote
a zipfileset
This is not easy to fix, since in turn the stable (released) version of
Ant (up to 1.5.3) doesn't allow for zipfileset in the project section.
So we're bitten by a chicken and egg problem, since we should either
ship the CVS version of Ant or just forget about it and let our Gump
builds fail. I don't like either option, so I'm wondering if there is a
solution I'm missing (again, I'm not an Ant guru at all), a reason for
this particular backward incompatible change, or a chance to see it
corrected in Ant CVS: my take is that not only Xindice will be bitten by
this.
TIA,
--
Gianugo Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18476] - copy with filtering modifies lineendings
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=18476. 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=18476 copy with filtering modifies lineendings --- Additional Comments From [EMAIL PROTECTED] 2003-04-22 23:35 --- snap! I was just about to submit the changes under windows. I have added a new patch against current cvs to fix the unit tests and to provide an alternative fix for stripjavacomments. The patched files are: src/etc/testcases/filters/head-tail.xml: add the targets for the filterreader tests src/testcases/org/apache/tools/ant/filters/HeadTailTest.java fix the result and expected filenames, I had them mixed up before, and the test succeeded as two non-existant files were matched src/main/org/apache/tools/ant/filters/StripJavaComments.java I initially had the same logic as your fix, but realized that the code would not work under mac line endings. Looking at the code, I released that \r, or \n where all that is needed to terminate the the \\ comment - tested this on windows. Cheers, Peter. PS. I have had difficulty in getting the following unit tests to work on windows: CopyTest - trancoding test - result not as expected ZipTest - last test - unable to delete a file XMLCatalogTest - most of the tests fail FileUnitTests - to/from uri and testRemoveLeadingPath Peter
cvs commit: ant/src/main/org/apache/tools/ant/types ZipFileSet.java
antoine 2003/04/22 16:33:32
Modified:src/main/org/apache/tools/ant/types ZipFileSet.java
Log:
fix because of class cast exception detected
Revision ChangesPath
1.18 +4 -1 ant/src/main/org/apache/tools/ant/types/ZipFileSet.java
Index: ZipFileSet.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/types/ZipFileSet.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ZipFileSet.java 22 Apr 2003 23:16:30 - 1.17
+++ ZipFileSet.java 22 Apr 2003 23:33:32 - 1.18
@@ -295,7 +295,10 @@
}
Object o = getRefid().getReferencedObject(p);
-if (!(o instanceof ZipFileSet) !(o instanceof FileSet)) {
+if (o instanceof FileSet) {
+ return (AbstractFileSet)(new ZipFileSet((FileSet)o));
+}
+else if (!(o instanceof ZipFileSet)) {
String msg = getRefid().getRefId() + doesn\'t denote a
zipfileset or a fileset;
throw new BuildException(msg);
} else {
DO NOT REPLY [Bug 18476] - copy with filtering modifies lineendings
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=18476. 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=18476 copy with filtering modifies lineendings --- Additional Comments From [EMAIL PROTECTED] 2003-04-22 23:40 --- I hadn't considered Mac. I will apply your patch tomorrow. Thanks, once again!
Re: [GUMP] Test Failure - Ant
On Tue, 22 Apr 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: From: Stefan Bodewig [EMAIL PROTECTED] Which documentation? I meant the ant manual page under docs/manual/CoreTasks/war.html Nested elements lib The nested lib element specifies a FileSet. Well, yes. This doesn't rule out zipfileset, I'd call it an implementation detail that the user shouldn't have to be aware of. Which also measn that using a reference to a plain fileset must work. What about changing the method signature of War#addLib from addLib(ZipFileSet fs) to addLib(FileSet fs) ? Would break this here war ... lib src=foo.zip/ /war which should work right now (and in Ant 1.3+). Yes this is new, it was possible to do fileset ... id=xyz/ war lib refid=xyz/ /war before I did my changes. Yes, I've seen Gianugo's post as well 8-) Stefan
Re: cvs commit: ant/src/main/org/apache/tools/ant/types ZipFileSet.java
On 22 Apr 2003, [EMAIL PROTECTED] wrote:
+if (o instanceof FileSet) {
+ return (AbstractFileSet)(new ZipFileSet((FileSet)o));
the cast is not needed here.
+}
+else if (!(o instanceof ZipFileSet)) {
will always be true as instanceof ZipFileSet implies instanceof
FileSet.
Maybe you really wanted something like
if (o instanceof FileSet) {
return (AbstractFileSet) o;
} else if (o instanceof FileSet) {
return (new ZipFileSet((FileSet) o));
} else {
String msg = getRefid().getRefId() + doesn\'t denote a zipfileset
or a fileset;
throw new BuildException(msg);
}
Stefan
ZipFileSet test failures in CVS HEAD
[junit] Testcase: testAttributes(org.apache.tools.ant.types.ZipFileSetTest):Caused an ERROR [junit] null [junit] java.lang.NullPointerException [junit] at org.apache.tools.ant.types.ZipFileSetTest.testAttributes(ZipFileSetTest.java:149) [junit] at java.lang.reflect.Method.invoke(Native Method) [junit] at junit.framework.TestCase.runTest(TestCase.java:154) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:318) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:872) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:562) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:538) [junit] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:231) [junit] at org.apache.tools.ant.Task.perform(Task.java:399) [junit] at org.apache.tools.ant.Target.execute(Target.java:309) [junit] at org.apache.tools.ant.Target.performTasks(Target.java:336) [junit] at org.apache.tools.ant.Project.executeTarget(Project.java:1404)[junit] at org.apache.tools.ant.Project.executeTargets(Project.java:1278) [junit] at org.apache.tools.ant.Main.runBuild(Main.java:611) [junit] at org.apache.tools.ant.Main.start(Main.java:198) [junit] at org.apache.tools.ant.Main.main(Main.java:245) [junit] Testcase: testCircularReferenceCheck(org.apache.tools.ant.types.ZipFileSetTest):FAILED [junit] Dir is basedir expected:null but was:/home/bodewig/ASF/jakarta/jakarta-ant [junit] junit.framework.AssertionFailedError: Dir is basedir expected:null but was:/home/bodewig/ASF/jakarta/jakarta-ant [junit] at junit.framework.Assert.fail(Assert.java:47) [junit] at junit.framework.Assert.failNotEquals(Assert.java:282) [junit] at junit.framework.Assert.assertEquals(Assert.java:64) [junit] at org.apache.tools.ant.types.AbstractFileSetTest.testCircularReferenceCheck(AbstractFileSetTest.java:281) [junit] at java.lang.reflect.Method.invoke(Native Method) [junit] at junit.framework.TestCase.runTest(TestCase.java:154) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:118) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:208) [junit] at junit.framework.TestSuite.run(TestSuite.java:203) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:318) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeInVM(JUnitTask.java:872) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:562) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:538) [junit] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:231) [junit] at org.apache.tools.ant.Task.perform(Task.java:399) [junit] at org.apache.tools.ant.Target.execute(Target.java:309) [junit] at org.apache.tools.ant.Target.performTasks(Target.java:336) [junit] at org.apache.tools.ant.Project.executeTarget(Project.java:1404)[junit] at org.apache.tools.ant.Project.executeTargets(Project.java:1278) [junit] at org.apache.tools.ant.Main.runBuild(Main.java:611) [junit] at org.apache.tools.ant.Main.start(Main.java:198) [junit] at org.apache.tools.ant.Main.main(Main.java:245)
Re: [PATCH] add test case for containsregexp
I'm taking care of it. Stefan
cvs commit: ant/src/testcases/org/apache/tools/ant/types/selectors ContainsRegexpTest.java
bodewig 2003/04/22 23:34:53
Modified:.build.xml
src/etc/testcases/types selectors.xml
Added: src/testcases/org/apache/tools/ant/types/selectors
ContainsRegexpTest.java
Log:
Add testcase for containsregexp selector.
Submitted by: Jay jvandermeer2 at comcast dot net
Revision ChangesPath
1.368 +2 -0 ant/build.xml
Index: build.xml
===
RCS file: /home/cvs/ant/build.xml,v
retrieving revision 1.367
retrieving revision 1.368
diff -u -r1.367 -r1.368
--- build.xml 22 Apr 2003 18:23:53 - 1.367
+++ build.xml 23 Apr 2003 06:34:52 - 1.368
@@ -1514,6 +1514,8 @@
unless=some.regexp.support/
exclude name=${optional.package}/sitraka/*.java
unless=some.regexp.support/
+ exclude
name=${ant.package}/types/selectors/ContainsRegexpTest.java
+ unless=some.regexp.support/
exclude name=${optional.package}/RhinoScriptTest.java
unless=bsf.present/
exclude name=${optional.package}/RhinoScriptTest.java
1.5 +26 -0 ant/src/etc/testcases/types/selectors.xml
Index: selectors.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/types/selectors.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- selectors.xml 11 Mar 2003 09:26:44 - 1.4
+++ selectors.xml 23 Apr 2003 06:34:52 - 1.5
@@ -5,6 +5,10 @@
property name=etc.dir value=../
property name=test.dir
value=selectortest/
+ property name=testregexpsrc.dir
+ value=regexpseltestsrc/
+ property name=testregexpdest.dir
+ value=regexpseltestdest/
property name=mirror.dir
value=selectortest2/
@@ -80,6 +84,28 @@
target name=cleanup.mirrorfiles
delete dir=${mirror.dir} /
+ /target
+
+ target name=cleanupregexp
+delete dir=${testregexpsrc.dir} /
+delete dir=${testregexpdest.dir} /
+ /target
+
+ target name=containsregexp
+mkdir dir=${testregexpsrc.dir} /
+mkdir dir=${testregexpdest.dir} /
+!-- Make two test files, shouldcopy.txt will get selected if everything
works
+ shouldnotcopy.txt will not get selected for copy. The test looks
to see
+ that only one file is copied
+--
+echo message=Some testregexp text 2.0
file=${testregexpsrc.dir}/shouldcopy.txt /
+echo message=Some testregexp text 20
file=${testregexpsrc.dir}/shouldnotcopy.txt /
+copy todir=${testregexpdest.dir}
+ fileset dir=${testregexpsrc.dir}
+include name=*.txt /
+containsregexp expression=[0-9]\.[0,1,2] /
+ /fileset
+/copy
/target
/project
1.1
ant/src/testcases/org/apache/tools/ant/types/selectors/ContainsRegexpTest.java
Index: ContainsRegexpTest.java
===
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names Ant and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION
Re: antlib
On Tue, 22 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: If we do this, then we can concentrate here on the local antlib while someone else can take care of the external work. +1 Stefan
Re: antlib
On Mon, 21 Apr 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: 1) antlib antjar deployment descriptor called antlib.xml which would go in the META-INF subdirectory of the antlib I prefer an XML descriptor over manifest entries as well, because it is easier to extend in the future. Say centipede wants to add information in that descriptor that antlib doesn't need to care about. looks like that antlib version=1.5 Is that the version of the antlib parser, i.e. does version define the format of the file? The minimal version of Ant the antlib needs? Or is that the version of the antlib itself? I think we'll have to provide all three items, while the first two may in fact be just one. 2) type definitions -- allowing to define new implementations of mappers, selectors, paths, conditions, We definitely need this, roles may be the key here. With that, do we really need separate task and data-type in antlib or are they just special cases of roles? 3) A scoping framework for the symbol tables needed to manage the antlib definitions Management of a hash symbol table containing names, classes, and roles. Roles are currently task or datatype. It is possible to define new roles. Works for me. 4) A framework for managing classloaders where you can specify which classloader to use when loading an antlib. This is the hardest part IMHO. Sorry, I haven't looked at the proposal thoroughly so far. Is there such a classloading framework in place? What does it provide and how do you use it? Stefan
cvs commit: ant/src/main/org/apache/tools/ant/types ZipFileSet.java
antoine 2003/04/23 00:20:17
Modified:src/main/org/apache/tools/ant/types ZipFileSet.java
Log:
fix ZipFileSet#getRef for referenced ZipFileSets
Revision ChangesPath
1.19 +5 -7 ant/src/main/org/apache/tools/ant/types/ZipFileSet.java
Index: ZipFileSet.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/types/ZipFileSet.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ZipFileSet.java 22 Apr 2003 23:33:32 - 1.18
+++ ZipFileSet.java 23 Apr 2003 07:20:17 - 1.19
@@ -293,16 +293,14 @@
stk.push(this);
dieOnCircularReference(stk, p);
}
-
Object o = getRefid().getReferencedObject(p);
-if (o instanceof FileSet) {
- return (AbstractFileSet)(new ZipFileSet((FileSet)o));
-}
-else if (!(o instanceof ZipFileSet)) {
+if (o instanceof ZipFileSet) {
+return (AbstractFileSet) o;
+} else if (o instanceof FileSet) {
+ return (new ZipFileSet((FileSet) o));
+} else {
String msg = getRefid().getRefId() + doesn\'t denote a
zipfileset or a fileset;
throw new BuildException(msg);
-} else {
-return (AbstractFileSet) o;
}
}
/**
[Fwd: Re: antlib]
Jose Alberto Fernandez wrote, On 22/04/2003 19.20: Hi guys, I would propose to that instead of antlib calling ruper, the rupper people can provide a ruperautoload task (or whatever other name you want) that will do all the finding and downloading and then will invoque antlib. If we do this, then we can concentrate here on the local antlib while someone else can take care of the external work. Ok, agreed. In reality, we already have it ;-) In Centipede antlibs are called cents, and to get them it's called importcent. Cents are versioned, can automatically import snippets, can be autodownloaded, installed and shared, contain resources, and can add tasks and types. I'll keep it that way, and maybe it's better for all; architecturaly speaking it also makes better layering and separation of concerns. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
DO NOT REPLY [Bug 9300] - Support raw Classsaths in TypeDef
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=9300. 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=9300 Support raw Classsaths in TypeDef [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
DO NOT REPLY [Bug 9301] - Merge Old Project/Workspace model and Module/TargetMetaData 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=9301. 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=9301 Merge Old Project/Workspace model and Module/TargetMetaData code [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
DO NOT REPLY [Bug 9536] - Write a Diff 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=9536. 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=9536 Write a Diff Task [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 08:23 --- No longer relevent
DO NOT REPLY [Bug 9304] - Service Deployment/Descriptors
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=9304. 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=9304 Service Deployment/Descriptors [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 08:23 --- No longer relevent
DO NOT REPLY [Bug 9303] - Supoprt Nested ServiceKernel
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=9303. 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=9303 Supoprt Nested ServiceKernel [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 08:23 --- No longer relevent
DO NOT REPLY [Bug 9304] - Service Deployment/Descriptors
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=9304. 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=9304 Service Deployment/Descriptors [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
DO NOT REPLY [Bug 9303] - Supoprt Nested ServiceKernel
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=9303. 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=9303 Supoprt Nested ServiceKernel [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED
DO NOT REPLY [Bug 19179] - enhancement to mail / email task to support smtp auth
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=19179. 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=19179 enhancement to mail / email task to support smtp auth [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement
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|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 09:44 --- There is an encoding attribute in 1.6, but the code has been changed significantly between 1.5.1 and 1.5.3 so chances are very good that it is going to work with 1.5.3 already - at least as long as the multi-byte encoding is your native file encoding.
DO NOT REPLY [Bug 19213] - Further Cleanup of the ClasspathUtils.
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=19213. 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=19213 Further Cleanup of the ClasspathUtils. [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
[GUMP] Test Failure - Ant
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-04-23/test-ant.html Buildfile: build.xml check_for_optional_packages: xml-check: dump-sys-properties: run-which: [which] # BEGIN: Which report [which] Which.version=Which.java:($Revision: 1.4 $) WhichJar.java:($Revision: 1.3 $) [which] Which.special-note=No -projects provided, using DEFAULT_PROJECTS [which] java.version=1.4.1_02 [which] file.encoding=ANSI_X3.4-1968 [which] java.ext.dirs=/usr/java/j2sdk1.4.1_02/jre/lib/ext [which] java.class.path=/home/rubys/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar:/home/rubys/jakarta/xml-xerces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xalan/java/build/xalan.jar:/home/rubys/jakarta/xml-commons/java/external/build/xml-apis.jar:.:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/usr/java/j2sdk1.4.1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/lib/tools.jar:/home/rubys/jakarta/ant/build/lib/ant-testutil.jar:/home/rubys/jakarta/xml-commons/java/build/which.jar:/home/rubys/jakarta/rhino/build/rhino_20030423/js.jar:/home/rubys/jakarta/beanshell/dist/bsh-20030423.jar:/home/rubys/jakarta/beanshell/dist/bsh-bsf-20030423.jar:/home/rubys/jakarta/beanshell/dist/bsh-classpath-20030423.jar:/home/rubys/jakarta/beanshell/dist/bsh-commands-20030423.jar:/home/rubys/jakarta/beanshell/dist/bsh-core-20030423.jar:/home/rubys/jakarta/beanshell/dist/bsh-reflect-20030423.jar:/home/rubys/jakarta/beanshell/dist/bsh-util-20030423.jar:/home/rubys/jakarta/jakarta-commons/logging/dist/commons-logging.jar:/home/rubys/jakarta/jakar [which] ta-commons/logging/dist/commons-logging-api.jar:/home/rubys/jakarta/jakarta-log4j/log4j-20030423.jar:/home/rubys/jakarta/jakarta-log4j/log4j-lf5-20030423.jar:/home/rubys/jakarta/jakarta-log4j/log4j-chainsaw-20030423.jar:/home/rubys/jakarta/xml-stylebook/bin/stylebook-1.0-b3_xalan-2.jar:/home/rubys/jakarta/jakarta-oro/jakarta-oro-20030423.jar:/home/rubys/jakarta/xml-commons/java/build/resolver.jar:/home/rubys/jakarta/jakarta-bcel/bin/bcel.jar:/opt/javamail-1.3/mail.jar:/opt/jaf-1.0.1/activation.jar:/opt/jdepend-2.6/lib/jdepend.jar:/home/rubys/jakarta/jakarta-commons/net/dist/commons-net-20030423.jar:/home/rubys/jakarta/jakarta-bsf/src/bsf-2.3/build/lib/bsf.jar:/home/rubys/jakarta/ant/dist/lib/ant.jar:/home/rubys/jakarta/ant/dist/lib/ant-jmf.jar:/home/rubys/jakarta/ant/dist/lib/ant-junit.jar:/home/rubys/jakarta/ant/dist/lib/ant-stylebook.jar:/home/rubys/jakarta/ant/dist/lib/ant-swing.jar:/home/rubys/jakarta/ant/dist/lib/ant-trax.jar:/home/rubys/jakarta/ant/dist/lib/ant-xalan2.jar:/home/rubys/jakarta/ant/dist/lib [which] /nodeps.jar:/home/rubys/jakarta/ant/build/lib/ant.jar:/home/rubys/jakarta/ant/build/lib/ant-antlr.jar:/home/rubys/jakarta/ant/build/lib/ant-apache-bsf.jar:/home/rubys/jakarta/ant/build/lib/ant-apache-resolver.jar:/home/rubys/jakarta/ant/build/lib/ant-bcel.jar:/home/rubys/jakarta/ant/build/lib/ant-commons-logging.jar:/home/rubys/jakarta/ant/build/lib/ant-commons-net.jar:/home/rubys/jakarta/ant/build/lib/ant-jakarta-regexp.jar:/home/rubys/jakarta/ant/build/lib/ant-javamail.jar:/home/rubys/jakarta/ant/build/lib/ant-jdepend.jar:/home/rubys/jakarta/ant/build/lib/ant-jmf.jar:/home/rubys/jakarta/ant/build/lib/ant-jsch.jar:/home/rubys/jakarta/ant/build/lib/ant-junit.jar:/home/rubys/jakarta/ant/build/lib/ant-log4j.jar:/home/rubys/jakarta/ant/build/lib/ant-oro.jar:/home/rubys/jakarta/ant/build/lib/ant-stylebook.jar:/home/rubys/jakarta/ant/build/lib/ant-swing.jar:/home/rubys/jakarta/ant/build/lib/ant-trax.jar:/home/rubys/jakarta/ant/build/lib/ant-xalan2.jar:/home/rubys/jakarta/ant/build/lib/nodeps.jar:/opt/antlr-2.7.2/an [which] tlrall.jar:/opt/antlr-2.7.2/antlr.jar:/home/rubys/jakarta/ant/bootstrap/lib/ant.jar:/home/rubys/jakarta/jakarta-servletapi-4/lib/servlet.jar:/opt/jsch-0.1.3/dist/lib/jsch-gump.jar:/home/rubys/jakarta/dist/junit/junit.jar:/home/rubys/jakarta/jakarta-tomcat-4.0/dist/common/lib/jasper-compiler.jar:/home/rubys/jakarta/jakarta-tomcat-4.0/dist/common/lib/jasper-runtime.jar:/home/rubys/jakarta/jakarta-regexp/bin/jakarta-regexp-20030423.jar:/home/rubys/jakarta/ant/build/testcases:/home/rubys/jakarta/ant/src/testcases:/home/rubys/jakarta/ant/src/etc/testcases [which] Which.status=.ok-present [which] os.name=Linux [which] java.vendor=Sun Microsystems Inc. [which] sun.boot.class.path=/home/rubys/jakarta/xml-commons/java/external/build/xml-apis.jar:/home/rubys/jakarta/xml-xalan/java/build/xalan.jar:/home/rubys/jakarta/xml-xerces2/java/build/xercesImpl.jar:/home/rubys/jakarta/xml-xerces2/java/build/xmlParserAPIs.jar:/usr/java/j2sdk1.4.1_02/jre/lib/rt.jar:/usr/java/j2sdk1.4.1_02/jre/lib/i18n.jar:/usr/java/j2sdk1.4.1_02/jre/lib/sunrsasign.jar:/usr/java/j2sdk1.4.1_02/jre/lib/jsse.jar:/usr/java/j2sdk1.4.1_02/jre/lib/jce.jar:/usr/java/j2sdk1.4.1_02/jre/lib/charsets.jar:/usr/java/j2sdk1.4.1_02
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-23 11:54 --- I think you are misunderstanding a few things. (1) jvmarg gets passed to the java VM (i.e. java.exe) and nowhere else. The VM doesn't know how to read command line arguments from a file. (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.
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-23 12:07 --- Do you mean that: jvmarg file=../../cfg/cmdline.properties/ gets translated into: java -Dfile=/usr/home/xpse/cfg/cmdline.properties/
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-23 12:16 --- No, I mean jvmarg file=../../cfg/cmdline.properties/ gets translated to java WHATEVER-IS-THE-ABSOLUTE-PATH-OF/cfg/cmdline.properties i.e, if your build file is in C:\temp\cmdltest and you don't fiddle with basedir, it gets translated to java C:\cfg\cmdline.properties
DO NOT REPLY [Bug 19151] - A New nested element to the batchtest element of the JUnit task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19151. 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=19151 A New nested element to the batchtest element of the JUnit task --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 12:30 --- I agree with Dominique. You can already do what you want with a custom selector. How do you perform the instanceof check? Do you load the classes, parse the bytecode or parse the source?
DO NOT REPLY [Bug 13510] - CvsChangeLog should accept a branch as an optional parameter
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=13510. 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=13510 CvsChangeLog should accept a branch as an optional parameter --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 13:08 --- I've reproduced the problem on the latest cvs version (1.11.5) and it seems as the only way to get around this is by using the -S flag. This flag was added in version 1.11.2 which was released in april 2002, so you'll need a fairly new cvs server to get this working. Maybe the ant task can check for the cvs server version before attempting to set a branch property, and issue a warning if the server is prior to 1.11.2 ?
DO NOT REPLY [Bug 19247] New: - zipfileset: 'src' does not replace 'dir' attribute
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=19247.
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=19247
zipfileset: 'src' does not replace 'dir' attribute
Summary: zipfileset: 'src' does not replace 'dir' attribute
Product: Ant
Version: 1.5.3
Platform: PC
URL: http://http://
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: Other
Component: Core tasks
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Maybe it is not a bug and I didn't understand the documentation. I've search
the mailinglist archive and the bug database, but I could not find the issue.I
tried 'zipfileset' within a 'war' task to copy some classes from a jar, but it
fails.According to the documentation, the first should be right I guess.
Because it failed, I tried 2. and 3. Apparently it does not replace the 'dir'
for the 'src' attribute.1. with 'src': zipfileset
src=${basedir}/myclient.jar No directory specified for ZipFileSet2. with
'dir' en 'src': zipfileset dir=${basedir} src=myclient.jar
Cannot set both dir and src attributes3. with 'dir': zipfileset
dir=${basedir}/myclient.jar /home/hans/java/myclient.jar is not a directory
DO NOT REPLY [Bug 19213] - Further Cleanup of the ClasspathUtils.
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=19213. 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=19213 Further Cleanup of the ClasspathUtils. [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.6 --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 13:50 --- I've left the public methods in (which also forced me to add some methods to the new inner class of ClasspathUtils) for backwards compatibility reasons. With a slightly modifed version I get this here when running the test [junit] Testcase: testCustomFilter(org.apache.tools.ant.filters.DynamicFilterTest): Caused an ERROR [junit] null [junit] java.lang.NullPointerException [junit] at java.util.Hashtable.get(Hashtable.java:315) [junit] at org.apache.tools.ant.Project$AntRefTable.getReal(Project.java:2194) [junit] at org.apache.tools.ant.Project.addReference(Project.java:1869) [junit] at org.apache.tools.ant.util.ClasspathUtils.getClassLoaderForPath(ClasspathUtils.java:198) [junit] at org.apache.tools.ant.util.ClasspathUtils$Delegate.getClassLoader(ClasspathUtils.java:405) [junit] at org.apache.tools.ant.taskdefs.Definer.createLoader(Definer.java:263) [junit] at org.apache.tools.ant.taskdefs.Definer.execute(Definer.java:166) [junit] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:231) [junit] at org.apache.tools.ant.Task.perform(Task.java:399) [junit] at org.apache.tools.ant.Target.execute(Target.java:309) [junit] at org.apache.tools.ant.Target.performTasks(Target.java:336) [junit] at org.apache.tools.ant.Project.executeTarget(Project.java:1404) [junit]at org.apache.tools.ant.BuildFileTest.executeTarget(BuildFileTest.java:265) [junit] at org.apache.tools.ant.filters.DynamicFilterTest.expectFileContains(DynamicFilterTest.java:137) [junit] at org.apache.tools.ant.filters.DynamicFilterTest.testCustomFilter(DynamicFilterTest.java:84)
DO NOT REPLY [Bug 19151] - A New nested element to the batchtest element of the JUnit task
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19151. 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=19151 A New nested element to the batchtest element of the JUnit task [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 14:53 --- Working with selectors is a good enough solution. I'm closing the request.
cvs commit: ant/src/main/org/apache/tools/ant/util ClasspathUtils.java
bodewig 2003/04/23 08:03:06
Modified:src/etc/testcases/core/loaderref loaderref.xml
src/main/org/apache/tools/ant/taskdefs Definer.java
src/main/org/apache/tools/ant/util ClasspathUtils.java
Log:
Make Definer use the new ClasspathUtils, make ClasspathUtils even more
reuse-friendly.
PR: 19213
Submitted by: Marc Portier mpo at apache dot org
Revision ChangesPath
1.2 +1 -0 ant/src/etc/testcases/core/loaderref/loaderref.xml
Index: loaderref.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/core/loaderref/loaderref.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- loaderref.xml 6 Jan 2003 13:58:31 - 1.1
+++ loaderref.xml 23 Apr 2003 15:03:06 - 1.2
@@ -22,6 +22,7 @@
target name=testbadref depends=compile
taskdef loaderref=loaderref-test
+ name=test1
classname=Test1
classpath=${classes.dir}/
/target
1.29 +23 -93ant/src/main/org/apache/tools/ant/taskdefs/Definer.java
Index: Definer.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Definer.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- Definer.java 7 Mar 2003 11:23:01 - 1.28
+++ Definer.java 23 Apr 2003 15:03:06 - 1.29
@@ -66,6 +66,7 @@
import org.apache.tools.ant.Task;
import org.apache.tools.ant.types.Path;
import org.apache.tools.ant.types.Reference;
+import org.apache.tools.ant.util.ClasspathUtils;
/**
* Base class for Taskdef and Typedef - does all the classpath
@@ -79,21 +80,16 @@
public abstract class Definer extends Task {
private String name;
private String value;
-private Path classpath;
private File file;
private String resource;
-private boolean reverseLoader = false;
-private String loaderId = null;
-private String classpathId = null;
-
-private static final String REUSE_LOADER_REF = ant.reuse.loader;
+private ClasspathUtils.Delegate cpDelegate;
/**
* @deprecated stop using this attribute
* @ant.attribute ignore=true
*/
public void setReverseLoader(boolean reverseLoader) {
-this.reverseLoader = reverseLoader;
+this.cpDelegate.setReverseLoader(reverseLoader);
log(The reverseloader attribute is DEPRECATED. It will be removed,
Project.MSG_WARN);
}
@@ -103,7 +99,7 @@
}
public Path getClasspath() {
-return classpath;
+return cpDelegate.getClasspath();
}
public File getFile() {
@@ -115,15 +111,15 @@
}
public boolean isReverseLoader() {
-return reverseLoader;
+return cpDelegate.isReverseLoader();
}
public String getLoaderId() {
-return loaderId;
+return cpDelegate.getClassLoadId();
}
public String getClasspathId() {
-return classpathId;
+return cpDelegate.getClassLoadId();
}
/**
@@ -132,21 +128,14 @@
* @param classpath an Ant Path object containing the classpath.
*/
public void setClasspath(Path classpath) {
-if (this.classpath == null) {
-this.classpath = classpath;
-} else {
-this.classpath.append(classpath);
-}
+this.cpDelegate.setClasspath(classpath);
}
/**
* Create the classpath to be used when searching for component being
defined
*/
public Path createClasspath() {
-if (this.classpath == null) {
-this.classpath = new Path(getProject());
-}
-return this.classpath.createPath();
+return this.cpDelegate.createClasspath();
}
/**
@@ -154,8 +143,7 @@
* To actually share the same loader, set loaderref as well
*/
public void setClasspathRef(Reference r) {
-classpathId=r.getRefId();
-createClasspath().setRefid(r);
+this.cpDelegate.setClasspathref(r);
}
/**
@@ -170,7 +158,7 @@
* @since Ant 1.5
*/
public void setLoaderRef(Reference r) {
-loaderId = r.getRefId();
+this.cpDelegate.setLoaderRef(r);
}
@@ -272,81 +260,12 @@
* create a classloader for this definition
*/
private ClassLoader createLoader() {
-// magic property
-if (getProject().getProperty(REUSE_LOADER_REF) != null) {
-// Generate the 'reuse' name automatically from the reference.
-// This allows taskdefs that work on both ant1.4 and ant1.5.
-//
DO NOT REPLY [Bug 19213] - Further Cleanup of the ClasspathUtils.
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=19213. 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=19213 Further Cleanup of the ClasspathUtils. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 15:05 --- OK, getUniqueClassLoaderForPath doesn't even try to use the path it gets as argument. So after all, things are looking more and more different from your original patch. And then there is LoaderRefTest which insists on the instanceof check you skipped 8-) This same test also showed that *def's loaderref attribute was suddenly ignored in absence of the magic property. What I've committed now passes the tests and looks a little bit more robust than your original submission - could you please check that I didn't break anything?
Re: antlib
On Wed, 23 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: I am not even sure the code today was examining the value. 8-) It's been a long time, I know. we probably should define more meaningful attributes ant-required-version, antlib-version (version used to buils the library) that would probably mate things more clear. Fine with me. With that, do we really need separate task and data-type in antlib or are they just special cases of roles? They should be. So if they are just roles, why treat them in a different way than other roles? Why a task element? define classname=... name=... role=task/ could do the same and be more consistent. I don't have a strong feeling here, just trying to find my way through the ideas without having to read the code ;-) Maybe something could even be in different roles at the same time? See available, checksum or uptodate for things that are tasks and conditions in one. Let me first say that this feature appeared by the need to be able to say, antlib name=A classpathref=XYZ/ antlib name=B classpathref=XYZ/ And being able to make sure that B and A use the same classLoader and therefore they can use each other components. I understand that usecase and think it's important. See Steve Loughran's comment on the .NET tasks wanting to have access to the datatypes defined in the cpptasks project for example. My solution at the time was this idea of a named classloader that you could define using a classpath, and then tell your antlibs use this or that classloader, if you use the same classloader visibility is guaranteed. Take a look at what Costin had done to taskdef and typedef with the loaderref attribute. This has now (i.e. CVS HEAD) been generalized in ClasspathUtils, the infrastructure for named classloaders is there - at least the foundation for it. Stefan
cvs commit: ant build.xml
umagesh 2003/04/23 08:11:43
Modified:.build.xml
Log:
Enable previously disabled head-tail tests.
Make StripJavaComments recognize and retain Mac line endings.
PR: 18476
Submitted by: [EMAIL PROTECTED] (peter reilly)
Revision ChangesPath
1.369 +0 -1 ant/build.xml
Index: build.xml
===
RCS file: /home/cvs/ant/build.xml,v
retrieving revision 1.368
retrieving revision 1.369
diff -u -r1.368 -r1.369
--- build.xml 23 Apr 2003 06:34:52 - 1.368
+++ build.xml 23 Apr 2003 15:11:42 - 1.369
@@ -277,7 +277,6 @@
patternset id=teststhatfail
exclude name=${optional.package}/BeanShellScriptTest.java/
exclude name=${ant.package}/taskdefs/ImportTest.java/
-!--exclude name=${ant.package}/filters/HeadTailTest.java/ --
/patternset
!--
cvs commit: ant/src/testcases/org/apache/tools/ant/filters HeadTailTest.java
umagesh 2003/04/23 08:12:13
Modified:src/etc/testcases/filters head-tail.xml
src/main/org/apache/tools/ant/filters StripJavaComments.java
src/testcases/org/apache/tools/ant/filters HeadTailTest.java
Log:
Enable previously disabled head-tail tests.
Make StripJavaComments recognize and retain Mac line endings.
PR: 18476
Submitted by: [EMAIL PROTECTED] (peter reilly)
Revision ChangesPath
1.2 +24 -0 ant/src/etc/testcases/filters/head-tail.xml
Index: head-tail.xml
===
RCS file: /home/cvs/ant/src/etc/testcases/filters/head-tail.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- head-tail.xml 14 Apr 2003 15:37:45 - 1.1
+++ head-tail.xml 23 Apr 2003 15:12:13 - 1.2
@@ -43,6 +43,18 @@
/copy
/target
+ target name=testFilterReaderHeadLinesSkip depends=init
+copy file=input/head-tail.test
+ tofile=result/head-tail.filterReaderHeadLinesSkip.test
+ filterchain
+filterreader classname=org.apache.tools.ant.filters.HeadFilter
+ param name=lines value=2/
+ param name=skip value=2/
+/filterreader
+ /filterchain
+/copy
+ /target
+
target name=testHeadAllSkip depends=init
copy file=input/head-tail.test
tofile=result/head-tail.headAllSkip.test
filterchain
@@ -81,6 +93,18 @@
copy file=input/head-tail.test
tofile=result/head-tail.tailLinesSkip.test
filterchain
tailfilter lines=2 skip=2/
+ /filterchain
+/copy
+ /target
+
+ target name=testFilterReaderTailLinesSkip depends=init
+copy file=input/head-tail.test
+ tofile=result/head-tail.filterReaderTailLinesSkip.test
+ filterchain
+filterreader classname=org.apache.tools.ant.filters.TailFilter
+ param name=lines value=2/
+ param name=skip value=2/
+/filterreader
/filterchain
/copy
/target
1.11 +1 -7
ant/src/main/org/apache/tools/ant/filters/StripJavaComments.java
Index: StripJavaComments.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/filters/StripJavaComments.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- StripJavaComments.java22 Apr 2003 18:23:54 - 1.10
+++ StripJavaComments.java23 Apr 2003 15:12:13 - 1.11
@@ -132,14 +132,8 @@
if (ch == '/') {
ch = in.read();
if (ch == '/') {
-int prevCh = -1;
-while (ch != '\n' ch != -1) {
-prevCh = ch;
+while (ch != '\n' ch != -1 ch != '\r') {
ch = in.read();
-}
-if ( ch == '\n' prevCh == '\r' ) {
-readAheadCh = ch;
-ch = prevCh;
}
} else if (ch == '*') {
while (ch != -1) {
1.3 +4 -8
ant/src/testcases/org/apache/tools/ant/filters/HeadTailTest.java
Index: HeadTailTest.java
===
RCS file:
/home/cvs/ant/src/testcases/org/apache/tools/ant/filters/HeadTailTest.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- HeadTailTest.java 22 Apr 2003 18:23:55 - 1.2
+++ HeadTailTest.java 23 Apr 2003 15:12:13 - 1.3
@@ -112,19 +112,17 @@
assertTrue(testHeadLinesSkip: Result not like expected,
fu.contentEquals(expected, result));
}
-/*
public void testFilterReaderHeadLinesSkip() throws IOException {
executeTarget(testFilterReaderHeadLinesSkip);
File expected = getProject().resolveFile(
-expected/head-tail.filterReaderHeadLinesSkip.test);
+expected/head-tail.headLinesSkip.test);
File result = getProject().resolveFile(
-result/head-tail.headLinesSkip.test);
+result/head-tail.filterReaderHeadLinesSkip.test);
FileUtils fu = FileUtils.newFileUtils();
assertTrue(testFilterReaderHeadLinesSkip: Result not like expected,
fu.contentEquals(expected, result));
}
-*/
public void testTail() throws IOException {
executeTarget(testTail);
File expected =
getProject().resolveFile(expected/head-tail.tail.test);
@@ -157,18 +155,16 @@
assertTrue(testTailLinesSkip: Result not like expected,
fu.contentEquals(expected,
Re: Cleanup for ClasspathUtils
On Fri, 18 Apr 2003, Marc Portier [EMAIL PROTECTED] wrote:
1. ClasspathUtils duplicates (i.e. stole) some code from the
o.a.t.a.taskdefs.Definer: the least I should do is refactor that one
to now use what is in the ClasspathUtils.
This is now in CVS.
I noted at least one difference, and I'm not sure whether it is going
to have any effect right now, but we may need to address this: If no
classpath had been defined, Definer would first check the project's
core loader and use that if set. ClasspathUtils ignores this.
While this is not that much of code I still would like to add to
this some Helper that does all of this for you,
It's also in.
BTW
public void setClasspathRef(Reference r) {
this.cpHelper.setClasspathRef(r);
}
I wouldn't implement this and setClasspath(Path) at all if I were to
write a new task today. I'd simply stick with the nested element.
(what about these ./proposal things?)
Ignore them for now.
I take it the prefered patch format is cvs -q diff -u -N ?
Yep. The -q is your choice, off course.
tests are currently not working in cvs head
I think some of the failures you've seen are due to the copy
changes the line-end style bug that is supposed to be fixed now. If
things keep failing, nag this list. ant test is supposed to pass.
Stefan
RE: antlib
One comment about roles: Roles are fine, but roles are just strings... If everything is defined as a component at a low level, then they can be easily introspected to find out what interfaces components implement. For example, why would I have to say: define classname=a.b.C name=... role=selector/ when class a.b.C does implement FileSelector! The role is implicit thanks to the type of the class itself. I suspect there will be more cases where a role maps directly to a single given interface than to an arbitrary bean, which is the only case where a role string needs to be specified!?!? So an AntLib system that forces to spell out (string) roles in an XML descriptor (which I also prefer over the Manifest) when the defined class itself already embeds this info in it own type will be cumbersome at best. --DD -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 23, 2003 10:12 AM To: [EMAIL PROTECTED] Subject: Re: antlib With that, do we really need separate task and data-type in antlib or are they just special cases of roles? They should be. So if they are just roles, why treat them in a different way than other roles? Why a task element? define classname=... name=... role=task/ could do the same and be more consistent. I don't have a strong feeling here, just trying to find my way through the ideas without having to read the code ;-) Maybe something could even be in different roles at the same time? See available, checksum or uptodate for things that are tasks and conditions in one.
DO NOT REPLY [Bug 18476] - copy with filtering modifies lineendings
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=18476. 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=18476 copy with filtering modifies lineendings --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 15:31 --- Patch applied. Thanks.
DO NOT REPLY [Bug 19213] - Further Cleanup of the ClasspathUtils.
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=19213. 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=19213 Further Cleanup of the ClasspathUtils. --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 15:35 --- Sorry for all the bugs, will investigate some time in why tests are misbehaving on my pltaform before adding more of these patches for you to debug :-S Have checked your changes in code, will slide them under my new task and typedefs this evening. Since I changed some of the semantics myself between both patches I will need to do some changing in my project in any case. Thx a lot for debugging and applying.
Re: antlib
On Wed, 23 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: If everything is defined as a component at a low level, then they can be easily introspected to find out what interfaces components implement. This breaks down if there is no specific interface for a role - like task or data-type. And also doesn't address things that can be in multiple roles. At least for task I'd expect some strong opposition against an interface that marks them up. Hi Costin ;-) Stefan
RE: antlib
I probably didn't express myself correctly ;-) I didn't say the string role was not necessary, I'm saying it's redundant when the role itself corresponds to an interface. I can implement a single class implementing a bunch of interfaces, each corresponding to a given role, can't I? Plus tasks/types will soon be only different in the sense that tasks have an execute method, right? Forcing roles to map to an interface is probably a *good* idea! Every single bean would become implicitly a data-type, and the ones with an execute() method implicitly become tasks. Beyond that, all other roles are interfaces. What's wrong with that? --DD -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 23, 2003 10:35 AM To: [EMAIL PROTECTED] Subject: Re: antlib On Wed, 23 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: If everything is defined as a component at a low level, then they can be easily introspected to find out what interfaces components implement. This breaks down if there is no specific interface for a role - like task or data-type. And also doesn't address things that can be in multiple roles. At least for task I'd expect some strong opposition against an interface that marks them up. Hi Costin ;-) Stefan
RE: antlib
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Wed, 23 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: With that, do we really need separate task and data-type in antlib or are they just special cases of roles? They should be. So if they are just roles, why treat them in a different way than other roles? Why a task element? define classname=... name=... role=task/ could do the same and be more consistent. I don't have a strong feeling here, just trying to find my way through the ideas without having to read the code ;-) I think you can already. The task and datatype(sp?) is just neat syntax sugar. As mentioned in a previous message from Antoine: Once you define a new role 'myrole' you can say: myrole classname=... name=.../ so tasks and datatypes are just predefined roles. Maybe something could even be in different roles at the same time? No problem, declare the class in as many roles as you like. See available, checksum or uptodate for things that are tasks and conditions in one. Yeap. Let me first say that this feature appeared by the need to be able to say, antlib name=A classpathref=XYZ/ antlib name=B classpathref=XYZ/ And being able to make sure that B and A use the same classLoader and therefore they can use each other components. I understand that usecase and think it's important. See Steve Loughran's comment on the .NET tasks wanting to have access to the datatypes defined in the cpptasks project for example. My solution at the time was this idea of a named classloader that you could define using a classpath, and then tell your antlibs use this or that classloader, if you use the same classloader visibility is guaranteed. Take a look at what Costin had done to taskdef and typedef with the loaderref attribute. This has now (i.e. CVS HEAD) been generalized in ClasspathUtils, the infrastructure for named classloaders is there - at least the foundation for it. If this is already suported by the core, then scrap what I have and replace it with the way the core supports it. I have no objection. After that we can comeback begging for any additional features we needed and everybody will get them. Jose Alberto
cvs commit: ant WHATSNEW
bodewig 2003/04/23 09:01:00 Modified:.WHATSNEW Log: Keep track of changes Revision ChangesPath 1.403 +2 -0 ant/WHATSNEW Index: WHATSNEW === RCS file: /home/cvs/ant/WHATSNEW,v retrieving revision 1.402 retrieving revision 1.403 diff -u -r1.402 -r1.403 --- WHATSNEW 22 Apr 2003 18:23:52 - 1.402 +++ WHATSNEW 23 Apr 2003 16:00:59 - 1.403 @@ -268,6 +268,8 @@ * zipfileset can now be defined in the main body of a project and referred to with refid=xyz. Bugzilla Report 17007. +* A wrapper script for OS/2 has been added. + Changes from Ant 1.5.2 to Ant 1.5.3 ===
Re: antlib
On Wed, 23 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: Forcing roles to map to an interface is probably a *good* idea! Maybe, hmm, probably, not convinced ... Every single bean would become implicitly a data-type, and the ones with an execute() method implicitly become tasks. Beyond that, all other roles are interfaces. How would you have a task that also is a condition? It implements Condition and has an execute method? How would you have a datatype that also is a condition? This may be far-fetched, not sure. Stefan
Re: antlib
On Wednesday 23 April 2003 17:41, Dominique Devienne wrote: Let's turn around your question: Tell me of a (string) role (beside the special task/type cases) that would not be an interface? What good a bean is, if it's not of an expected Java type? What method or field are you going to use/call on it? I agree with Costin, all tasks/types become simply beans. You should be able to use any one of these beans in any place it's suitable to use it, i.e. any time the Java type/role requested is part of the bean's type (in the isAssigneableFrom() sense). The type being requested depends on who requests it. Inside or outside targets, it's any bean. And I mean really any bean: Doesn't need to implement anything Ant-related. This is implicitly what we call today a datatype, and they can be id'd. The subset of these beans that also have an execute method are also implicitly tasks. The different subsets of these beans that implements FileSelector are suitable to use within filesets, and tasks deriving from MatchingTask since we're talking about it. I fail to see what is wrong with this scenario. --DD The only problem is the namespace problem. But this is not a huge restriction. Peter.
DO NOT REPLY [Bug 19252] New: - 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 Summary: untar does not untar symbolic links properly Product: Ant Version: 1.5.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The untar task does not properly restore the symbolic link from the tar. On Unix (I tried on Linux and SGI), I created a tar with a symbolic link in it. I can untar this file fine with tar xvf file.tar command but using untar command, the links are created as regular files with 0 (zero) size.
Re: antlib
Stefan Bodewig wrote: On Wed, 23 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: If everything is defined as a component at a low level, then they can be easily introspected to find out what interfaces components implement. This breaks down if there is no specific interface for a role - like task or data-type. And also doesn't address things that can be in multiple roles. Interfaces _and_ patterns. ( and in interface I also include extending some base class like task ). If it has an execute() method - that method will be called, even if you don't extend Task. It would be nice to have init()/destroy() patterns on the datatypes as well. What matters at low level are components. What matters at high level ( i.e. from a target perspective, or a task that includes other tasks, or a datatype that uses some roles or conditions ) are the operations that a component supports. Operations can be expressed by interfaces, or by patterns. It may sound a bit to JMX-ish, but this is something that works amazingly well. Everything in tomcat is becoming a simple JMX component. JBoss ( which is even more complex ) operates in terms of mbeans - with init/start/stop/destroy pattern. If some mbean happens to be a servlet container and another mbean happens to be an EJB container or just a simple logger or set some properties - it doesn't matter. And what's nice is that we don't need to change much in ant to achieve that. We can say it's almost already available. At least for task I'd expect some strong opposition against an interface that marks them up. Hi Costin ;-) Of course. There is no need to have a Task interface, or even require Task to be extended. Ant's strength (IMHO) comes from the lightness of the framework. Just add an execute method to your java bean and you can use it in ant. Very low entry point, no pressure, no strong dependency. JMX is the best analogy, and it's used with success in things far more complex than ant. You only have to support certain operations. That's not to say I'm against using interfaces to define roles - my only problem is to keep the interfaces informative, not required. There is no need to be stricter than JMX - which also uses interfaces, but supports declarative model ( model mbeans - you just use descriptors, and any java object ) or direct calls ( dynamic mbeans ). Costin
RE: antlib
Yes, it could be a problem. But running the risk of speaking yet another anathema, I'm starting to believe the Jelly approach of using XML namespaces is the right one... The problem is not so much that one wants to use the same name (say containsregex) for two different things (a condition and a filter for example), but more than different AntLibs from different people might clash. Using a prefix would work, but XML has built-in namespace support, and the syntax is not that bad actually, and Ant would remain the default namespace. Plus a single bean could implement both Condition and FileFilter if it wanted, so there's no name clash anymore... I'm not sure it's wise the raising the XML namespace issue again at this time, if AntLib is to go anywhere though... --DD -Original Message- From: peter reilly [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 23, 2003 11:53 AM To: Ant Developers List Subject: Re: antlib The only problem is the namespace problem. But this is not a huge restriction. Peter.
DO NOT REPLY [Bug 18484] - Please add parameters into script 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=18484. 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=18484 Please add parameters into script task. --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 17:05 --- you can always do: project.getProperty(whatever.whatever) or project.references.get(whatever.reference) for properties that are nor legal identifiers.
Re: antlib
On Wednesday 23 April 2003 17:57, Dominique Devienne wrote: Yes, it could be a problem. But running the risk of speaking yet another anathema, I'm starting to believe the Jelly approach of using XML namespaces is the right one... +1 Seems simple to implement and fits in with current usage. Proposal: * place tasks.properties and typedefs.properties the jar file as per bugzilla 17844 * have an antlib task that defines a name space for the tasks/typedefs in the jar. - default is the global namespace. * use a variation of dynamictag or dynamicelement to allow the datatypes to be used in supporting tasks / datatypes The problem is not so much that one wants to use the same name (say containsregex) for two different things (a condition and a filter for example), but more than different AntLibs from different people might clash. Using a prefix would work, but XML has built-in namespace support, and the syntax is not that bad actually, and Ant would remain the default namespace. Plus a single bean could implement both Condition and FileFilter if it wanted, so there's no name clash anymore... It would be nice to have two different classes for this case . I'm not sure it's wise the raising the XML namespace issue again at this time, if AntLib is to go anywhere though... --DD True. Peter.
RE: antlib
From: peter reilly [mailto:[EMAIL PROTECTED] A couple of points: 1) the Project.java in the proposal should be synced up with the current Project.java. It is quite difficult to see the differences. Antoine keeps on sync-ing but the thing keeps on moving :-( 2) do the taskdef, typedef tasks still work as at present ? (ie for individual tasks and with property resouces) Yes, taskdef and typedef remain the same as required for backward compatibility. Jose
Re: antlib
Peter Reilly wrote A couple of points: 1) the Project.java in the proposal should be synced up with the current Project.java. It is quite difficult to see the differences. Yes 2) do the taskdef, typedef tasks still work as at present ? (ie for individual tasks and with property resouces) No, I need to implement taskdef, typedef and subant in the proposal. Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib
Dominique, you should love the current antlib proposal more of what you are arguing is acomplish there, maybe with a little twist. :-) From: Dominique Devienne [mailto:[EMAIL PROTECTED] Let's turn around your question: Tell me of a (string) role (beside the special task/type cases) that would not be an interface? What good a bean is, if it's not of an expected Java type? What method or field are you going to use/call on it? This is exactly the point, we should try to type things. Roles are this typed interfaces expected by the set/add method. The component being declared of a particular role, may or may not implement the interface. If it does cool; if not an adaptor will be used to bridge the gap. It is upto the adaptor to decide if the bean is compatible or not. The guy writing the container (the thing with the set/add methods) does not have to deal with introspection or anything of that. As s/he shouldn't. But by allowing adaptors someone can take some cool object and bridge it. I agree with Costin, all tasks/types become simply beans. You should be able to use any one of these beans in any place it's suitable to use it, i.e. any time the Java type/role requested is part of the bean's type (in the isAssigneableFrom() sense). So, since now this objects come from somewhere else, if it is not typed somehow, any object expecting an instance of the role need to do introspection by hand. Not good. Jose
RE: antlib
Dominique Devienne wrote: Let's turn around your question: Tell me of a (string) role (beside the special task/type cases) that would not be an interface? What good a bean is, if it's not of an expected Java type? What method or field are you going to use/call on it? Any role. Just like you can put any java class with an execute() method in a task role, or any java bean in a datatype role. Interfaces are fine - they define a set of methods and contract that a class must support. But it is perfectly possible to support the contract without implementing the interface. In JDK1.3+ ( and JMX1.2+) you can use a proxy that implement the interface - but what really matters is the contract, not the syntactic detail. Ant ( and JMX ) have allways had a loose coupling aproach. You can write a lot of tasks without having any dependency on ant. I agree with Costin, all tasks/types become simply beans. You should be able to use any one of these beans in any place it's suitable to use it, i.e. any time the Java type/role requested is part of the bean's type (in the isAssigneableFrom() sense). I agree with you that roles should be associated with an interface. I don't agree that the components need to actually implement the interface, they only need to support the contract. I would like to allow any mbean that has an execute method to be used as an ant task. Or any mbean that supports a particular contract to be used in the associated role - without having to change the mbean and make it depend on ant. The type being requested depends on who requests it. Inside or outside targets, it's any bean. And I mean really any bean: Doesn't need to Exactly. implement anything Ant-related. This is implicitly what we call today a datatype, and they can be id'd. The subset of these beans that also have an execute method are also implicitly tasks. The different subsets of these beans that implements FileSelector are suitable to use within filesets, and tasks deriving from MatchingTask since we're talking about it. I fail to see what is wrong with this scenario. --DD I think it is a good scenario, and the JMX uses prove it is viable. You may like or dislike Jboss - but their modularity and flexibility ( given by JMX and the low-coupling ) is a proven thing. Costin -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 23, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: Re: antlib On Wed, 23 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: Forcing roles to map to an interface is probably a *good* idea! Maybe, hmm, probably, not convinced ... Every single bean would become implicitly a data-type, and the ones with an execute() method implicitly become tasks. Beyond that, all other roles are interfaces. How would you have a task that also is a condition? It implements Condition and has an execute method? [DD] Yes! What's wrong with that? How would you have a datatype that also is a condition? This may be far-fetched, not sure. Stefan
Re: antlib
peter reilly wrote: On Wednesday 23 April 2003 17:57, Dominique Devienne wrote: Yes, it could be a problem. But running the risk of speaking yet another anathema, I'm starting to believe the Jelly approach of using XML namespaces is the right one... +1 Seems simple to implement and fits in with current usage. Proposal: * place tasks.properties and typedefs.properties the jar file as per bugzilla 17844 +1 Eventually it can be an antlib.properties containing all kinds of components. * have an antlib task that defines a name space for the tasks/typedefs in the jar. - default is the global namespace. We already have one, called taskdef. It needs few changes to support both tasks and types ( if we decide to support both ). Or a new task that extends Definer and loads the descriptor automatically. We can start simple with that, then add more as we need it ( from antlib or elsewhere ) * use a variation of dynamictag or dynamicelement to allow the datatypes to be used in supporting tasks / datatypes Costin
RE: antlib
Jose Alberto Fernandez wrote: This is exactly the point, we should try to type things. Roles Why ? We have components that can be used in any role. Metadata can be extracted and used in a variety of ways - descriptors, interfaces, runtime calls ( like in the 3 kinds of mbeans ). But in the end the user of a component decides in what roles he wants to use it and how. are this typed interfaces expected by the set/add method. The component being declared of a particular role, may or may not implement the interface. If it does cool; if not an adaptor will be used to bridge the gap. It is upto the adaptor to decide if the bean is compatible or not. +1 on this part The guy writing the container (the thing with the set/add methods) does not have to deal with introspection or anything of that. As s/he shouldn't. But by allowing adaptors someone can take some cool object and bridge it. I think the container is ant. Not sure who should write the adapters - IMO ant can support this automatically ( by introspection since we can't use 1.3 features). So, since now this objects come from somewhere else, if it is not typed somehow, any object expecting an instance of the role need to do introspection by hand. Not good. No. It is easy to provide this service in ant - just like it is done in JMX. Code using JMX never does introspection - just calls the invoke method. If JDK1.3 is used, he can get a proxy that implements the desired interface. ( I think it can be done for JDK1.2 as well, but a bit harder ). Costin
DO NOT REPLY [Bug 19259] New: - 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 Summary: Ant projects should support init and final project/ attributes Product: Ant Version: 1.5.3 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Just like the default attribute of a project/ element, which can be specified to indicate which target to execute by default, ant should also provide an init attribute to indicate a target to execute before any other targets _IF_ it exists and a final target to execute after all other targets _IF_ it exists. Ex: project init=start default=all final=end target name=init taskdef name=foo classname=my.custom.class/ /target target name=all echo message=Hello World/ /target /project
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-23 20:03 --- I screwed that up and the correct build.xml is below project init=init default=all final=end target name=init taskdef name=foo classname=my.custom.class/ /target target name=all echo message=Hello World/ /target /project
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 20:08 --- *** This bug has been marked as a duplicate of 17973 ***
DO NOT REPLY [Bug 17973] - A final target just like a init target
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=17973. 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=17973 A final target just like a init target [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-04-23 20:08 --- *** Bug 19259 has been marked as a duplicate of this bug. ***
