DO NOT REPLY [Bug 19301] New: - junitreport fails
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=19301. 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=19301 junitreport fails Summary: junitreport fails Product: Ant Version: 1.5.3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] With Xalan Java 2.2.D11: [junitreport] jar:file:/C:/Programs/Ant/lib/optional.jar!/org/apache/tools/ant/t askdefs/optional/junit/xsl/junit-frames.xsl; Line 134; Column 74; java.lang.refl ect.InvocationTargetException With Xalan Java 2.5.D1: BUILD FAILED file:C:/Documents%20and%20Settings/Eric/My%20Documents/Projects/Expasy/build.xml :299: Errors while applying transformations: java.lang.StackOverflowError
DO NOT REPLY [Bug 19301] - junitreport fails
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=19301. 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=19301 junitreport fails --- Additional Comments From [EMAIL PROTECTED] 2003-04-25 00:52 --- Created an attachment (id=6002) The test result file that causes junitreport to fail.
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-04-25 06:36 --- If you want to echo the classpath used in javac as a quick check, ant -verbose should work. For more advanced cases, go the define outside of task and echo route.
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-25 06:41 --- Could you give us a complete output (of the javac task, you can snip the rest) from ant -debug please?
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-25 06:43 --- If you want to remove the files that are no longer present, simply set update to false.
DO NOT REPLY [Bug 19249] - javadoc @doclet.ins equivalent
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=19249. 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=19249 javadoc @doclet.ins equivalent [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-04-25 06:50 --- If you really already have all your packages listed in doclet.ins you are not going to gain anything by using javadoc instead of exec - well, javadoc doesn't need the javadoc executable in the PATH, but that's pretty much all. You must give javadoc at leas one source file or package name to chew upon as it really has been invented for a more dynamic system than yours. This also is a workaround for you, simply give it a single source file you will want to have docced anyway. You can pass your @doclet.ins via the additionalparam attribute.
Re: antlib
On Thu, 24 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote: Look - adding roles concept to ant, and adding antlib are 2 separate issues. I tend to agree - that's why I proposed to get antlib into the main trunk with support for types and tasks only. At least for starters. If you want a custom mapper you can do so right now with a data type and refid. The same is not true for filter readers, conditions or selectors. But I feel that enabling that would inevitably lead us to the more general polymorphism discussion and this is what I wanted to avoid 8-). Stefan
Re: antlib
On Thu, 24 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: So how do *you* propose we plug in custom implementations of all the things mentioned above, if not with roles? That other thing we discuss and discuss over and over again without getting anywhere 8-) Polymorphism. Stefan
Re: antlib
On Friday 25 April 2003 08:31, Stefan Bodewig wrote:
On Thu, 24 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote:
Look - adding roles concept to ant, and adding antlib are 2
separate issues.
+1
I tend to agree - that's why I proposed to get antlib into the main
trunk with support for types and tasks only. At least for starters.
If you want a custom mapper you can do so right now with a data type
and refid. The same is not true for filter readers, conditions or
selectors. But I feel that enabling that would inevitably lead us to
Not quite true for filter readers.
In CVS HEAD, FilterChain has a currently (deliberate) undocumented feature of
implementing DynamicConfigurator. The implementation looks up the
name in the types and if present and if the bean implements ChainableReader
it is used as a ChainableReader.
This is used to support ScriptFilter. Script reader is an optional
ChainableReader which depends on the presence of BSF and thus cannot
be implemented in the same way as the other built-in ChainableReaders.
the more general polymorphism discussion and this is what I wanted to
avoid 8-).
I have implemented a generalization of FilterChain's
usage of DynamicConfigurator in IntrospectionHelper.
This extends the introspection support to include methods of the form:
public void dynamicElement(type name);
So in my local ant build the relavant part of FilterChain.java is
public void dynamicElement(ChainableReader reader) {
filterReaders.addElement(reader);
}
and of ConditionBase.java
public void dynamicElement(Condition condition) {
conditions.addElement(condition);
}
As regards using roles:
(note: Roles in the antlib proposal are not completely implemented,ie.
there is no condition, mapper or filter implementation so
my comments may be correct).
Roles in the proposal provide three features:
1) they provide a way of limiting the scope of the tag. I assume that
this is meant to be used by introspection in the same way as
the dynamicElement method above.
2) As a consequence of 1), the same identifier by be used to
point to different classes.
3) they provide an optional adaptor to allow classes that do not support
a requred interface.
These features may be implemented in different ways, for example:
typedef could be extended to have an implements attribute:
typedef name=and classname=o.a.t.ant.taskdefs.conditions.And
implements=o.a.t.ant.taskdefs.conditions.Condition/
and may then only be used in beans that have the method:
public void dynamicElement(Condition condition)
if the class did not implement the condition, a proxy class could be defined:
typedef name=diskfull classname=acme.disk.DiskFull
implements=o.a.t.ant.taskdefs.conditions.Condition
proxy=acme.ant.ConditionAdaptor/
or one could have a class that defines adaptors:
a new task may define adaptors:
adaptor classname=o.a.t.ant.taskdefs.conditions.Condition
proxy=acme.ant.ConditionAdaptor/
My feeling is that roles are not needed to support dynamic conditions,
filters ...,
in fact I do not think that typedef is needed:
loadclasses classpathref=${acme.ant.jars}/
condition property=disk.danger.level
acme.disk.DiskFull percent=70 filesystem=/tmp/
/condition
I see typedef/taskdef as providing alaises for java beans.
Peter.
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-25 09:38 --- Created an attachment (id=6007) ant -debug output for javac
Re: antlib
On Fri, 25 Apr 2003, peter reilly [EMAIL PROTECTED] wrote: I have implemented a generalization of FilterChain's usage of DynamicConfigurator in IntrospectionHelper. This extends the introspection support to include methods of the form: Yes, that's one way to implement it. The tricky part starts if you want to support polymorphism for more than one nested element. Say class PathThatIgnoresBuildSysclassPathToTrickGump extends Path and you want to use it in javac which has several nested elements that are Paths. My, will I ever by able to keep focused on one thread at a time 8-) 2) As a consequence of 1), the same identifier by be used to point to different classes. I see manifest as data type - the one you'd use for refid usage - is implemented by a different class than the manifest task. Luckily we never declared a data-type named manifest. 3) they provide an optional adaptor to allow classes that do not support a requred interface. This may be out of scope for antlib and in scope for the polymorphism debate. My feeling is that roles are not needed to support dynamic conditions, filters ..., in fact I do not think that typedef is needed: I agree. At least no formal definition of a role. Stefan
Re: polymorphism (was Re: antlib)
On Friday 25 April 2003 10:42, Stefan Bodewig wrote:
Yes, that's one way to implement it. The tricky part starts if you
want to support polymorphism for more than one nested element.
true.
The problem exists in CVS HEAD for TokenFilter, it can take
TokenFilter.Filter and TokenFilter.Tokenizer objects. Suppose
an object implements both interfaces?. The current code
just treats it as a TokenFilter.Filter.
Say class PathThatIgnoresBuildSysclassPathToTrickGump extends Path
and you want to use it in javac which has several nested elements
that are Paths.
I do not see the problem here: suppose Path implements
dynamicElement(Path path)
one could do:
javac
classpath
PathThatIgnoresBuildSysclassPathToTrickGump
pathelement path=${classpath}/
/PathThatIgnoresBuildSysclassPathToTrickGump
/classpath
/javac
Peter
Re: polymorphism (was Re: antlib)
On Fri, 25 Apr 2003, peter reilly [EMAIL PROTECTED] wrote:
I do not see the problem here: suppose Path implements
dynamicElement(Path path)
one could do:
javac
classpath
PathThatIgnoresBuildSysclassPathToTrickGump
pathelement path=${classpath}/
/PathThatIgnoresBuildSysclassPathToTrickGump
/classpath
/javac
I don't want to use it as nested element of classpath, but as nested
element of javac.
Take classfileset/zipfileset and dependset as another example
(where you can trick me ;-).
I want to be able to be able to use classfileset as srcfileset and
zipfileset as targetfileset - or the other way around.
Stefan
RE: antlib
From: Costin Manolache [mailto:[EMAIL PROTECTED] Erik Hatcher wrote: But the current one does not support adding other components like conditions, mappers, filters, and selectors. Does ant support this ? And what do you mean does not support adding ? It can add any component ( as datatype for example), and nothing stops you from using any datatype as anything you want ( condition, mapper, filter or selector ). The big difference is the way ANT currently treats a core condition/mapper/filter from one defined by a user. If I look at a build file the syntax are completely different, not only that but in some cases the name of attributes changes for the same class depending on whether I use the core syntax or the syntax for user defined implementations. And it is not only the things above, it is also the vendor specific elements of things like ejbjar jspc and others. I would like those classes reemplemented using roles and scatter the vendor specific code to the wind (to te vendors) where it belongs (on their own release cycle). To me the whole point of antlib is that it will make core code and 3rd party maintained components completely indistinguishable from the point of view of the build writer, no priviledges to anyone. Jose Alberto
RE: antlib
Peter,
this is exactly my point. For every new thingy that we add we now need to go and
modify IntrospectionHelper or something to make special allowances for it.
It is bloating the core like mad and in my opinion it is crazy. We need a
unified
way to treat this things no matter what the things are. Ant's engine core should
not need to know anything about anything.
In an ideal world, we should have an engine core with no reference to any
task/type
or its implementing classes and a core-antlib which provides the classes and
definintions
for all the task/types/conditions/selectors/mappers that define core java.
We could even have separate release cycles for it.
THAT is the potential for antlib (and it is not polimorphish).
Jose Alberto
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: 25 April 2003 10:30
To: Ant Developers List
Subject: Re: antlib
On Friday 25 April 2003 08:31, Stefan Bodewig wrote:
On Thu, 24 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote:
Look - adding roles concept to ant, and adding antlib are 2
separate issues.
+1
I tend to agree - that's why I proposed to get antlib into the main
trunk with support for types and tasks only. At least for starters.
If you want a custom mapper you can do so right now with a data type
and refid. The same is not true for filter readers, conditions or
selectors. But I feel that enabling that would inevitably
lead us to
Not quite true for filter readers.
In CVS HEAD, FilterChain has a currently (deliberate)
undocumented feature of
implementing DynamicConfigurator. The implementation looks up the
name in the types and if present and if the bean implements
ChainableReader
it is used as a ChainableReader.
This is used to support ScriptFilter. Script reader is an optional
ChainableReader which depends on the presence of BSF and thus cannot
be implemented in the same way as the other built-in ChainableReaders.
the more general polymorphism discussion and this is what I
wanted to
avoid 8-).
I have implemented a generalization of FilterChain's
usage of DynamicConfigurator in IntrospectionHelper.
This extends the introspection support to include methods of the form:
public void dynamicElement(type name);
So in my local ant build the relavant part of FilterChain.java is
public void dynamicElement(ChainableReader reader) {
filterReaders.addElement(reader);
}
and of ConditionBase.java
public void dynamicElement(Condition condition) {
conditions.addElement(condition);
}
As regards using roles:
(note: Roles in the antlib proposal are not completely implemented,ie.
there is no condition, mapper or filter implementation so
my comments may be correct).
Roles in the proposal provide three features:
1) they provide a way of limiting the scope of the tag. I assume that
this is meant to be used by introspection in the same way as
the dynamicElement method above.
2) As a consequence of 1), the same identifier by be used to
point to different classes.
3) they provide an optional adaptor to allow classes that do
not support
a requred interface.
These features may be implemented in different ways, for example:
typedef could be extended to have an implements attribute:
typedef name=and classname=o.a.t.ant.taskdefs.conditions.And
implements=o.a.t.ant.taskdefs.conditions.Condition/
and may then only be used in beans that have the method:
public void dynamicElement(Condition condition)
if the class did not implement the condition, a proxy class
could be defined:
typedef name=diskfull classname=acme.disk.DiskFull
implements=o.a.t.ant.taskdefs.conditions.Condition
proxy=acme.ant.ConditionAdaptor/
or one could have a class that defines adaptors:
a new task may define adaptors:
adaptor classname=o.a.t.ant.taskdefs.conditions.Condition
proxy=acme.ant.ConditionAdaptor/
My feeling is that roles are not needed to support dynamic conditions,
filters ...,
in fact I do not think that typedef is needed:
loadclasses classpathref=${acme.ant.jars}/
condition property=disk.danger.level
acme.disk.DiskFull percent=70 filesystem=/tmp/
/condition
I see typedef/taskdef as providing alaises for java beans.
Peter.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: polymorphism (was Re: antlib)
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Fri, 25 Apr 2003, peter reilly [EMAIL PROTECTED] wrote:
I do not see the problem here: suppose Path implements
dynamicElement(Path path)
one could do:
javac
classpath
PathThatIgnoresBuildSysclassPathToTrickGump
pathelement path=${classpath}/
/PathThatIgnoresBuildSysclassPathToTrickGump
/classpath
/javac
I don't want to use it as nested element of classpath, but as nested
element of javac.
Take classfileset/zipfileset and dependset as another example
(where you can trick me ;-).
I want to be able to be able to use classfileset as srcfileset and
zipfileset as targetfileset - or the other way around.
Actually, peter trick may give us a hint on an easy way to achieve polimorphism.
We just need to provide a way on the basic core type implementations to delegate
all calls to a nested object (similar to what we do for refids).
With that and the roles we would get alot of functionality almost free of charge
and without any changes to the core engine (but roles of course).
Jose Alberto
Re: antlib
On Friday 25 April 2003 12:24, Jose Alberto Fernandez wrote:
Peter,
this is exactly my point. For every new thingy that we add we now need to
go and modify IntrospectionHelper or something to make special allowances
for it.
The dynamicelement addition to IntrospectionHelper is general and new thingies
can be added without affecting core ant.
It is bloating the core like mad and in my opinion it is crazy. We need a
unified way to treat this things no matter what the things are. Ant's
engine core should not need to know anything about anything.
Dynamicelement has the potential to remove code (e.g. all the
addNAME methods to conditionbase, selectorbase, and filterchain). The
only problem is name clashes.
In an ideal world, we should have an engine core with no reference to any
task/type or its implementing classes and a core-antlib which provides the
classes and definintions for all the
task/types/conditions/selectors/mappers that define core java.
This can be done with dynamicelement, except for name clashes and mapper
(which does not use sub-elements for different filenamemappers).
Peter.
Ps: I am including mods to IntrospectionHelper.java and
DynamicElementHelper.java
Index: IntrospectionHelper.java
===
RCS file: /home/cvspublic/ant/src/main/org/apache/tools/ant/IntrospectionHelper.java,v
retrieving revision 1.55
diff -u -r1.55 IntrospectionHelper.java
--- IntrospectionHelper.java 15 Apr 2003 17:23:15 - 1.55
+++ IntrospectionHelper.java 25 Apr 2003 12:14:09 -
@@ -61,6 +61,7 @@
import java.util.Enumeration;
import java.util.Hashtable;
import java.util.Locale;
+import org.apache.tools.ant.helper.DynamicElementHelper;
import org.apache.tools.ant.types.EnumeratedAttribute;
import org.apache.tools.ant.types.Path;
@@ -114,6 +115,11 @@
private Class bean;
/**
+ * The dynamic elements implemented by this class
+ */
+private DynamicElementHelper dynamicElementHelper = null;
+
+/**
* Helper instances we've already created (Class to IntrospectionHelper).
*/
private static Hashtable helpers = new Hashtable();
@@ -199,9 +205,10 @@
nestedTypes = new Hashtable();
nestedCreators = new Hashtable();
nestedStorers = new Hashtable();
+dynamicElementHelper = new DynamicElementHelper(bean);
this.bean = bean;
-
+
Method[] methods = bean.getMethods();
for (int i = 0; i methods.length; i++) {
final Method m = methods[i];
@@ -534,6 +541,15 @@
public Object createElement(Project project, Object parent,
String elementName) throws BuildException {
NestedCreator nc = (NestedCreator) nestedCreators.get(elementName);
+
+if (nc == null) {
+Object nestedElement = dynamicElementHelper.createDynamicElement(
+project, parent, elementName);
+if (nestedElement != null) {
+return nestedElement;
+}
+}
+
if (nc == null parent instanceof DynamicConfigurator) {
DynamicConfigurator dc = (DynamicConfigurator) parent;
Object nestedElement = dc.createDynamicElement(elementName);
@@ -578,7 +594,8 @@
*/
public boolean supportsNestedElement(String elementName) {
return nestedCreators.containsKey(elementName) ||
-DynamicConfigurator.class.isAssignableFrom(bean);
+DynamicConfigurator.class.isAssignableFrom(bean) ||
+dynamicElementHelper.hasDynamicMethods();
}
/**
// {ANT Apache Software License}
package org.apache.tools.ant.helper;
import java.lang.reflect.Method;
import java.lang.reflect.InvocationTargetException;
import java.util.Vector;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.DynamicConfigurator;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.RuntimeConfigurable;
import org.apache.tools.ant.Task;
import org.apache.tools.ant.TaskAdapter;
import org.apache.tools.ant.UnknownElement;
/**
* p
* This class is used to help in handling dynamic elements.
* The idea is to allow easy custom extensions
* and to extend the traditional ant bean reflection to call setters
* methods, or add/create methods, with all the magic type conversion
* it does.
* /p
* p
* The dynamic element classes will be defined by lt;typedef/gt;
* or b(to be decided)/b by lt;taskdef/gt;
* /p
* p
* User classes (tasks or datatypes) have methods
* codedynamicElement(class or interface)/code
* /p
* p
* This class is currently used by DynamicElementTask, but
* may in the future be used by ant core IntrospectionHelper.
* /p
* p
* An example: Suppose one had a task buildpath that resolved
* paths using custom resolvers that implement a BuildPathResolver
* interface.
* /p
* pre
* lt;typedef name=tahoeresolver
*classname=acme.resolvers.TahoeResolver
*
Broken link on src-dist download page
I don´t know where that content is stored. But on http://ant.apache.org/srcdownload.cgi the link to the 1.5.3.1 version of Ant source distribution is broken. .zip archive: apache-ant-1.5.3-1-src.zip [PGP] [MD5] Link for the zip goes to http://apache.serveftp.org/apache-site/dist/ant/source/apache-ant-1.5.3-src. zip but must go to http://apache.serveftp.org/apache-site/dist/ant/source/apache-ant-1.5.3-1-sr c.zip (missing the -1 suffix for the update). Jan Matèrne
DO NOT REPLY [Bug 19301] - junitreport fails
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=19301. 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=19301 junitreport fails --- Additional Comments From [EMAIL PROTECTED] 2003-04-25 12:51 --- I tracked down the problem to the JS-escape template, which produces a StackOverFlowError with Xalan 2.5D1 if the string parameter passed to the template is too long, as can easily happen when processing the java.class.path property. Not sure where the real limit is, all I know is that 7952 characters is too much :-) A temporary fix is to simply skip any long values and display them as '...' instead: xsl:when test=string-length($string) 1000 xsl:text.../xsl:text /xsl:when
cvs commit: ant/xdocs bindownload.xml srcdownload.xml
bodewig 2003/04/25 06:17:26 Modified:docs bindownload.html srcdownload.html xdocsbindownload.xml srcdownload.xml Log: Fix broken link Revision ChangesPath 1.30 +1 -1 ant/docs/bindownload.html Index: bindownload.html === RCS file: /home/cvs/ant/docs/bindownload.html,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- bindownload.html 16 Apr 2003 15:22:35 - 1.29 +++ bindownload.html 25 Apr 2003 13:17:26 - 1.30 @@ -210,7 +210,7 @@ Current Release of Ant /h3 pCurrently, Apache Ant 1.5.3 is the best available version, see the -a href=[preferred]/ant/README.htmlrelease notes/a. /p +a href=[preferred]/ant/README.htmlrelease notes/a./p div class=warning div class=labelNote/div div class=contentAn updated version of Ant 1.5.3 has been released on 17-April-2003 and may not be available on all 1.29 +1 -1 ant/docs/srcdownload.html Index: srcdownload.html === RCS file: /home/cvs/ant/docs/srcdownload.html,v retrieving revision 1.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- srcdownload.html 16 Apr 2003 15:22:35 - 1.28 +++ srcdownload.html 25 Apr 2003 13:17:26 - 1.29 @@ -218,7 +218,7 @@ /div ul licode.zip/code archive: -a href=[preferred]/ant/source/apache-ant-1.5.3-src.zipapache-ant-1.5.3-1-src.zip/a +a href=[preferred]/ant/source/apache-ant-1.5.3-1-src.zipapache-ant-1.5.3-1-src.zip/a [a href=http://www.apache.org/dist/ant/source/apache-ant-1.5.3-1-src.zip.asc;PGP/a] [a href=http://www.apache.org/dist/ant/source/apache-ant-1.5.3-1-src.zip.md5;MD5/a]/li 1.15 +1 -1 ant/xdocs/bindownload.xml Index: bindownload.xml === RCS file: /home/cvs/ant/xdocs/bindownload.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- bindownload.xml 16 Apr 2003 15:22:35 - 1.14 +++ bindownload.xml 25 Apr 2003 13:17:26 - 1.15 @@ -60,7 +60,7 @@ section name=Current Release of Ant pCurrently, Apache Ant 1.5.3 is the best available version, see the -a href=[preferred]/ant/README.htmlrelease notes/a. /p +a href=[preferred]/ant/README.htmlrelease notes/a./p div class=warning div class=labelNote/div 1.13 +1 -1 ant/xdocs/srcdownload.xml Index: srcdownload.xml === RCS file: /home/cvs/ant/xdocs/srcdownload.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- srcdownload.xml 16 Apr 2003 15:22:35 - 1.12 +++ srcdownload.xml 25 Apr 2003 13:17:26 - 1.13 @@ -69,7 +69,7 @@ ul licode.zip/code archive: -a href=[preferred]/ant/source/apache-ant-1.5.3-src.zipapache-ant-1.5.3-1-src.zip/a +a href=[preferred]/ant/source/apache-ant-1.5.3-1-src.zipapache-ant-1.5.3-1-src.zip/a [a href=http://www.apache.org/dist/ant/source/apache-ant-1.5.3-1-src.zip.asc;PGP/a] [a href=http://www.apache.org/dist/ant/source/apache-ant-1.5.3-1-src.zip.md5;MD5/a]/li
Re: Broken link on src-dist download page
On Fri, 25 Apr 2003, Jan Materne [EMAIL PROTECTED] wrote: I don´t know where that content is stored. xdocs/srcdownload.xml But on http://ant.apache.org/srcdownload.cgi the link to the 1.5.3.1 version of Ant source distribution is broken. Yep, only one of them, though. Fixed now. Thanks! Stefan
AW: Broken link on src-dist download page
-Ursprüngliche Nachricht- Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] Gesendet am: Freitag, 25. April 2003 15:20 An: [EMAIL PROTECTED] Betreff: Re: Broken link on src-dist download page On Fri, 25 Apr 2003, Jan Materne [EMAIL PROTECTED] wrote: I don´t know where that content is stored. xdocs/srcdownload.xml Ah, yes. Found :-) But on http://ant.apache.org/srcdownload.cgi the link to the 1.5.3.1 version of Ant source distribution is broken. Yep, only one of them, though. Fixed now. Thanks! Of course! Jan
Re: polymorphism (was Re: antlib)
On Fri, 25 Apr 2003, peter reilly [EMAIL PROTECTED] wrote: On Friday 25 April 2003 11:54, Stefan Bodewig wrote: I don't want to use it as nested element of classpath, but as nested element of javac. Why because it feels more natural? and how (from an xml point-of-view)? One of the questions that usually get us stuck 8-) classpath ant:type=PathThatIgnoresBuildSysclassPathToTrickGump or PathThatIgnoresBuildSysclassPathToTrickGump ant:element=classpath are alternatives (without any claim for completeness) with quite different consequences when it comes to the implementation side of things. Neither would require any formal definition of roles. Stefan
Re: polymorphism (was Re: antlib)
On Fri, 25 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Actually, peter trick may give us a hint on an easy way to achieve polimorphism. We just need to provide a way on the basic core type implementations to delegate all calls to a nested object (similar to what we do for refids). Easy from the implementation side, but is it intuitive for the user to write? copy ... fileset classfileset ... /fileset /copy condition condition true/ /condition /condition In simple non-ambiguos cases like the above this could be without the trick. copy ... classfileset ... /copy condition true/ /condition Stefan
RE: antlib
Jose Alberto Fernandez wrote:
Peter,
this is exactly my point. For every new thingy that we add we now need to
go and modify IntrospectionHelper or something to make special allowances
for it.
It is bloating the core like mad and in my opinion it is crazy. We need a
unified way to treat this things no matter what the things are. Ant's
engine core should not need to know anything about anything.
Fine - but do this in core, not in antlib.
Antlib needs to load whatever ant supports. Not to define new things.
I don't have any problem with polymorphism ( or roles ). Nobody said they
shouldn't be added. My only comment is that the implementation of
polymorphism shouldn't be tied with antlib, and I would preffer a solution
that would simplify the core - i.e. interfaces or something like that, that
would allow us to treat all components as components at the low level.
An unified way to treat all the sub-types should be defined and implemented
as part of the core.
We can wait with antlib ( the part that loads whatever-things-ant-supports)
until polymorphism is defined, but I would preffer having antlib included
in ant sooner.
Costin
In an ideal world, we should have an engine core with no reference to any
task/type or its implementing classes and a core-antlib which provides the
classes and definintions for all the
task/types/conditions/selectors/mappers that define core java.
We could even have separate release cycles for it.
THAT is the potential for antlib (and it is not polimorphish).
Jose Alberto
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: 25 April 2003 10:30
To: Ant Developers List
Subject: Re: antlib
On Friday 25 April 2003 08:31, Stefan Bodewig wrote:
On Thu, 24 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote:
Look - adding roles concept to ant, and adding antlib are 2
separate issues.
+1
I tend to agree - that's why I proposed to get antlib into the main
trunk with support for types and tasks only. At least for starters.
If you want a custom mapper you can do so right now with a data type
and refid. The same is not true for filter readers, conditions or
selectors. But I feel that enabling that would inevitably
lead us to
Not quite true for filter readers.
In CVS HEAD, FilterChain has a currently (deliberate)
undocumented feature of
implementing DynamicConfigurator. The implementation looks up the
name in the types and if present and if the bean implements
ChainableReader
it is used as a ChainableReader.
This is used to support ScriptFilter. Script reader is an optional
ChainableReader which depends on the presence of BSF and thus cannot
be implemented in the same way as the other built-in ChainableReaders.
the more general polymorphism discussion and this is what I
wanted to
avoid 8-).
I have implemented a generalization of FilterChain's
usage of DynamicConfigurator in IntrospectionHelper.
This extends the introspection support to include methods of the form:
public void dynamicElement(type name);
So in my local ant build the relavant part of FilterChain.java is
public void dynamicElement(ChainableReader reader) {
filterReaders.addElement(reader);
}
and of ConditionBase.java
public void dynamicElement(Condition condition) {
conditions.addElement(condition);
}
As regards using roles:
(note: Roles in the antlib proposal are not completely implemented,ie.
there is no condition, mapper or filter implementation so
my comments may be correct).
Roles in the proposal provide three features:
1) they provide a way of limiting the scope of the tag. I assume that
this is meant to be used by introspection in the same way as
the dynamicElement method above.
2) As a consequence of 1), the same identifier by be used to
point to different classes.
3) they provide an optional adaptor to allow classes that do
not support
a requred interface.
These features may be implemented in different ways, for example:
typedef could be extended to have an implements attribute:
typedef name=and classname=o.a.t.ant.taskdefs.conditions.And
implements=o.a.t.ant.taskdefs.conditions.Condition/
and may then only be used in beans that have the method:
public void dynamicElement(Condition condition)
if the class did not implement the condition, a proxy class
could be defined:
typedef name=diskfull classname=acme.disk.DiskFull
implements=o.a.t.ant.taskdefs.conditions.Condition
proxy=acme.ant.ConditionAdaptor/
or one could have a class that defines adaptors:
a new task may define adaptors:
adaptor classname=o.a.t.ant.taskdefs.conditions.Condition
proxy=acme.ant.ConditionAdaptor/
My feeling
Re: polymorphism (was Re: antlib)
On Friday 25 April 2003 14:30, Stefan Bodewig wrote: because it feels more natural? classpath ant:type=PathThatIgnoresBuildSysclassPathToTrickGump or PathThatIgnoresBuildSysclassPathToTrickGump ant:element=classpath I see. This is an interesting idea, whether is more natural is debatable ;-). A thing to note is that ant: assumes that an xml namespace is set-up, ... xmlns:ant=... Another similar idea could be: classpath implementationClass=acme.ant.TrickGump ... are alternatives (without any claim for completeness) with quite different consequences when it comes to the implementation side of things. One of the consequences is that Javac's public method createClasspath() may need to be modified. Peter
cvs commit: ant/proposal/xdocs/dvsl task.dvsl
jesse 2003/04/25 07:09:11
Modified:proposal/xdocs/lib xdoclet-apache-module-1.2b3-dev.jar
proposal/xdocs/dvsl task.dvsl
Log:
Generate attribute requirements
Revision ChangesPath
1.2 +103 -92
ant/proposal/xdocs/lib/xdoclet-apache-module-1.2b3-dev.jar
Binary file
1.5 +40 -7 ant/proposal/xdocs/dvsl/task.dvsl
Index: task.dvsl
===
RCS file: /home/cvs/ant/proposal/xdocs/dvsl/task.dvsl,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- task.dvsl 14 Feb 2003 20:37:23 - 1.4
+++ task.dvsl 25 Apr 2003 14:09:11 - 1.5
@@ -54,7 +54,7 @@
#set( $project =
$node.selectSingleNode(document('xdocs/stylesheets/project.xml')/project ) )
#if ($node.name().equals(task))
#set( $title = #capitalize($attrib.name) Task )
-#set( $summary = $node.short-description )
+#set( $summary = $node.short-description )
#end
html
@@ -105,7 +105,7 @@
!-- Applying task/long-description --
#**#$context.applyTemplates(long-description)
#* *##end
-#* *#$context.applyTemplates(structure/attributes)
+#* *#$context.applyTemplates(structure/attribute-groups)
#* *#$context.applyTemplates(structure/elements)
#* *#$context.applyTemplates(external/section)
#**##end
@@ -154,6 +154,16 @@
#end
#*
+Macro to format a table body cell that spans multiple rows
+*#
+#macro( tdmr $text $rows )
+td bgcolor=$table-td-bg valign=top align=left rowspan=$rows
+ font color=#00 size=-1
face=arial,helvetica,sanserif$text/font
+/td
+#end
+
+
+#*
Macro to format a section banner
*#
#macro( section $anchor $name )
@@ -215,19 +225,18 @@
#*
Process top level attributes
*#
-#match( structure/attributes )
+#match( structure/attribute-groups )
!-- Start Attributes --
table border=0 cellspacing=0 cellpadding=2 width=100%
trtdnbsp;/td/tr
-
-#* *##section(attributes Parameters)
-
+#* *##section(attributes Parameters)
trtdblockquote
table
tr
#* *##th(Attribute)
#* *##th(Description)
#* *##th(Type)
+#* *##th(Requirement)
/tr
#**#$context.applyTemplates(*)
/table
@@ -238,14 +247,29 @@
#end
#*
+Process attribute group
+*#
+#match( structure/attribute-groups/attribute-group )
+!-- Attribute Group --
+#set ($attributeGroup = $attrib.description)
+#set ($numGroups = $node.selectNodes(attribute).size())
+#set ($inGroup = true)
+#**#$context.applyTemplates(*)
+#end
+
+#*
Process a single attribute
*#
-#match( attribute )
+#match( structure/attribute-groups/attribute-group/attribute )
!-- Attribute --
tr
#**##td($attrib.name)
#**##td($node.description)
#**##td($attrib.briefType)
+#if ($inGroup)
+#**##tdmr($attributeGroup $numGroups)
+#set ($inGroup = false)
+#end
/tr
#end
@@ -383,6 +407,15 @@
$context.applyTemplates(*)
/td/tr
/table
+#end
+
+#*
+ * process a the requirement groups
+ *#
+#match( requirement-group )
+#if ($regGroup == $attrib.name)
+#* *#$attrib.description
+#end
#end
#match( source )
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs Property.java
jesse 2003/04/25 07:11:16
Modified:src/main/org/apache/tools/ant/taskdefs Property.java
Log:
Add some new @tags for xdocs
Revision ChangesPath
1.61 +38 -23ant/src/main/org/apache/tools/ant/taskdefs/Property.java
Index: Property.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/Property.java,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- Property.java 18 Apr 2003 23:40:22 - 1.60
+++ Property.java 25 Apr 2003 14:11:16 - 1.61
@@ -99,6 +99,9 @@
* @author a href=mailto:[EMAIL PROTECTED]Sam Ruby/a
* @author a href=mailto:[EMAIL PROTECTED]Glenn McAllister/a
* @since Ant 1.1
+ *
+ * @ant.attribute.group name=name description=One of these, when
using the name attribute
+ * @ant.attribute.group name=nonamedescription=One of these, when not
using the name attribute
*/
public class Property extends Task {
@@ -134,7 +137,7 @@
}
/**
- * sets the name of the property to set.
+ * The name of the property to set.
* @param name property name
*/
public void setName(String name) {
@@ -152,14 +155,18 @@
* current platforms conventions). Otherwise it is taken as a path
* relative to the project's basedir and expanded.
* @param location path to set
+ *
+ * @ant.attribute group=name
*/
public void setLocation(File location) {
setValue(location.getAbsolutePath());
}
/**
- * Sets the value of the property.
+ * The value of the property.
* @param value value to assign
+ *
+ * @ant.attribute group=name
*/
public void setValue(String value) {
this.value = value;
@@ -170,8 +177,10 @@
}
/**
- * the filename of a property file to load.
- [EMAIL PROTECTED] file filename
+ * Filename of a property file to load.
+ * @param file filename
+ *
+ * @ant.attribute group=noname
*/
public void setFile(File file) {
this.file = file;
@@ -208,6 +217,8 @@
* Only yields reasonable results for references
* PATH like structures or properties.
* @param ref reference
+ *
+ * @ant.attribute group=name
*/
public void setRefid(Reference ref) {
this.ref = ref;
@@ -218,8 +229,10 @@
}
/**
- * the resource name of a property file to load
+ * The resource name of a property file to load
* @param resource resource on classpath
+ *
+ * @ant.attribute group=noname
*/
public void setResource(String resource) {
this.resource = resource;
@@ -230,23 +243,25 @@
}
/**
-* the prefix to use when retrieving environment variables.
-* Thus if you specify environment=quot;myenvquot;
-* you will be able to access OS-specific
-* environment variables via property names quot;myenv.PATHquot; or
-* quot;myenv.TERMquot;.
-* p
-* Note that if you supply a property name with a final
-* quot;.quot; it will not be doubled. ie
environment=quot;myenv.quot; will still
-* allow access of environment variables through quot;myenv.PATHquot;
and
-* quot;myenv.TERMquot;. This functionality is currently only
implemented
-* on select platforms. Feel free to send patches to increase the number
of platforms
-* this functionality is supported on ;).br
-* Note also that properties are case sensitive, even if the
-* environment variables on your operating system are not, e.g. it
-* will be ${env.Path} not ${env.PATH} on Windows 2000.
-* @param env prefix
-*/
+ * Prefix to use when retrieving environment variables.
+ * Thus if you specify environment=quot;myenvquot;
+ * you will be able to access OS-specific
+ * environment variables via property names quot;myenv.PATHquot; or
+ * quot;myenv.TERMquot;.
+ * p
+ * Note that if you supply a property name with a final
+ * quot;.quot; it will not be doubled. ie
environment=quot;myenv.quot; will still
+ * allow access of environment variables through quot;myenv.PATHquot;
and
+ * quot;myenv.TERMquot;. This functionality is currently only
implemented
+ * on select platforms. Feel free to send patches to increase the number
of platforms
+ * this functionality is supported on ;).br
+ * Note also that properties are case sensitive, even if the
+ * environment variables on your operating system are not, e.g. it
+ * will be ${env.Path} not ${env.PATH} on Windows 2000.
+ * @param env prefix
+ *
+ * @ant.attribute group=noname
+ */
public void setEnvironment(String env) {
cvs commit: ant build.xml
jesse 2003/04/25 07:16:47 Modified:.build.xml Log: Add 2 new @tags that should be ignored by javadoc Revision ChangesPath 1.371 +2 -0 ant/build.xml Index: build.xml === RCS file: /home/cvs/ant/build.xml,v retrieving revision 1.370 retrieving revision 1.371 diff -u -r1.370 -r1.371 --- build.xml 23 Apr 2003 15:57:42 - 1.370 +++ build.xml 25 Apr 2003 14:16:47 - 1.371 @@ -1353,6 +1353,8 @@ tag name=todo description=To do: scope=all/ tag name=ant.task enabled=false description=Task: scope=types/ tag name=ant.datatype enabled=false description=Data type: scope=types/ + tag name=ant.attribute enabled=false description=Attribute: scope=types/ + tag name=ant.element enabled=false description=Nested element: scope=types/ group title=Apache Ant Core packages=org.apache.tools.ant*/ group title=Core Tasks packages=org.apache.tools.ant.taskdefs*/ group title=Core Types packages=org.apache.tools.ant.types*/
Re: polymorphism (was Re: antlib)
On Friday 25 April 2003 14:34, Stefan Bodewig wrote: On Fri, 25 Apr 2003, Jose Alberto Fernandez In simple non-ambiguos cases like the above this could be without the trick. copy ... classfileset ... /copy condition true/ /condition This is exactly what dynamicElement is for. For example: as ConditionBase has dynamicElement(Condition c) and as IfTask extends ConditionBase, and OutOfDate implements Condition, the following works with my build: if outofdate targetfiles path=build.xml/ sourcefiles path=build.xml/ /outofdate else echo message=build.xml is not outofdate/ /else /if Peter.
cvs commit: ant build.xml
jesse 2003/04/25 07:21:35 Modified:.build.xml Log: 1 more @tag to ignore Revision ChangesPath 1.372 +1 -0 ant/build.xml Index: build.xml === RCS file: /home/cvs/ant/build.xml,v retrieving revision 1.371 retrieving revision 1.372 diff -u -r1.371 -r1.372 --- build.xml 25 Apr 2003 14:16:47 - 1.371 +++ build.xml 25 Apr 2003 14:21:35 - 1.372 @@ -1354,6 +1354,7 @@ tag name=ant.task enabled=false description=Task: scope=types/ tag name=ant.datatype enabled=false description=Data type: scope=types/ tag name=ant.attribute enabled=false description=Attribute: scope=types/ + tag name=ant.attribute.group enabled=false description=Attribute group: scope=types/ tag name=ant.element enabled=false description=Nested element: scope=types/ group title=Apache Ant Core packages=org.apache.tools.ant*/ group title=Core Tasks packages=org.apache.tools.ant.taskdefs*/
DO NOT REPLY [Bug 19323] - user-defined sequential class requires lower case nested 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=19323. 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=19323 user-defined sequential class requires lower case nested tasks --- Additional Comments From [EMAIL PROTECTED] 2003-04-25 14:24 --- Fails in Ant 1.6, too: Ant-Home: c:\seu\ant16.1 Java-Home: c:\seu\jdk14 Buildfile: build.xml fail: [Prattle] hello BUILD FAILED C:\temp\build.xml:8: Could not create task or type of type: prattle. Ant could not find the task or a class this task relies upon. This is common and has a number of causes; the usual ... --- Ant diagnostics report --- Apache Ant version 1.6alpha compiled on April 15 2003 --- Implementation Version (JDK1.2+ only) --- core tasks : 1.5.9 optional tasks : 1.5.9 ... --- System properties --- java.vm.version : 1.4.0_01-b03 os.name : Windows 2000 ... Sorry, but I can´t find any hint in the sources ...
[PATCH] docs/manual/install.html: src-distribution directory stru cture documented
Title: [PATCH] docs/manual/install.html: src-distribution directory structure documented I have documented the directory structure of the source distribution. Maybe it´s worth to be added? Attached the diff-file and the whole html. Jan Matèrne install.html.diff install.html
Re: cvs commit: ant/proposal/xdocs/dvsl task.dvsl
Got patches to the antdoclet stuff you'd like me to commit on the
XDoclet codebase?
Nice work (having not run it yet myself, just browsing the commit
messages)!
Erik
On Friday, April 25, 2003, at 10:09 AM, [EMAIL PROTECTED] wrote:
jesse 2003/04/25 07:09:11
Modified:proposal/xdocs/lib xdoclet-apache-module-1.2b3-dev.jar
proposal/xdocs/dvsl task.dvsl
Log:
Generate attribute requirements
Revision ChangesPath
1.2 +103 -92
ant/proposal/xdocs/lib/xdoclet-apache-module-1.2b3-dev.jar
Binary file
1.5 +40 -7 ant/proposal/xdocs/dvsl/task.dvsl
Index: task.dvsl
===
RCS file: /home/cvs/ant/proposal/xdocs/dvsl/task.dvsl,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- task.dvsl 14 Feb 2003 20:37:23 - 1.4
+++ task.dvsl 25 Apr 2003 14:09:11 - 1.5
@@ -54,7 +54,7 @@
#set( $project =
$node.selectSingleNode(document('xdocs/stylesheets/project.xml')/
project ) )
#if ($node.name().equals(task))
#set( $title = #capitalize($attrib.name) Task )
-#set( $summary = $node.short-description )
+#set( $summary = $node.short-description )
#end
html
@@ -105,7 +105,7 @@
!-- Applying task/long-description --
#**#$context.applyTemplates(long-description)
#* *##end
-#* *#$context.applyTemplates(structure/attributes)
+#* *#$context.applyTemplates(structure/attribute-groups)
#* *#$context.applyTemplates(structure/elements)
#* *#$context.applyTemplates(external/section)
#**##end
@@ -154,6 +154,16 @@
#end
#*
+Macro to format a table body cell that spans multiple rows
+*#
+#macro( tdmr $text $rows )
+td bgcolor=$table-td-bg valign=top align=left
rowspan=$rows
+ font color=#00 size=-1
face=arial,helvetica,sanserif$text/font
+/td
+#end
+
+
+#*
Macro to format a section banner
*#
#macro( section $anchor $name )
@@ -215,19 +225,18 @@
#*
Process top level attributes
*#
-#match( structure/attributes )
+#match( structure/attribute-groups )
!-- Start Attributes --
table border=0 cellspacing=0 cellpadding=2 width=100%
trtdnbsp;/td/tr
-
-#* *##section(attributes Parameters)
-
+#* *##section(attributes Parameters)
trtdblockquote
table
tr
#* *##th(Attribute)
#* *##th(Description)
#* *##th(Type)
+#* *##th(Requirement)
/tr
#**#$context.applyTemplates(*)
/table
@@ -238,14 +247,29 @@
#end
#*
+Process attribute group
+*#
+#match( structure/attribute-groups/attribute-group )
+!-- Attribute Group --
+#set ($attributeGroup = $attrib.description)
+#set ($numGroups = $node.selectNodes(attribute).size())
+#set ($inGroup = true)
+#**#$context.applyTemplates(*)
+#end
+
+#*
Process a single attribute
*#
-#match( attribute )
+#match( structure/attribute-groups/attribute-group/attribute )
!-- Attribute --
tr
#**##td($attrib.name)
#**##td($node.description)
#**##td($attrib.briefType)
+#if ($inGroup)
+#**##tdmr($attributeGroup $numGroups)
+#set ($inGroup = false)
+#end
/tr
#end
@@ -383,6 +407,15 @@
$context.applyTemplates(*)
/td/tr
/table
+#end
+
+#*
+ * process a the requirement groups
+ *#
+#match( requirement-group )
+#if ($regGroup == $attrib.name)
+#* *#$attrib.description
+#end
#end
#match( source )
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bug 13655: proper retrncode for ant.bat
Hello, I sent a patch in to fix this bug about two months ago and have yet to hear any response. Is there something I did wrong? How can I get this checked in? Simon N.B. Please CC me on replies.
Re: cvs commit: ant/proposal/xdocs/dvsl task.dvsl
On Fri, 25 Apr 2003, Erik Hatcher [EMAIL PROTECTED] wrote: stuff you'd like me to commit on the XDoclet codebase? OK, my snippage isn't fair, I know 8-) How about Jira Issue XJD-21, Gump would really benefit from it 8-) Stefan
Re: cvs commit: ant/proposal/xdocs/dvsl task.dvsl
On Fri, 2003-04-25 at 10:29, Erik Hatcher wrote: Got patches to the antdoclet stuff you'd like me to commit on the XDoclet codebase? Yes. I've checked in a binary in the proposal tree, but Gump wont use it, so I need to get them into XDoclet's CVS tree. How much work wuld be involved in moving the antdoclet module to Ant's CVS tree? Nice work (having not run it yet myself, just browsing the commit messages)! Have a look here for a sample http://www.magma.ca/~stockall/property.html -- Jesse Stockall [EMAIL PROTECTED]
RE: antlib
From: Costin Manolache [mailto:[EMAIL PROTECTED] Fine - but do this in core, not in antlib. But this are changes to core. Granted they are comming as part of the bundle but they are not in antlib. What it is in antlib is a way to declare these roles and I am 100% with you that we should be able to declare them with a task of their owm that can be used in the buildfile directly. Fine with me. Antlib needs to load whatever ant supports. Not to define new things. I don't have any problem with polymorphism ( or roles ). Nobody said they shouldn't be added. My only comment is that the implementation of polymorphism shouldn't be tied with antlib, and I would preffer a solution that would simplify the core - i.e. interfaces or something like that, that would allow us to treat all components as components at the low level. Well this is exactly what I am trying to achieve, and I think the it does. Roles ARE interfaces not strings. The names of the roles are just syntactic sugar to simplify declarations. An unified way to treat all the sub-types should be defined and implemented as part of the core. 100% with you. We can wait with antlib ( the part that loads whatever-things-ant-supports) until polymorphism is defined, but I would preffer having antlib included in ant sooner. Sounds good. Jose Alberto
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-25 15:00 --- This is the original author of the question. I downloaded the source and built Ant-1.5.3.1 this morning. I am able to view the Jars using Winzip. Thanks to everyone who responded to my question. It's very nice to have have a group such as this to bounce ideas off.
RE: polymorphism (was Re: antlib)
This discussion starts to get interesting. Just a few thoughts... because it feels more natural? classpath ant:type=PathThatIgnoresBuildSysclassPathToTrickGump or PathThatIgnoresBuildSysclassPathToTrickGump ant:element=classpath I see. This is an interesting idea, whether is more natural is debatable ;-). It'd be natural to people who've worked with XML Schema Instance documents, where you'd write something like: classpath xsi:type=my:somekindofpath/ Maybe the XML Namespace like notation of my:somekindofpath could mean that somekindofpath is a task/type defined in antlib my. But also something like my:somekindofpath/ by itself (not nested in another task) could be made possible. In both cases Ant would have to use the somekindofpath task in the antlib registered as my (or actually the URI which my is a prefix for). A thing to note is that ant: assumes that an xml namespace is set-up, ... xmlns:ant=... The way described namespaces could be used to denote antlibs. But again, I guess these ideas are both about antlib and roles (and even about the use of namespaces). Another similar idea could be: classpath implementationClass=acme.ant.TrickGump ... are alternatives (without any claim for completeness) with quite different consequences when it comes to the implementation side of things. One of the consequences is that Javac's public method createClasspath() may need to be modified. Yes, the addXXX() methods are probably way easier to deal with. -- knut
DO NOT REPLY [Bug 14849] - JProbe tasks: executables cannot be found with JProbe 4.0.1
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14849. 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=14849 JProbe tasks: executables cannot be found with JProbe 4.0.1 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-04-25 16:21 --- Hi Stefan, I built the ant_20030425102107.tar.gz nightly snapshot and tested all three tasks with JProbe 4.0.2. jpcoverage/ and jpcovreport/ seem OK. However, there is still a small bug in CovMerge.java : in createParamFile(), you put the tofile file into the temporary paramfile: // last file is the output snapshot pw.println(getProject().resolveFile(tofile.getPath())); The output file has to be the last argument on the command line (it's not optional) and cannot be put into the paramfile. Otherwise Jprobe will complain: [jpcovmerge] Missing arguments I paste the commandline help: C:\Program Files\JProbe Suite 4.0.2\binjpcovmerge.exe jpcovmerge [-v] [-paramfile=file] snapshot file1 file2 ... output Merge multiple snapshots: -paramfile=file A file containing a list of files to be merged These files are inserted in the list at the point where the -paramfile option is located -v Verbose mode for displaying diagnostic information Best regards, Jan
DO NOT REPLY [Bug 13222] - [PATCH] ClearCase mklabel and mklbtype 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=13222. 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=13222 [PATCH] ClearCase mklabel and mklbtype tasks [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-04-25 16:27 --- *** This bug has been marked as a duplicate of 17408 ***
Re: polymorphism (was Re: antlib)
On Friday 25 April 2003 16:45, Wannheden, Knut wrote:
It'd be natural to people who've worked with XML Schema Instance documents,
where you'd write something like:
classpath xsi:type=my:somekindofpath/
Maybe the XML Namespace like notation of my:somekindofpath could mean
that somekindofpath is a task/type defined in antlib my. But also
something like
my:somekindofpath/
by itself (not nested in another task) could be made possible. In both
cases Ant would have to use the somekindofpath task in the antlib
registered as my (or actually the URI which my is a prefix for).
A thing to note is that ant: assumes that an xml namespace
is set-up,
... xmlns:ant=...
The way described namespaces could be used to denote antlibs.
But again, I guess these ideas are both about antlib and roles (and even
about the use of namespaces).
Yes four different items.
I have been thinking about using namespaces with antlibs like this:
project
.. init properies .../
use xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/use
/project
Another similar idea could be:
classpath implementationClass=acme.ant.TrickGump ...
are alternatives (without any claim for completeness) with quite
different consequences when it comes to the implementation side of
things.
One of the consequences is that Javac's public method
createClasspath()
may need to be modified.
Yes, the addXXX() methods are probably way easier to deal with.
Yes, Introspection should allow constructors having Project as a parameter.
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-25 16:58 --- Can somebody who has already contributed to the other ClearCase tasks review this and see: * if there is a use-case; * if it works as stated; * if you are willing to support this at a later stage.
RE: antlib
Jose Alberto Fernandez wrote: From: Costin Manolache [mailto:[EMAIL PROTECTED] Fine - but do this in core, not in antlib. But this are changes to core. Granted they are comming as part of the bundle but they are not in antlib. All I ask is to do the changes in the core separately. Costin
Re: antlib
On Friday, April 25, 2003, at 01:25 PM, Costin Manolache wrote: All I ask is to do the changes in the core separately. +1 I'm in agreement with you on the order of events, Costin, 100%. antlib with tasks/datatypes is fair game to migrate into HEAD, then core changes to make the other components work as pluggable pieces, then refactoring antlib to support it. I also agree with the use of interfaces (not just marker ones, per se) for distinguishing what components are used for. Again, its cool that Ant supports making lightweight tasks, but I think it should be more rigid in the future and mandating components implement a particular interface. Most of us at least extend Task when writing tasks, I suspect, too. :) Erik
Re: cvs commit: ant/proposal/xdocs/dvsl task.dvsl
On Friday, April 25, 2003, at 10:41 AM, Jesse Stockall wrote: On Fri, 2003-04-25 at 10:29, Erik Hatcher wrote: Got patches to the antdoclet stuff you'd like me to commit on the XDoclet codebase? Yes. I've committed the patches to XDoclet's CVS that you sent to me. Let me know if there are any issues or I missed anything. I will work on migrating the antdoclet stuff to Ant's CVS next, and removing it from XDoclet's codebase. Erik
Re: antlib
On Friday 25 April 2003 18:32, Erik Hatcher wrote: On Friday, April 25, 2003, at 01:25 PM, Costin Manolache wrote: All I ask is to do the changes in the core separately. +1 +1 I'm in agreement with you on the order of events, Costin, 100%. antlib with tasks/datatypes is fair game to migrate into HEAD, then with xml or with properties? core changes to make the other components work as pluggable pieces, then refactoring antlib to support it. +1 I also agree with the use of interfaces (not just marker ones, per se) for distinguishing what components are used for. Again, its cool that Ant supports making lightweight tasks, but I think it should be more rigid in the future and mandating components implement a particular interface. Most of us at least extend Task when writing tasks, I suspect, too. :) +1 Peter
Re: antlib
On Friday, April 25, 2003, at 01:39 PM, peter reilly wrote: I'm in agreement with you on the order of events, Costin, 100%. antlib with tasks/datatypes is fair game to migrate into HEAD, then with xml or with properties? I don't care. :)) So take that as a +0 on either - for the time being. I think XML is the right choice, personally, but its of little concern to me. Erik
Re: Antlib descriptor
On Friday, April 25, 2003, at 01:39 PM, Costin Manolache wrote: New thread. +1 :) However I'm more convinced than ever that the XML should use a subset of ant, and reuse the same processing infrastructure. I.e. not another parser or rules. I'll defer commenting on this until I ponder it more and see what others say about it. Erik and few others seem to believe that the XML vocabulary doesn't matter, and anything can be generated by xdoclet and processed. If this is the case - then using ant syntax in the antlib descriptor would be as good as another syntax. Well, again, don't stretch my thoughts on this too far. I meant it didn't matter *now*, in terms of getting it migrated to HEAD and having it in a place handy for all of us to work with and evolve it. It does matter though. - maybe we want antlibs to have some initialization. This can be easily done by allowing more ant elements in the descriptor - maybe we'll want to allow antlib to declare targets - that could be used in depends or antcall ( target name=foo depends=myAntLib:antlibTarget/ ). Wow ok, still pondering Again - those are just examples, there are a lot of things that could be done easily. Even if you don't need any of this - it would be nice to not have to repeat the long and painfull evolution of the main xml processor. It'll take some thinking and convincing for me to see why antlib needs descriptors that get processed like Ant build files. Something as simple as Digester would seem to do the trick (bootstrap craziness?!) but as I said, I want to see what others think and let myself consider your idea a bit more. Erik
Re: Antlib descriptor
Erik Hatcher wrote: - maybe we want antlibs to have some initialization. This can be easily done by allowing more ant elements in the descriptor - maybe we'll want to allow antlib to declare targets - that could be used in depends or antcall ( target name=foo depends=myAntLib:antlibTarget/ ). Wow ok, still pondering Please - don't take this as we should do this. It may be the worst idea ever. What I'm trying to say is that a lot of things we might want later will be simpler, and we won't have to bloat the antlib SAX processor to implement such features. I'm sure there are some valid uses cases and extensions that we may add - even if those 2 use cases are completely wrong. It is very unlikely antlib will never change. Again - those are just examples, there are a lot of things that could be done easily. Even if you don't need any of this - it would be nice to not have to repeat the long and painfull evolution of the main xml processor. It'll take some thinking and convincing for me to see why antlib needs descriptors that get processed like Ant build files. Something as simple as Digester would seem to do the trick (bootstrap craziness?!) but as I said, I want to see what others think and let myself consider your idea a bit more. - consistency. I think it would be a bad idea to use Digester in antlib and another mechanism in ProjectHelper. Plus digester would add dependencies on beanutils, collections - we already have introspection code. I can accept replacing ProjectHelper with Digester - but I would like we use the same mechanism. - same kind of extensibility as ant. It may not be perfect - but at least will be consistent and most people understand it. - We can just use the same ( or almost ) code for taskdef, roles and whatever else we want to allow to be defined in antlib. - very easy to implement ( minor changes in ProjectHelper to parse antlib at top and restrict the childs ). Actually, antlib could be a task ( so antlib elements could be used in a build file - another stupid idea ), and we can just change PH to start with a different root. - easier to maintain. I know we're all SAX experts, but we've seen a lot of tricky aspects in ProjectHelper long evolution. This way we maintain a single parser - and a single behavior. - all the wonderful features that may be easily enabled ( if they prove to not be very bad ideas ). I can add more to the list. Costin
RE: Antlib descriptor
From: Erik Hatcher [mailto:[EMAIL PROTECTED] - maybe we want antlibs to have some initialization. This can be easily done by allowing more ant elements in the descriptor - maybe we'll want to allow antlib to declare targets - that could be used in depends or antcall ( target name=foo depends=myAntLib:antlibTarget/ ). Wow ok, still pondering Again - those are just examples, there are a lot of things that could be done easily. Even if you don't need any of this - it would be nice to not have to repeat the long and painfull evolution of the main xml processor. It'll take some thinking and convincing for me to see why antlib needs descriptors that get processed like Ant build files. Something as simple as Digester would seem to do the trick (bootstrap craziness?!) but as I said, I want to see what others think and let myself consider your idea a bit more. I am not too keen on having alive ANTS roaming in my classpath. Jar files are passive things, in general having too many in your classpath does not mean you will execute more stuff. I think that is nice and autoinitializing jars (antlibs) sound way too scary at this point. Jose Alberto
DO NOT REPLY [Bug 17040] - JUnit task report does not use the one defined by setName method
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=17040.
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=17040
JUnit task report does not use the one defined by setName method
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Additional Comments From [EMAIL PROTECTED] 2003-04-25 19:01 ---
Stefan,
The failed test cases are being reported twice. To avoid this, we need to
add failedTests.put(test, test); in the addFailure section as below.
public void addFailure(Test test, AssertionFailedError t) {
addFailure(test, (Throwable) t);
failedTests.put(test, test);
}
Sorry that this took long, as I haven't found a 1.6 build that worked for me.
I simply took the source, and re-compiled it with the 1.5.1 environment to
verify the bug.
RE: Antlib descriptor
Jose Alberto Fernandez wrote: I am not too keen on having alive ANTS roaming in my classpath. Jar files are passive things, in general having too many in your classpath does not mean you will execute more stuff. I think that is nice and autoinitializing jars (antlibs) sound way too scary at this point. AFAIK the proposal doesn't implement autodiscovery - and we don't know if we will get getResources(META-INF/antlib.xml ) or require explicit antlib In any case - it is easy to give user explicit control. In many systems libraries have a initialization mechanism. We may only allow conditions for example - but I don't see anything fundamentally wrong with this, that would guarantee we'll never want to do this. Same for allowing libraries to define fragments and targets - maybe today most people thing it is a crazy idea, but one year from now we may find it usefull. Of course, we could change the parser then - but we'll accumulate a lot of behaviors that would make this difficult. Costin
RE: polymorphism (was Re: antlib)
I have been thinking about using namespaces with antlibs like this:
project
.. init properies .../
use xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/use
/project
That is almost the same thing as I had in mind. Although I've been thinking
about some slight variations to this, where no top-level element like use/
would be necessary. The Jelly style would be:
project xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
.. init properies .../
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
Here target/ is still toplevel and the antlibs are loaded on project
initialization (or on demand). But I'm not sure I like this automagical
loading. Something inbetween would be this:
project
.. init properies .../
use resource=${ant-contrib.jar} ns=antlib:ant-contrib/
use resource=${antelope.jar} ns=antlib:antelope/
target name=test xmlns:antcontrib=antlib:ant-contrib
xmlns:antelope=antlib:antelope
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
which is slightly more verbose, but cleaner IMO. Especially since the
antlib loading is explicit.
--
knut
cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/sos SOS.java SOSCheckin.java SOSCheckout.java SOSGet.java SOSLabel.java
jesse 2003/04/25 14:10:02
Modified:src/main/org/apache/tools/ant/taskdefs/optional/sos SOS.java
SOSCheckin.java SOSCheckout.java SOSGet.java
SOSLabel.java
Log:
Fix the javadoc comments and add @ant.attribute tags for xdocs documentation
generation
Revision ChangesPath
1.14 +23 -15
ant/src/main/org/apache/tools/ant/taskdefs/optional/sos/SOS.java
Index: SOS.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/sos/SOS.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- SOS.java 10 Feb 2003 14:14:25 - 1.13
+++ SOS.java 25 Apr 2003 21:10:02 - 1.14
@@ -94,8 +94,9 @@
protected Commandline commandLine;
/**
- * Flag to disable the cache when set;
- * optional needed if SOSHOME is set as an environment variable.,
default false
+ * Flag to disable the cache when set.
+ * Required if SOSHOME is set as an environment variable.
+ * Defaults to false.
*
* @param nocache True to disable caching.
*/
@@ -104,7 +105,7 @@
}
/**
- * Flag that disables compression when set; optional, default false
+ * Flag to disable compression when set. Defaults to false.
*
* @param nocompress True to disable compression.
*/
@@ -113,8 +114,8 @@
}
/**
- * Set the directory where soscmd(.exe) is located;
- * optional, soscmd must be on the path if omitted.
+ * The directory where soscmd(.exe) is located.
+ * soscmd must be on the path if omitted.
*
* @param dir The new sosCmd value
*/
@@ -123,16 +124,18 @@
}
/**
- * Set the SourceSafe username; required.
+ * The SourceSafe username.
*
* @param username The new username value
+ *
+ * @ant.attribute group=required
*/
public final void setUsername(String username) {
sosUsername = username;
}
/**
- * Set the SourceSafe password; optional.
+ * The SourceSafe password.
*
* @param password The new password value
*/
@@ -141,9 +144,11 @@
}
/**
- * Set the SourceSafe project path; required.
+ * The SourceSafe project path.
*
* @param projectpath The new projectpath value
+ *
+ * @ant.attribute group=required
*/
public final void setProjectPath(String projectpath) {
if (projectpath.startsWith(SOSCmd.PROJECT_PREFIX)) {
@@ -154,17 +159,18 @@
}
/**
- * Set the path to the location of the ss.ini file;
- * required.
+ * The path to the location of the ss.ini file.
*
* @param vssServerPath The new vssServerPath value
+ *
+ * @ant.attribute group=required
*/
public final void setVssServerPath(String vssServerPath) {
this.vssServerPath = vssServerPath;
}
/**
- * The path to the SourceOffSite home directory
+ * Path to the SourceOffSite home directory.
*
* @param sosHome The new sosHome value
*/
@@ -173,17 +179,19 @@
}
/**
- * Sets the address and port of SourceOffSite Server,
- * for example 192.168.0.1:.; required.
+ * The address and port of SourceOffSite Server,
+ * for example 192.168.0.1:.
*
* @param sosServerPath The new sosServerPath value
+ *
+ * @ant.attribute group=required
*/
public final void setSosServerPath(String sosServerPath) {
this.sosServerPath = sosServerPath;
}
/**
- * Override the working directory and get to the specified path;
optional.
+ * Override the working directory and get to the specified path.
*
* @param path The new localPath value
*/
@@ -192,7 +200,7 @@
}
/**
- * Enable verbose output; optional, default false
+ * Enable verbose output. Defaults to false.
*
* @param verbose True for verbose output.
*/
1.11 +7 -87
ant/src/main/org/apache/tools/ant/taskdefs/optional/sos/SOSCheckin.java
Index: SOSCheckin.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/taskdefs/optional/sos/SOSCheckin.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- SOSCheckin.java 18 Apr 2003 23:40:27 - 1.10
+++ SOSCheckin.java 25 Apr 2003 21:10:02 - 1.11
@@ -58,95 +58,16 @@
/**
* Commits and unlocks files in Visual SourceSafe via a SourceOffSite server.
*
- * p
- * The following
RE: polymorphism (was Re: antlib)
Wannheden, Knut wrote:
project
.. init properies .../
use xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/use
/project
Or even:
antelope:if xmlns:antelope=antlib:${ant-contrib.jar} /
In any case - if ComponentHelper is used, it'll get
antlib:/path/to/ant-contrib.jar as first param and if as the second param
- and any helper in the chain can create the task.
I don't like passing the .jar very much - but that's probably the only
way if we want to use META-INF/antlib.xml.
The alternative would be to use /net/sf/antcontrib/antlib.xml (i.e.
descriptor in a package ), and use antlib:net.sf.antcontrib as namespace.
Then getResource() can be used, and we don't have to worry about
multiple jars providing META-INF/antlib.xml - which forces us to use the
.jar file directly.
Costin
That is almost the same thing as I had in mind. Although I've been
thinking about some slight variations to this, where no top-level element
like use/
would be necessary. The Jelly style would be:
project xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
.. init properies .../
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
Here target/ is still toplevel and the antlibs are loaded on project
initialization (or on demand). But I'm not sure I like this automagical
loading. Something inbetween would be this:
project
.. init properies .../
use resource=${ant-contrib.jar} ns=antlib:ant-contrib/
use resource=${antelope.jar} ns=antlib:antelope/
target name=test xmlns:antcontrib=antlib:ant-contrib
xmlns:antelope=antlib:antelope
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
which is slightly more verbose, but cleaner IMO. Especially since the
antlib loading is explicit.
--
knut
RE: polymorphism (was Re: antlib)
No need for parsing! Don't know about ClassLoader#getResources??? --DD -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED] I don't like passing the .jar very much - but that's probably the only way if we want to use META-INF/antlib.xml. The alternative would be to use /net/sf/antcontrib/antlib.xml (i.e. descriptor in a package ), and use antlib:net.sf.antcontrib as namespace. Then getResource() can be used, and we don't have to worry about multiple jars providing META-INF/antlib.xml - which forces us to use the .jar file directly.
