jesse 2003/04/28 17:07:23
Added: proposal/xdocs/src/org/apache/tools/ant/taskdefs
Property.xml
Log:
Merge file for property
Revision ChangesPath
1.1
ant/proposal/xdocs/src/org/apache/tools/ant/taskdefs/Property.xml
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=19407.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
J.Pietschmann wrote:
Costin Manolache wrote:
There are working and valid systems ( Axis, Xslt ) that use the namespace
with associated meaning.
The expanded XML element/attribute names get a meaning through an
processing model, nobody denies this. The problems start if someone
associates
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=19415.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
peter reilly wrote:
True. It seems quite difficult to use namespaces in a nice way.
You are not supposed to use namespaces in a nice way.
XML Namespaces are there so that you can avoid name clashes
for XML element and attribute names if you want to use XML
vocabularies from various
First, I must say that it would be nice to have
context dependent element names - my core example
is the element name containsregexp - is this a condition,
filter or selector ? , the different meaning may mean
that different classes should implement them.
However, I think that expressing this in
Two points
1)
Using /org/apache/.../anlib.xml defeats the purpose of the antlib
proposal.
However it is in keeping with current ant practice.
it could be supported using
typedef definitionresource=/org/apache/commons/modeler/ant/antlib.xml
classpath path=${commons.modler/
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
Assume class C implements role intrefaces P, Q, and R then
typedef name=C1 classname=C/
typedef name=C2 classname=C/
will cause two definitions for P and Q each. There is no way to
assign different
On Tuesday 29 April 2003 10:46, Jose Alberto Fernandez wrote:
If you don't want if to be useable as a condition - don't make it
implement condition.
It sounds very nice, but the reality is that if already exists and has
existed for a long time. Hence we can not go and change it just because
Finally some body with sense :-)
From: Wannheden, Knut [mailto:[EMAIL PROTECTED]
The question I think is more important is whether antlibs
should be loaded
explicitly with something like an antlib/ task (similar to
taskdef/) or
if it should be more automagical like in Jelly where the
On Mon, 28 Apr 2003, peter reilly [EMAIL PROTECTED] wrote:
4. public void add(NestedElement anInner)
5. public void addConfigured(NestedElement anInner)
Make NestedElement a FileSet and explain how you'd support accepting
ClassFileset or ZipFileSet as either srcfiles or destfiles in
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.
On Mon, 28 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote:
If ParentClass has no addMyChild()/createMyChild() method, we'll
need to look up in some table and find a class associated with
myChild.
OK, well, maybe, see below for an alterbative view.
We'll then look in ParentClass for an
On Tuesday 29 April 2003 12:49, Stefan Bodewig wrote:
On Mon, 28 Apr 2003, peter reilly [EMAIL PROTECTED] wrote:
4. public void add(NestedElement anInner)
5. public void addConfigured(NestedElement anInner)
Make NestedElement a FileSet and explain how you'd support accepting
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=19386.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=19407.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tuesday 29 April 2003 13:12, Stefan Bodewig wrote:
I think the learning curve for beginners to grok
copy ...
classfileset .../
zipfileset .../
/copy
is steeper than the alternative
copy ...
fileset type=classfileset .../
fileset type=zipfileset .../
/copy
This is
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=19415.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On Tue, 29 Apr 2003, peter reilly [EMAIL PROTECTED] wrote:
This is debatable
I said I wasn't sure 8-)
I think we should allow both approaches.
The main difference between them is that in approach 1 the child
determines the name of the element while it is the parent who does so
in the second
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=19415.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
bodewig 2003/04/29 06:16:22
Modified:.WHATSNEW
src/main/org/apache/tools/ant/taskdefs/compilers
DefaultCompilerAdapter.java JavacExternal.java
Log:
From the JDK tool-docs for javac of JDK 1.4:
An argument file can include javac
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=10499.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Hi Stefan,
Let me start by saying that the roles proposal had not in mind
solving the polimorphism issue (which I think is what is at the bottom
of your points here). I have no problem on arriving to a solution that
covers this aspect, but I do not want it to be the stumbling block
on the whole
Stefan Bodewig wrote:
On Mon, 28 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote:
If ParentClass has no addMyChild()/createMyChild() method, we'll
need to look up in some table and find a class associated with
myChild.
OK, well, maybe, see below for an alterbative view.
We'll then
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=19386.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Jose Alberto Fernandez wrote, On 29/04/2003 12.03:
...
The proposal antlib provides a task antlib which can be used to
load libraries manually. Al the same time there are hooks on the code
for an autoloading mechanism to be supported. In escence, it would
allow ANT's main() to do something like:
On Tue, 29 Apr 2003, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
This continues with the two-tier issue, the core conditions of ANT
you can just named, but the third party ones need to use some funny
syntax.
core conditions would use the same funny syntax, if it wasn't for
backwards
Hi All,
I have found an interesting problem when one is defining their own task
and this
task is being defined within multiple build.xml files. The problem
happens when
you do the following.
1 - define a task using the taskdef within a top level build file and
supply a
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=19407.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Nicola Ken Barozzi wrote:
...
The proposal antlib provides a task antlib which can be used to
load libraries manually. Al the same time there are hooks on the code
for an autoloading mechanism to be supported. In escence, it would
allow ANT's main() to do something like:
- get all
On Tuesday 29 April 2003 16:50, Stefan Bodewig wrote:
On Tue, 29 Apr 2003, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
This continues with the two-tier issue, the core conditions of ANT
you can just named, but the third party ones need to use some funny
syntax.
core conditions would
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=19432.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=19436.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
ehatcher2003/04/29 12:21:25
ant/proposal/xdocs/metadata - New directory
ehatcher2003/04/29 12:32:31
ant/proposal/xdocs/src/org/apache/ant - New directory
ehatcher2003/04/29 12:32:48
ant/proposal/xdocs/src/org/apache/ant/xdoclet - New directory
ehatcher2003/04/29 12:33:21
ant/proposal/xdocs/src/org/apache/ant/xdoclet/resources - New directory
ehatcher2003/04/29 12:42:00
Modified:proposal/xdocs build.xml
Added: proposal/xdocs/metadata xdoclet.xml
proposal/xdocs/src/org/apache/ant/xdoclet AntDocletTask.java
AntSubTask.java IndexGen.java
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=19437.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
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=19438.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Stefan,
On Tuesday, April 29, 2003, at 03:42 PM, [EMAIL PROTECTED] wrote:
+ target name=gen depends=jar
taskdef name=antdoclet
- classname=xdoclet.modules.apache.ant.AntDocletTask
- classpathref=xdoclet.classpath/
+
On Tue, 2003-04-29 at 15:42, [EMAIL PROTECTED] wrote:
migrated Ant XDoclet code here, to maintain it easier
Cool, everything seems to be working after the move.
Aslak just committed a fix for XJavaDoc so EnumeratedAttributes are
being resolved correctly. XJavaDoc still has problems
On Tue, 2003-04-29 at 16:56, Erik Hatcher wrote:
Hmmm... didn't realize EnumeratedAttributes were an issue. The
IntrospectionHelper stuff was dealing with it fine - what was going
wrong?
The IntrospectionHelper stuff was working as designed when it had all
the required info, but
jesse 2003/04/29 15:36:19
Modified:proposal/xdocs/src/org/apache/ant/xdoclet AntSubTask.java
proposal/xdocs/lib xdoclet-1.2b3-dev.jar
xdoclet-ejb-module-1.2b3-dev.jar
xdoclet-web-module-1.2b3-dev.jar
44 matches
Mail list logo
