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.
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.
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.
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.
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.
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.
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
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
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
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.
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
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
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}/
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
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
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
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
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
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.
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
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!
-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
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
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
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
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
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
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
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:
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
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
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.
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
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:
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.
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
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
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
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.
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
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.
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.
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
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.
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.
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
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
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
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
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
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/
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
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.
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
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
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
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 ...
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
58 matches
Mail list logo
