Re: Antlib test classpath
On Sat, Feb 5, 2022, 1:19 AM Stefan Bodewig wrote: > On 2022-02-04, Matt Benson wrote: > > > I am working on a new antlib (discussed a couple of years ago on list), > and > > trying to figure out how to get antunit to run tests using Ivy's created > > classpath.test from the common build framework. I have tried combinations > > of the (hidden) classloader task with antunit references, etc., so far to > > no avail. Does anyone (Stefan?) have any basic suggestions I can try? > > I must admit that I never tried to use things with Ivy at all. When I > run tests I do so with several -lib arguments (and always need to figure > out what is required as I don't do it often enough). > > If you figured things out it would probably be a good idea to update the > common build structure as needed. > > > > > Well > The changes I have made today to Ant core and Antunit will allow us, after the next release of each, to boilerplate the classpath setup for running Antunit tests in antlibs using [future modifications to] the common build structure. Matt Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: Antlib test classpath
On Sat, 5 Feb 2022 at 08:19, Stefan Bodewig wrote: > I must admit that I never tried to use things with Ivy at all. When I > run tests I do so with several -lib arguments (and always need to figure > out what is required as I don't do it often enough). > > If you figured things out it would probably be a good idea to update the > common build structure as needed. > The basic structure for using Ivy with different tasks is set in Ant's check.xml Watch out for Ant plugins that forget to put ant dependency in optional (aka "compile only") scope when using POMs, though. Gintas
Re: Antlib test classpath
On 2022-02-04, Matt Benson wrote: > I am working on a new antlib (discussed a couple of years ago on list), and > trying to figure out how to get antunit to run tests using Ivy's created > classpath.test from the common build framework. I have tried combinations > of the (hidden) classloader task with antunit references, etc., so far to > no avail. Does anyone (Stefan?) have any basic suggestions I can try? I must admit that I never tried to use things with Ivy at all. When I run tests I do so with several -lib arguments (and always need to figure out what is required as I don't do it often enough). If you figured things out it would probably be a good idea to update the common build structure as needed. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Antlib test classpath
Looks like I got it sorted by passing a path reference to Antunit and executing typedef there. Matt On Fri, Feb 4, 2022, 12:07 PM Matt Benson wrote: > I am working on a new antlib (discussed a couple of years ago on list), > and trying to figure out how to get antunit to run tests using Ivy's > created classpath.test from the common build framework. I have tried > combinations of the (hidden) classloader task with antunit references, > etc., so far to no avail. Does anyone (Stefan?) have any basic suggestions > I can try? > > Matt >
Re: Antlib SVN and antunit Java versions
On 19/12/18 11:29 PM, Stefan Bodewig wrote: > On 2018-12-18, Jaikiran Pai wrote: > >> One option in similar cases that we have employed in other jobs is to >> configure the Java system property -Dhttps.protocols to "TLSv1.2". But >> this version of TLS is only supported in a Java release after Java 1.5. > I'd be in favor of updating the jobs. Nobody would build releases using > Java 1.5 either, I guess. Done. I have updated the jobs of antlib svn and antunit to use Java 8 to build it. > >> At a more higher level, I think it's probably time to decide whether we >> want to change the minimum required Java versions for these libraries? >> Should we now mandate Java 1.8 at least? > In the case of antlib svn we could simply decide to call it dead or > dormant or whatever (like almost all other antlibs, I guess). Unless I'm > overlooking something, the svn antlib is neither listed on > http://ant.apache.org/antlibs/proper.html nor > http://ant.apache.org/antlibs/sandbox.html - so it doesn't even exist > from out user's point of view. I found this (live) page http://ant.apache.org/antlibs/svn/ the other day while looking at the Jenkins failure. But now that you mention it, I don't remember how I landed up on that page. I don't see it linked in the Jenkins job or some other place. But yes, I don't see it linked anywhere in the Ant website. I'll start a new VOTE thread to retire this project. I might need Jan's help here if/after the VOTE passes to actually do some of the process involved in retiring projects. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Antlib SVN and antunit Java versions
On 2018-12-18, Jaikiran Pai wrote: > One option in similar cases that we have employed in other jobs is to > configure the Java system property -Dhttps.protocols to "TLSv1.2". But > this version of TLS is only supported in a Java release after Java 1.5. I'd be in favor of updating the jobs. Nobody would build releases using Java 1.5 either, I guess. > At a more higher level, I think it's probably time to decide whether we > want to change the minimum required Java versions for these libraries? > Should we now mandate Java 1.8 at least? In the case of antlib svn we could simply decide to call it dead or dormant or whatever (like almost all other antlibs, I guess). Unless I'm overlooking something, the svn antlib is neither listed on http://ant.apache.org/antlibs/proper.html nor http://ant.apache.org/antlibs/sandbox.html - so it doesn't even exist from out user's point of view. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Antlib SVN and antunit Java versions
On Tue, 18 Dec 2018 at 10:44, Dominique Devienne wrote: > On Tue, Dec 18, 2018 at 9:21 AM Jaikiran Pai wrote: > > > [...] 2 jobs[1][2] which are for Antlib SVN and Antunit libraries. > > Both these jobs are configure for JDK 5 [...] > > However, the Maven central repo [...[ has been configured not to let > > clients with > > lower TLS versions (lesser than TLSv1.2) to communicate with it. [...] > > But this version of TLS is only supported in a Java release after Java 1.5. > > [...] > > Should we now mandate Java 1.8 at least? > > > > Sounds completely reasonable to me. Thanks for the clear message. +1. --DD > I'd say the choices are: - use Java 6 or 7 with command line switch forcing TLSv1.2 or Java 8 and crosscompile to Java 5 - change to Java 8 to follow Ant 1.10 Java 9+ can only crosscompile to Java 6+. It will be interesting to see if JEP 332 [1] gets backported... Gintas [1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8202625
Re: Antlib SVN and antunit Java versions
On Tue, Dec 18, 2018 at 9:21 AM Jaikiran Pai wrote: > [...] 2 jobs[1][2] which are for Antlib SVN and Antunit libraries. Both these jobs are configure for JDK 5 [...] > However, the Maven central repo [...[ has been configured not to let > clients with > lower TLS versions (lesser than TLSv1.2) to communicate with it. [...] But this version of TLS is only supported in a Java release after Java 1.5. > [...] Should we now mandate Java 1.8 at least? > Sounds completely reasonable to me. Thanks for the clear message. +1. --DD
Re: AntLib compress
On 2010-03-31, jan.mate...@rzf.fin-nrw.de wrote: I found that the Antlib compress requires commons-compress in version 1.1. But where to that that? Build it yourself, sorry I don't have any better idea. I dont want to build all the transitive dependencies :-O There shouldn't be any. Commons Compress has no dependencies at all, everything that gets downloaded when building Commons Compress (i.e. three versions of Ant among other things) is only due to the Maven plugins used by Commons. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AntLib compress
On 2010-03-28, Jan Matèrne j...@materne.de wrote: I found that the Antlib compress requires commons-compress in version 1.1. Right - and Christian vounteered to release that, so I decided to make the Antlib's trunk depend on it. The plan is to release the Antlib ASAP once commons-compress 1.1 is out. But where to that that? Build it yourself, sorry I don't have any better idea. Well, or use this http://people.apache.org/~bodewig/commons-compress-1.1-SNAPSHOT.jar 8-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
RE: AntLib compress
I found that the Antlib compress requires commons-compress in version 1.1. But where to that that? The last release was 1.0 and it is not built in Hudson or Continuum. And I cant access the created JAR in Gump /srv/gump/public/workspace/apache-commons/compress/target/commons-compress-1 .1-SNAPSHOT.jar Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: antlib namespace and uri usage
This is in the ant manual.
http://ant.apache.org/manual/CoreTypes/antlib.html#currentnamespace
There is a special xml namespace (ant:current) for typedefs defined
within an antlib.
The namespace is only active during the processing of the antlib.
Peter
On Thu, Apr 23, 2009 at 7:53 AM, Gilles Scokart gscok...@gmail.com wrote:
Yesterday I lost 1 hour to fix an antlib namespace issue. I have no found
how to fix it, but I still don't clearly understand what is actually wrong
(=what error message should ant report).
I have an antlib defined in an XML file like this :
antlib xmlns:deco=antlib:net.sourceforge.deco.ant
taskdef name=analyze
classname=net.sourceforge.deco.ant.Analyze
/
/antlib
And I have my project was using it like this :
project name=build_base xmlns:deco=net.sourceforge.deco.ant
typedef resource=net/sourceforge/deco/ant/antlib.xml
uri=net.sourceforge.deco.ant
classpath
fileset dir=${build.script.dir}/lib/
include name=deco*.jar/
/fileset
pathelement
location=${build.script.dir}/lib/asm-3.1.jar /
/classpath
/typedef
/project
This was working fine, and I could use deco:analyse task in my build.
But then I added a presetdef in my anlib that refined analyze like this
(simplified version):
antlib xmlns:deco=antlib:net.sourceforge.deco.ant
taskdef name=analyze
classname=net.sourceforge.deco.ant.Analyze
/
presetdef name=check-compile
deco:analyze type=COMPILE
deco:check-compile-report/
/deco:analyze
/presetdef
/antlib
This was failing because deco:analyze was not found when presetdef
executed.
I tried unsuccesfully to change the usage of the namespace in different way,
then I plugged a debugger and I found that the analyze task did exist, but
with the name net.sourceforge.deco.ant:analyze while
antlib:net.sourceforge.deco.ant:analyze was searched.
The fix was to change the uri used in my build from net.sourceforge.deco.ant
to antlib:net.sourceforge.deco.ant.
But what is exactly wrong?
Was my initial declaration wrong? Should it be mandatory to use exactly the
same URI in the typedef loading the antlib than in the antlib declaration
For the moment it is not mandatory, If you don't do, you may not notice that
you don't do. But you might have the issue I had. In that case, we should
at least have a warning (failing would break backward compatibility).
Or are was it the intention to let the user of an antlib freely choose its
uri? I doubt. But if it is, how can I reference my own tasks into the
antlib.xml file ?
Gilles Scokart
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: antlib attributes - WAS: [VOTE] Release Apache .NET Antlib 1.0 final
On 10/31/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: 1) the antlib.xml does not set the onerror attribute, this means that all the definitions will be loaded when one is loaded, using onerror=ignore should be used. (ignore is a bit of a misnomer - it should be deferred, i.e. the check will be made when the task is first used). Where is this documented? Good point! It is not documented. taskdef name=mytask classname=this.does.not.exist onerror=ignore will be accepted ok. However when used, mytask/ one gets the message: C:\Documents and Settings\reilly\learning\a\typedef\build.xml:6: Problem: failed to create task or type mytask Cause: the class this.does.not.exist was not found. Action: Check that the component has been correctly declared . The idea of using the value ignore in an antlib is to defer creating the types/tasks until they are used by the build script - this emulates the built-in tasks/types of ant and allows thirdparty antlibs to have optional types/tasks Peter Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib alias?
You can declare multiple taskdefs all pointing to the same impl. class, or you can declare it once then use presetdef (I think). Jeffrey E. (Jeff) Care [EMAIL PROTECTED] IBM WebSphere Application Server Development WAS Pyxis Lead Release Engineer Kev Jackson [EMAIL PROTECTED] 05/03/2006 02:50 AM Please respond to Ant Developers List dev@ant.apache.org To Ant Developers List dev@ant.apache.org cc Subject Antlib alias? Hi, I've been messing with some code today, and looking at antlibs, a typical declaration may be something like: antlib taskdef name=my_task classname=org.apache.ant.my_task.Task1 / ... /antlib I was wondering if there would be any usefulness in adding an 'alias' attribute, which could take a list of aliases. This would allow an antlib to have an official name for a task, whilst still allowing the use of abbreviations (which is fairly common in unix land (--verbose/-v etc)). antlib taskdef name=my_task alias=t, task, task1 classname=org.apache.ant.my_task.Task1 / ... /antlib Any thoughts? Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib autoloading
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Mon, 12 Sep 2005, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: 1) How about collisions? Well, how about collisions between classes in the classpath? Putting antlibs into namespaces was supposed to resolve those collisions, just like namesspaces in C++. And no one is saying that should not continue to be the case, but if I want to load something in the default name space, it is up to me to take the risk. How about loading a task that collides with one already defined in defaults.properties? What do we do in this case? Shall we react the same way? Sure, this (complain loudly) is what we're doing with multiple typedefs for the same name as well. it may just be annoying, so annoaying that people will avoid autoloading. I do not buy too much this argument. If am extending my ANT-CORE with some 3rd party tasks is because that library does not collide with regular ANT tasks. This is the case of all the optional antlibs that we provide. And it may be the case of some specialized ant-libraries specific to some corporation. It is their job and their risk to try to cohabitate with the ANT tasks. Otherwise, they should use and declare name-spaces in their project files. 2) Shall we keep control on what gets aoutoloaded? I would say yes! Good 8-) I disagree on having some global switch (option) instead I would propose something like -lib (no autoloading) and -autolib (do autoloading). But you'd use the same classloader for both, right? Otherwise explaining Ant's classloaders becomes even more complex. Well, this is just engineering ;-) There is a way to know where a resource is coming from. We just need to examine what we allow in and what we don't. 3) Have an antlib.xml in META-INF for autoloading. My only misgiving on doing it this way is the duplication of declarations. Matt's example of using different names for autoloads (that end up in the default namespace) and namespaced tasks would show an example of when you want to have separate files. This may be a bit artificial, though. This to me is the worst that we can do to ANT. How are people going to understand that is you use auto-loading the tasks of some library have some name, but if you do not, then they have some completely different names, oh and by the way you ALSO need to define a name space for them. Is there any other way to make things more confusing for people trying to use reusable code? I doubt it. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
Stefan Bodewig wrote: On Mon, 12 Sep 2005, Steve Loughran [EMAIL PROTECTED] wrote: I hadnt thought about autoloading; I am happy with explicit loading of stuff into their own namespaces, but want to make it easier for projects to get access to my definitions (or even importable libraries) How do you like this xmlns:foo=antlib:file:///some/absolute/file.name xmlns:foo=antlib:file:some/relative/file.name yes, both interesting xmlns:foo=antlib:http://example.org/2005/yes#I_can_use_a_catalog_resolver; this scaers me, as people will assume that we are doing a download... xmlns:foo=antlib:resource:/org/apache/ant/antunit/antlib.xml yes, this I like. I also like DD's idea of letting me import something on the classpath. Something like import resource=projects/something/core.xml classpathref=app.path / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib autoloading
--- Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Mon, 12 Sep 2005, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: 1) How about collisions? Well, how about collisions between classes in the classpath? Putting antlibs into namespaces was supposed to resolve those collisions, just like namesspaces in C++. And no one is saying that should not continue to be the case, but if I want to load something in the default name space, it is up to me to take the risk. How about loading a task that collides with one already defined in defaults.properties? What do we do in this case? Shall we react the same way? Sure, this (complain loudly) is what we're doing with multiple typedefs for the same name as well. it may just be annoying, so annoaying that people will avoid autoloading. I do not buy too much this argument. If am extending my ANT-CORE with some 3rd party tasks is because that library does not collide with regular ANT tasks. This is the case of all the optional antlibs that we provide. And it may be the case of some specialized ant-libraries specific to some corporation. It is their job and their risk to try to cohabitate with the ANT tasks. Otherwise, they should use and declare name-spaces in their project files. [SNIP] 3) Have an antlib.xml in META-INF for autoloading. My only misgiving on doing it this way is the duplication of declarations. Matt's example of using different names for autoloads (that end up in the default namespace) and namespaced tasks would show an example of when you want to have separate files. This may be a bit artificial, though. This to me is the worst that we can do to ANT. How are people going to understand that is you use auto-loading the tasks of some library have some name, but if you do not, then they have some completely different names, oh and by the way you ALSO need to define a name space for them. Is there any other way to make things more confusing for people trying to use reusable code? I doubt it. :) Jose Alberto, it seems that you and I have each contradicted ourselves during this discussion. On issue (1) above, regarding collisions, your approach is to assume the user knows exactly what he/she is doing: e.g. the name of every task provided with every third-party distribution used. My thinking was the opposite: a user might add things to Ant's classpath that conflict and would need to be informed when collisions take place. THEN, on issue (3) above, your thinking seems to be the opposite: we cannot trust that the user understands the difference between global and other namespaces, etc., in Ant, while the multiple antlib.xml approach I [shall we say suggested but did not necessarily advocate] seems to come from the perspective that the user can be given choices, from which we can infer that he/she would know what they are doing. If we can satisfy both cases, so much the better, but if not surely we must all see that we should err on the side of caution (assume the user does NOT know everything)? -Matt Please note that no slight to current or future Ant users is intended here. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
Matt Benson wrote: :) Jose Alberto, it seems that you and I have each contradicted ourselves during this discussion. On issue (1) above, regarding collisions, your approach is to assume the user knows exactly what he/she is doing: e.g. the name of every task provided with every third-party distribution used. My thinking was the opposite: a user might add things to Ant's classpath that conflict and would need to be informed when collisions take place. THEN, on issue (3) above, your thinking seems to be the opposite: we cannot trust that the user understands the difference between global and other namespaces, etc., in Ant, while the multiple antlib.xml approach I [shall we say suggested but did not necessarily advocate] seems to come from the perspective that the user can be given choices, from which we can infer that he/she would know what they are doing. If we can satisfy both cases, so much the better, but if not surely we must all see that we should err on the side of caution (assume the user does NOT know everything)? I would assume that tools like websphere or the IDE are happily sticking stuff in on the classpath, and that anything more we can do for diagnostics helps 1. something to examine a task: where it comes from, whether it can be instantiated etc ant -diagnostics -task wsdl2java -namespace http://apache.org 2. something to examine a namespace ant -diagnostics -namespace antlib:org.example.p1 3. something to catch when a task exists but the namespace is wrong. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib autoloading
From: Matt Benson [mailto:[EMAIL PROTECTED] --- Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Mon, 12 Sep 2005, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: 1) How about collisions? Well, how about collisions between classes in the classpath? Putting antlibs into namespaces was supposed to resolve those collisions, just like namesspaces in C++. And no one is saying that should not continue to be the case, but if I want to load something in the default name space, it is up to me to take the risk. How about loading a task that collides with one already defined in defaults.properties? What do we do in this case? Shall we react the same way? Sure, this (complain loudly) is what we're doing with multiple typedefs for the same name as well. it may just be annoying, so annoaying that people will avoid autoloading. I do not buy too much this argument. If am extending my ANT-CORE with some 3rd party tasks is because that library does not collide with regular ANT tasks. This is the case of all the optional antlibs that we provide. And it may be the case of some specialized ant-libraries specific to some corporation. It is their job and their risk to try to cohabitate with the ANT tasks. Otherwise, they should use and declare name-spaces in their project files. [SNIP] 3) Have an antlib.xml in META-INF for autoloading. My only misgiving on doing it this way is the duplication of declarations. Matt's example of using different names for autoloads (that end up in the default namespace) and namespaced tasks would show an example of when you want to have separate files. This may be a bit artificial, though. This to me is the worst that we can do to ANT. How are people going to understand that is you use auto-loading the tasks of some library have some name, but if you do not, then they have some completely different names, oh and by the way you ALSO need to define a name space for them. Is there any other way to make things more confusing for people trying to use reusable code? I doubt it. :) Jose Alberto, it seems that you and I have each contradicted ourselves during this discussion. On issue (1) above, regarding collisions, your approach is to assume the user knows exactly what he/she is doing: e.g. the name of every task provided with every third-party distribution used. My thinking was the opposite: a user might add things to Ant's classpath that conflict and would need to be informed when collisions take place. THEN, on issue (3) above, your thinking seems to be the opposite: we cannot trust that the user understands the difference between global and other namespaces, etc., in Ant, while the multiple antlib.xml approach I [shall we say suggested but did not necessarily advocate] seems to come from the perspective that the user can be given choices, from which we can infer that he/she would know what they are doing. Matt, I guess I should go back to my original starting point. I do not advocate that users put all their third party libraries inside the core name-space. I advocate using this mechanism, principally, for our own optional tasks, but also allowing some ANT installations to decide if some few specific libraries should be treated the same way, because of backward compatibility or something. My main issue is that our optional libraries should not have any more rights to live in core than anyone else's. We just guarantee they will not introduce some collision with core. As per (3) my point is that it sounds unreasonable to provide some facility that allows the same tasks to be known by different names. It would mean that every task will have to be explain twice or people will use sometimes one name and others other, without any real advantage but to be confusing for everyone involved. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
On Tue, 13 Sep 2005, Matt Benson [EMAIL PROTECTED] wrote: :) Jose Alberto, it seems that you and I have each contradicted ourselves during this discussion. Me too. On issue (1) above, regarding collisions, I think Steve's argument about IDEs putting stuff into the CLASSPATH is an important one as well. It may make a -antlib switch for Ant users in IDEs difficult to do. And it may add tasks to the default namespace that users never wanted to see there if we enabled autoloading by default. So it is a good case against autoloading by default. And a good case where the user doesn't always know what she is doing. If we can satisfy both cases, so much the better, but if not surely we must all see that we should err on the side of caution (assume the user does NOT know everything)? Note that with -antlib the user is in control and explicitly says which antlibs to load into the default namespace, so we could assume more knowledge. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
On Tue, 13 Sep 2005, Steve Loughran [EMAIL PROTECTED] wrote: I would assume that tools like websphere or the IDE are happily sticking stuff in on the classpath, and that anything more we can do for diagnostics helps Sounds good. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
On Tue, 13 Sep 2005, Steve Loughran [EMAIL PROTECTED] wrote: xmlns:foo=antlib:http://example.org/2005/yes#I_can_use_a_catalog_resolver; this scaers me, as people will assume that we are doing a download... Of the descriptor. Why not? OK, they might expect we download the lib itself as well. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
Jeffrey E Care wrote:
I don't normally speak up on the developer list, but I thought this
discussion could benefit from the experience of a *very large* product
that uses Ant to build.
We use Ant + our own extensions (Mantis) to build WebSphere Application
Server (and a good number of the stack products as well). The Mantis
extensions allow for build modularization both on a fine-grain (called
component) and a coarse-grain (called functional element) scale;
Mantis also has tasks that manage the dependencies between these modular
units, for purposes of constructing classpaths, scheduling build order,
etc.
Given that our build is modular, as you might expect we have many hundreds
of individual build.xml files in WAS. With that many files it's difficult
to ensure that everyone is declaring typedefs correctly, so prior to our
adopting Ant 1.6 we were modifying an Ant 1.5.4 distribution to always
include the Mantis tasks in oata.tasks.defaults.properties; it was just
easier for our users that way. Now that we're on an Ant 1.6.5 base we're
using namespaces + antlibs to make the Mantis tasks available, which IMO
is better than doing a typedef, but on a large scale it's still difficult
to ensure that everyone is doing the right thing.
So, with all of that in mind, I really do like the suggestion of
autoloading type task definitions from META-INF/antlib.xml; I also
understand Dominique's concerns about transparency staying in control.
Perhaps this behavior could be controlled with a command-line switch, say
-autoload or something along those lines, such that the default behavior
would be as it is today (i.e. no autoloading), but by specifying the
switch Ant could search its classpath to discover the antlibs. This would
also yield a nontrivial performance enhancement, as currently each of our
modules is effectively reloading our antlib, whereas I would think that
autoloading would be done once (when Ant is bootstrapped).
This sounds like the largest Ant build project I've heard of, excluding
Gump itself, which is so loosely coupled it doesnt really count. We
have, what, 30 build files in ours and I am still struggling to deal
with refactoring it to be more effective. The big problem I have in mine
is that with a single ${root.dir}/common.xml containing most stuff, it
is inordinately brittle. So I am breaking it into separate build files
with lots of cross imports, mandatory namespace declarations for all
tasks, presets, etc.
My project rework proposal is here:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/smartfrog/core/antbuild/doc/third_generation_build_process.sxw
for anyone who wants to view and comment.
I hadnt thought about autoloading; I am happy with explicit loading of
stuff into their own namespaces, but want to make it easier for projects
to get access to my definitions (or even importable libraries)
-steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
Well, I am glad this is having a strong debate. Let me first say where I am coming from with this issue and then some of my thoughts on this and others comments. My main peeve currently is defaults.properties. To me it is an aberration now that we have antlibs. This file tries to load a whole load of tasks that at the end will not work because people do not have the supporting optional stuff. And it does not load the things that I do have. I want this done by the antlib mechanism itself which is already there. Now, to some of the comments: 1) How about collisions? Well, how about collisions between classes in the classpath? Is this really much different? Maybe, maybe not. How about loading a task that collides with one already defined in defaults.properties? What do we do in this case? Shall we react the same way? 2) Shall we keep control on what gets aoutoloaded? I would say yes! I disagree on having some global switch (option) instead I would propose something like -lib (no autoloading) and -autolib (do autoloading). With this in mind the things in the ANT distribution library will be loaded using the -autoload option and for other external libraries people can decide what should happen. 3) Have an antlib.xml in META-INF for autoloading. My only misgiving on doing it this way is the duplication of declarations. I do not like duplication. I would prefer providing something that just points to the package where the antlib.xml will be loaded when using name-spaces. So there is only one maintenance point. We could just use the java services mechanism or something very similar: We have a file META_INF/services/org.apache.ant.autoload (or something like that) that contains the packages where to look for antlib.xml files to load. That will make things reasonably simple, and all integrated. Comments, Jose Alberto -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: 09 September 2005 22:57 To: Ant Developers List Subject: Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java) On 9/9/05, Stefan Bodewig [EMAIL PROTECTED] wrote: So, any ideas how this could be acomplished? Load all resources from META-INF/antlib.xml at startup and process them, I'd say. But doesn't that go against Ant's tradition to not have auto-magic things, but instead spell things out explicitly, usually in the build file? I'd rather we extend typedef to accept a fileset of AntLib jars to load, possibly thru META-INF/antlib.xml, than auto-magically loading all possible antlibs visible from the classpath. At least you can see it and start looking at the jars it loads. How would you know looking at a build file where a task is coming from otherwise? Also, for example, I have quite a few AntLibs which are in ant/lib, and thus on Ant's classpath, but I don't use all of them in all my builds. They're there because it's our official supercharged production Ant distro, but loading all of them in builds that require none or just a few is wasteful. I personnally want to stay in control of what gets loaded in each build. I don't want to prevent others to do it if they fancy it, as long as it's not forced on me. --DD PS: And BTW, Matt's point about conflict resolution is a good one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
On Mon, 12 Sep 2005, Steve Loughran [EMAIL PROTECTED] wrote: I hadnt thought about autoloading; I am happy with explicit loading of stuff into their own namespaces, but want to make it easier for projects to get access to my definitions (or even importable libraries) How do you like this xmlns:foo=antlib:file:///some/absolute/file.name xmlns:foo=antlib:file:some/relative/file.name xmlns:foo=antlib:http://example.org/2005/yes#I_can_use_a_catalog_resolver; xmlns:foo=antlib:resource:/org/apache/ant/antunit/antlib.xml the last one being the verbise version of xmlns:foo=antlib:org.apache.ant.antunit Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
On Mon, 12 Sep 2005, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: 1) How about collisions? Well, how about collisions between classes in the classpath? Putting antlibs into namespaces was supposed to resolve those collisions, just like namesspaces in C++. How about loading a task that collides with one already defined in defaults.properties? What do we do in this case? Shall we react the same way? Sure, this (complain loudly) is what we're doing with multiple typedefs for the same name as well. it may just be annoying, so annoaying that people will avoid autoloading. 2) Shall we keep control on what gets aoutoloaded? I would say yes! Good 8-) I disagree on having some global switch (option) instead I would propose something like -lib (no autoloading) and -autolib (do autoloading). But you'd use the same classloader for both, right? Otherwise explaining Ant's classloaders becomes even more complex. 3) Have an antlib.xml in META-INF for autoloading. My only misgiving on doing it this way is the duplication of declarations. Matt's example of using different names for autoloads (that end up in the default namespace) and namespaced tasks would show an example of when you want to have separate files. This may be a bit artificial, though. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
I don't normally speak up on the developer list, but I thought this discussion could benefit from the experience of a *very large* product that uses Ant to build. We use Ant + our own extensions (Mantis) to build WebSphere Application Server (and a good number of the stack products as well). The Mantis extensions allow for build modularization both on a fine-grain (called component) and a coarse-grain (called functional element) scale; Mantis also has tasks that manage the dependencies between these modular units, for purposes of constructing classpaths, scheduling build order, etc. Given that our build is modular, as you might expect we have many hundreds of individual build.xml files in WAS. With that many files it's difficult to ensure that everyone is declaring typedefs correctly, so prior to our adopting Ant 1.6 we were modifying an Ant 1.5.4 distribution to always include the Mantis tasks in oata.tasks.defaults.properties; it was just easier for our users that way. Now that we're on an Ant 1.6.5 base we're using namespaces + antlibs to make the Mantis tasks available, which IMO is better than doing a typedef, but on a large scale it's still difficult to ensure that everyone is doing the right thing. So, with all of that in mind, I really do like the suggestion of autoloading type task definitions from META-INF/antlib.xml; I also understand Dominique's concerns about transparency staying in control. Perhaps this behavior could be controlled with a command-line switch, say -autoload or something along those lines, such that the default behavior would be as it is today (i.e. no autoloading), but by specifying the switch Ant could search its classpath to discover the antlibs. This would also yield a nontrivial performance enhancement, as currently each of our modules is effectively reloading our antlib, whereas I would think that autoloading would be done once (when Ant is bootstrapped). Just my $0.02. JEC -- Jeffrey E. Care ([EMAIL PROTECTED]) WebSphere v7 Release Engineer WebSphere Build Tooling Lead (Project Mantis) Dominique Devienne [EMAIL PROTECTED] wrote on 09/09/2005 05:57:07 PM: On 9/9/05, Stefan Bodewig [EMAIL PROTECTED] wrote: So, any ideas how this could be acomplished? Load all resources from META-INF/antlib.xml at startup and process them, I'd say. But doesn't that go against Ant's tradition to not have auto-magic things, but instead spell things out explicitly, usually in the build file? I'd rather we extend typedef to accept a fileset of AntLib jars to load, possibly thru META-INF/antlib.xml, than auto-magically loading all possible antlibs visible from the classpath. At least you can see it and start looking at the jars it loads. How would you know looking at a build file where a task is coming from otherwise? Also, for example, I have quite a few AntLibs which are in ant/lib, and thus on Ant's classpath, but I don't use all of them in all my builds. They're there because it's our official supercharged production Ant distro, but loading all of them in builds that require none or just a few is wasteful. I personnally want to stay in control of what gets loaded in each build. I don't want to prevent others to do it if they fancy it, as long as it's not forced on me. --DD PS: And BTW, Matt's point about conflict resolution is a good one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
On Fri, 9 Sep 2005, Dominique Devienne [EMAIL PROTECTED] wrote: On 9/9/05, Stefan Bodewig [EMAIL PROTECTED] wrote: So, any ideas how this could be acomplished? Load all resources from META-INF/antlib.xml at startup and process them, I'd say. But doesn't that go against Ant's tradition to not have auto-magic things, but instead spell things out explicitly, usually in the build file? Yes, probably. Even though there is a lot of explicitly invocable magic that is not visible in the build file either (build.sysclasspath for example). I'd rather we extend typedef to accept a fileset of AntLib jars to load, possibly thru META-INF/antlib.xml, than auto-magically loading all possible antlibs visible from the classpath. At least you can see it and start looking at the jars it loads. You can't look at the jars loaded by xmlns:au=antlib:org.apache.ant.antunit either. How would you know looking at a build file where a task is coming from otherwise? How do you know with a namespace declaration? Also, for example, I have quite a few AntLibs which are in ant/lib, and thus on Ant's classpath, but I don't use all of them in all my builds. They're there because it's our official supercharged production Ant distro, but loading all of them in builds that require none or just a few is wasteful. Completely agreed, that's why not enabling autoloading by default is a good idea. I personally don't want to autoload all antlibs, in oarticular not all into the default namespace, myself either. I just commented on how it could be done 8-) PS: And BTW, Matt's point about conflict resolution is a good one. Yes. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib loading in typedef
On Tue, 23 Aug 2005, Steve Loughran [EMAIL PROTECTED] wrote: One change I have also checked in to Definer.java is some extra logic for naming antlibs. Instead of just antlib:org.example.package you can go antlib://org/example/package/file.xml I don't like that antlib would now become a protocol for opaque and hierarchical URLs at the same time. Is antlib:foo loading the descriptor from resource /foo/antlib.xml or resource foo. antlib://org.example.package/file.xml antlib:org.example.package/file.xml antlib://org.example.package/antlib.xml how would the second form load a resource that's not in a package? Other than that I like that one most. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
--- Stefan Bodewig [EMAIL PROTECTED] wrote: On Fri, 26 Aug 2005, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Now, for backward compatibility and for convinience in general, one would like to be able to put in the -lib directories a bunch of antlib jars and that all their tasks get declared automatically as part of the default name space. Steve's approach would allow you to load them into different namespaces. I don't see that much benefit over typedef resource=.../ in his case, though. So, any ideas how this could be acomplished? Load all resources from META-INF/antlib.xml at startup and process them, I'd say. Sounds cool, but what do you do about e.g. collisions among tasknames from 3rd-party distributions? What is the user's recourse, turn off the warning and manually typedef (both)? -Matt Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
On Fri, 9 Sep 2005, Matt Benson [EMAIL PROTECTED] wrote: Load all resources from META-INF/antlib.xml at startup and process them, I'd say. Sounds cool, but what do you do about e.g. collisions among tasknames from 3rd-party distributions? It was Jose Alberto who wanted them in the default namespace ;-) What is the user's recourse, turn off the warning and manually typedef (both)? Probably. You don't have any chance to resolve this any other way since the order the resources get discovered and might even be different on each run (not sure, but it would certainly depend on the VM). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading
--- Stefan Bodewig [EMAIL PROTECTED] wrote: On Fri, 9 Sep 2005, Matt Benson [EMAIL PROTECTED] wrote: Load all resources from META-INF/antlib.xml at startup and process them, I'd say. Sounds cool, but what do you do about e.g. collisions among tasknames from 3rd-party distributions? It was Jose Alberto who wanted them in the default namespace ;-) What is the user's recourse, turn off the warning and manually typedef (both)? Probably. You don't have any chance to resolve this any other way since the order the resources get discovered and might even be different on each run (not sure, but it would certainly depend on the VM). I suppose, too, that a given project could supply two versions of antlib.xml: the package-level version designed for namespaces, and the one in META-INF that could use a (recommended) e.g. antcontrib=ac-* convention to reduce the chances of collision. :) Or would that be too ugly/scary for the world? -Matt Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib autoloading (was Re: cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java)
On 9/9/05, Stefan Bodewig [EMAIL PROTECTED] wrote: So, any ideas how this could be acomplished? Load all resources from META-INF/antlib.xml at startup and process them, I'd say. But doesn't that go against Ant's tradition to not have auto-magic things, but instead spell things out explicitly, usually in the build file? I'd rather we extend typedef to accept a fileset of AntLib jars to load, possibly thru META-INF/antlib.xml, than auto-magically loading all possible antlibs visible from the classpath. At least you can see it and start looking at the jars it loads. How would you know looking at a build file where a task is coming from otherwise? Also, for example, I have quite a few AntLibs which are in ant/lib, and thus on Ant's classpath, but I don't use all of them in all my builds. They're there because it's our official supercharged production Ant distro, but loading all of them in builds that require none or just a few is wasteful. I personnally want to stay in control of what gets loaded in each build. I don't want to prevent others to do it if they fancy it, as long as it's not forced on me. --DD PS: And BTW, Matt's point about conflict resolution is a good one. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib loading in typedef
I was thinking of having another attribute (like antlib=antlib:org.smartfrog.tools.ant) to set the uri and resource. It may be a good idea however to do this by default with just the uri attribute - if the user has not specified the resource/filename. Peter Steve Loughran wrote: Why do you have to repeat the full path to an antlib in typedef, when declaring into an antlib url. surely this should be sufficient typedef uri=antlib:org.smarfrog.tools.ant classpathref=smartfrog.tasks.classpath onerror=failall / I think if we have special handling of antlib namespaces, typedef ought to adopt that same logic, and get the path to the resource from the URI, if it is an antlib URI - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib loading in typedef
From: Steve Loughran [mailto:[EMAIL PROTECTED] One change I have also checked in to Definer.java is some extra logic for naming antlibs. Instead of just antlib:org.example.package you can go antlib://org/example/package/file.xml and have that file's declarations read in. This will let me keep a set of antlibs in a single dir, load it with -lib and then have antlib://m2-macros.xml antlib://sf-macros.xml So, I am clearly +1 in having this feature. What I am 0 about is the exact syntax. Should it be a full path like what I have done, or should it be antlib://org.example.package/file.xml antlib:org.example.package/file.xml antlib://org.example.package/antlib.xml In which case, the antlib.xml is just something we patch in on the end if there is no /*.xml file defined at the tail. Thoughts? I guess you did go more into the use case, after your commit ;-) I'm still not sure I fully follow your logic... but it sounds like you want to load some macros by (ab?)using the antlib mechanism??? Why not simply use import to load target-less builds with macro definitions? Auto-downloading tasks (instead of push, I much prefer pull, where you fail asking the user to run a given target to do the download explicitly) can be handled just the same with an imported build file, no? The one think your current use of antlib with -lib gives you is the ability to locate the resource dynamically using the classpath. This could and probably should be handled using an import path (kind of like a vpath) that import could use, no? I think this feature has been requested before. It would avoid me having to use an env. var. to locate the imported file as well. Like I said in my other message, I think we should reserve the antlib loading mechanism for load task collection just in the usual way, and use import, possibly enhanced, to support what I believe you want. Thoughts? --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib loading in typedef
Dominique Devienne wrote: From: Steve Loughran [mailto:[EMAIL PROTECTED] One change I have also checked in to Definer.java is some extra logic for naming antlibs. Instead of just antlib:org.example.package you can go antlib://org/example/package/file.xml and have that file's declarations read in. This will let me keep a set of antlibs in a single dir, load it with -lib and then have antlib://m2-macros.xml antlib://sf-macros.xml So, I am clearly +1 in having this feature. What I am 0 about is the exact syntax. Should it be a full path like what I have done, or should it be antlib://org.example.package/file.xml antlib:org.example.package/file.xml antlib://org.example.package/antlib.xml In which case, the antlib.xml is just something we patch in on the end if there is no /*.xml file defined at the tail. Thoughts? I guess you did go more into the use case, after your commit ;-) yeah, i kind of stuck it in as an experiment; we can back out trivially I'm still not sure I fully follow your logic... but it sounds like you want to load some macros by (ab?)using the antlib mechanism??? Why not simply use import to load target-less builds with macro definitions? I will still be using import where needed, but I wanted to define custom antlibs for all the presetdefs and typedefs and scripted things, with the goal being third party projects can reuse them by -lib including the directory. without the full-path antlib stuff we can do that, I just have to create one package/lib. here is the problem i am trying to deal with http://cvs.sourceforge.net/viewcvs.py/*checkout*/smartfrog/core/antbuild/doc/third_generation_build_process.sxw Auto-downloading tasks (instead of push, I much prefer pull, where you fail asking the user to run a given target to do the download explicitly) can be handled just the same with an imported build file, no? I'll probably have a sequence to pull down extra stuff w/ maven as need be The one think your current use of antlib with -lib gives you is the ability to locate the resource dynamically using the classpath. This could and probably should be handled using an import path (kind of like a vpath) that import could use, no? I think this feature has been requested before. It would avoid me having to use an env. var. to locate the imported file as well. yeah, an import path. interesting idea, though we'd need something on import to refer to a search path or something Like I said in my other message, I think we should reserve the antlib loading mechanism for load task collection just in the usual way, and use import, possibly enhanced, to support what I believe you want. Thoughts? --DD I am still working out how best to use antlib, and i think others are in the same state. Anything we can do to make this and import work better in big projects is good. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib loading in typedef
Stefan Bodewig wrote:
On Mon, 22 Aug 2005, Steve Loughran [EMAIL PROTECTED] wrote:
Why do you have to repeat the full path to an antlib in typedef,
when declaring into an antlib url.
antlib descriptor, you mean?
If so, I agree with you, we should magically provide a default for the
resource attribute if uri has been specified and uses the antlib
protocol.
This is working, I now have an importable build file whose aim in life
is to make sure an antlib is loaded, and if not, pulls down the files
from the maven libraries and declares them.
?xml version=1.0 ?
project name=sftasks
xmlns:ac=antlib:net.sf.antcontrib
xmlns:sf=antlib:org.smartfrog.tools.ant
xmlns:m2=antlib:org.apache.maven.artifact.ant
target name=smartfrog-tasks-classpath
depends=core.load-version-info
m2:dependencies pathID=smartfrog.tasks.classpath
dependency groupID=org.smartfrog
artifactID=smartfrog
version=${smartfrog-version}
scope=compile
/
dependency groupID=org.smartfrog
artifactID=sfServices
version=${smartfrog-version}
scope=compile
/
dependency groupID=org.smartfrog
artifactID=sf-tasks
version=${smartfrog-version}
scope=compile
/
/m2:dependencies
/target
target name=use-smartfrog-tasks
depends=sftasks.smartfrog-tasks-classpath
description=declare the classpath and imports for the smartfrog
tasks
property name=sf.antlib.uri
value=antlib:org.smartfrog.tools.ant /
ac:if
not
typefound
uri=${sf.antlib.uri}
name=startdaemon/
/not
ac:then
typedef
uri=${sf.antlib.uri}
classpathref=smartfrog.tasks.classpath
onerror=failall
/
/ac:then
ac:else
echo level=verboseTasks already found/echo
/ac:else
/ac:if
/target
/project
Next I could tease out some of it into a macro for broader re-use, which
leads to the next issue.
One change I have also checked in to Definer.java is some extra logic
for naming antlibs. Instead of just
antlib:org.example.package
you can go
antlib://org/example/package/file.xml
and have that file's declarations read in. This will let me keep a set
of antlibs in a single dir, load it with -lib and then have
antlib://m2-macros.xml
antlib://sf-macros.xml
So, I am clearly +1 in having this feature. What I am 0 about is the
exact syntax. Should it be a full path like what I have done, or should
it be
antlib://org.example.package/file.xml
antlib:org.example.package/file.xml
antlib://org.example.package/antlib.xml
In which case, the antlib.xml is just something we patch in on the end
if there is no /*.xml file defined at the tail.
Thoughts?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib loading in typedef
On Mon, 22 Aug 2005, Steve Loughran [EMAIL PROTECTED] wrote: Why do you have to repeat the full path to an antlib in typedef, when declaring into an antlib url. antlib descriptor, you mean? If so, I agree with you, we should magically provide a default for the resource attribute if uri has been specified and uses the antlib protocol. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib package names
We could use org.apache.ant.kernel :-) Isn't it the same thing? JA -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: 20 April 2005 16:24 To: Ant Developers List Subject: RE: Antlib package names From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED] cheektongueUse of core as a package/directory name is mildly off in a UNIX environment as the directory might be confused with a core dump! ;n)/tongue/cheek Phil :n) It would be a directory instead of a file though, so it wouldn't be mistaken for long. I'm not sure it invalidates my proposal though; I guess it puts a dent in it OTOH. We're often discussing Ant Core, and until now nobody's mentioned it could be confused for Ant's Core dump ;-) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib package names
cheektongueUse of core as a package/directory name is mildly off in a UNIX environment as the directory might be confused with a core dump! ;n)/tongue/cheek Phil :n) -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: Wed 20/04/2005 15:28 To: Ant Developers List Cc: Subject:RE: Antlib package names From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] We shouldnt plan the name only for the svn-package. Thats a general question for future extensions. Von: Peter Reilly [mailto:[EMAIL PROTECTED] Perhaps it could be just org.apache.ant.svn - i.e. drop antlibs. Actually, Peter might have a point. Why not drop antlibs, and to indeed differentiate future extensions from Ant core, then add an explicit org.apache.ant.core package, which opens up the app-top-level org.apache.ant package for antlibs. So we'd have: org.apache.ant.core - Ant Core - explicit enough org.apache.ant.svn - SNV AntLib org.apache.ant.foo - FOO AntLib org.apache.ant.bar - BAR AntLib etc... I think I like this scheme better in fact. Use a more explicit package for Core, while offering shorter names for AntLibs. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib package names
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] We shouldnt plan the name only for the svn-package. That´s a general question for future extensions. Von: Peter Reilly [mailto:[EMAIL PROTECTED] Perhaps it could be just org.apache.ant.svn - i.e. drop antlibs. Actually, Peter might have a point. Why not drop antlibs, and to indeed differentiate future extensions from Ant core, then add an explicit org.apache.ant.core package, which opens up the app-top-level org.apache.ant package for antlibs. So we'd have: org.apache.ant.core - Ant Core - explicit enough org.apache.ant.svn - SNV AntLib org.apache.ant.foo - FOO AntLib org.apache.ant.bar - BAR AntLib etc... I think I like this scheme better in fact. Use a more explicit package for Core, while offering shorter names for AntLibs. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib package names
From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED] cheektongueUse of core as a package/directory name is mildly off in a UNIX environment as the directory might be confused with a core dump! ;n)/tongue/cheek Phil :n) It would be a directory instead of a file though, so it wouldn't be mistaken for long. I'm not sure it invalidates my proposal though; I guess it puts a dent in it OTOH. We're often discussing Ant Core, and until now nobody's mentioned it could be confused for Ant's Core dump ;-) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib package names
Dominique Devienne wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] for the svn tasks I've used org.apache.tools.ant.taskdefs.svn, for the newer antunit I've used org.apache.ant.antlibs.antunit. I'd like to drop the tools for antlibs and I think antlibs should be somewhere in the package names, so I'd turn the former into org.apache.ant.antlibs.svn. Any other ideas, preferences? I'm all for dropping tools. But I don't like the sounds of ant.antlibs. I just don't like the repetition. I personally prefer either ant.libs or even just org.apache.antlibs, although the later being a new top-level name is probably not appropriate. No strong feeling really, but reading ant.antlibs is painful to me somehow ;-) --DD Perhaps it could be just org.apache.ant.svn - i.e. drop antlibs. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib package names
Hi, 2 things to defend core and one thing against it to take into consideration core would be defence: 1) typically no execution would be taking place from en expanded source code structure on the third level, so why would a core dump be generated on that spot anyway. (and who would be looking there for a core dump?) 2) file core and directory core are something different consider: core may be excluded from backup's, svn/cvs syncing. I also like core best, but maybe it isn't such a good idea indeed. for historical reasons we could use tools ;-) oata - oaat Martijn Jose Alberto Fernandez wrote: We could use org.apache.ant.kernel :-) Isn't it the same thing? JA -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: 20 April 2005 16:24 To: Ant Developers List Subject: RE: Antlib package names From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED] cheektongueUse of core as a package/directory name is mildly off in a UNIX environment as the directory might be confused with a core dump! ;n)/tongue/cheek Phil :n) It would be a directory instead of a file though, so it wouldn't be mistaken for long. I'm not sure it invalidates my proposal though; I guess it puts a dent in it OTOH. We're often discussing Ant Core, and until now nobody's mentioned it could be confused for Ant's Core dump ;-) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib package names
From: Martijn Kruithof [mailto:[EMAIL PROTECTED] I also like core best, but maybe it isn't such a good idea indeed. Let's just forget about org.apache.ant.core... --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Antlib package names
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] for the svn tasks I've used org.apache.tools.ant.taskdefs.svn, for the newer antunit I've used org.apache.ant.antlibs.antunit. I'd like to drop the tools for antlibs and I think antlibs should be somewhere in the package names, so I'd turn the former into org.apache.ant.antlibs.svn. Any other ideas, preferences? I'm all for dropping tools. But I don't like the sounds of ant.antlibs. I just don't like the repetition. I personally prefer either ant.libs or even just org.apache.antlibs, although the later being a new top-level name is probably not appropriate. No strong feeling really, but reading ant.antlibs is painful to me somehow ;-) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib package names
Dominique Devienne wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] for the svn tasks I've used org.apache.tools.ant.taskdefs.svn, for the newer antunit I've used org.apache.ant.antlibs.antunit. I'd like to drop the tools for antlibs and I think antlibs should be somewhere in the package names, so I'd turn the former into org.apache.ant.antlibs.svn. Any other ideas, preferences? I'm all for dropping tools. But I don't like the sounds of ant.antlibs. I just don't like the repetition. I personally prefer either ant.libs or even just org.apache.antlibs, although the later being a new top-level name is probably not appropriate. No strong feeling really, but reading ant.antlibs is painful to me somehow ;-) --DD Putting in ant on all subpackages would also lead to package abbreviations only contaings a after an initial o.. ant / antlibs on top level would be hard to discern as well as both would be abbreviated to oa, so personally I'd prefer ant.libs. Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib and classloaders
Jose Alberto Fernandez wrote: As the URI protocol antlib: provides a shortcut for the typedef/ above, I am just thinking on providing something similar for the classpath declaration when needed. classpath id=foo.bar./classpath I have been doing a little thinking about this. What about a task to specify the classpath to use if the antlib: shortcut is triggered for a particular uri: something like: antlibclasspath uri=antlib:foo.bar [path attributes] [loaderref attribute] [path elements] /antlibclasspath This would be a relatively low-cost task - it does not trigger reading the antlib.xml resource until the antlib: shortcut is triggered - so it could be placed in a common xml file imported by a site's build.xml files. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib and classloaders
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
As the URI protocol antlib: provides a shortcut for the typedef/
above, I am just thinking on providing something similar for the
classpath declaration when needed.
classpath id=foo.bar./classpath
I have been doing a little thinking about this.
What about a task to specify the classpath to use if the antlib:
shortcut is triggered
for a particular uri:
something like:
antlibclasspath uri=antlib:foo.bar [path attributes]
[loaderref attribute]
[path elements]
/antlibclasspath
This would be a relatively low-cost task - it does not
trigger reading the antlib.xml resource until the antlib:
shortcut is triggered - so it could be placed in a common xml
file imported by a site's build.xml files.
I think we are in the same wavelength here. I was trying to use
just classpath/ or the new classloader/ tasks directly
rather than having special versions of them.
I see the documentation value of what you propose, though
(specially with the URI attribute).
In any case, if we have an specific task for this, I would suggest
calling renaming it antlibloader/ with syntax similar to yours:
antlibloader uri=antlib:foo.bar
[{classpathref=...| loaderref=...}] [id=...]
[classpath/classpath]
[classloader.../classloader]
/antlibloader
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib and classloaders
As I said, I am not against using -lib (or some other environment magic)
my only point is that I would also think that having a way to
specify this things in the project file itself (and keeping it as
succinct
as possible) would be good.
In particular when you have different projects each with its own
set of third party libraries.
Jose Alberto
-Original Message-
From: didge [mailto:[EMAIL PROTECTED]
Sent: 03 April 2004 00:02
To: Ant Developers List
Subject: RE: antlib and classloaders
So what's to say that we can't build up an ANTLIB_PATH just
like we build up CLASSPATHs using classpath?
didge
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Friday, April 02, 2004 2:46 AM
To: Ant Developers List; [EMAIL PROTECTED]
Subject: RE: antlib and classloaders
The only issue I have with your suggestions is the fact that they
require the user to express dependencies outside the project itself.
This may be fine for many, but if you have to deal with multiple
projects that require different sets of dependencies, it
would be nice
if one could express this in the buildfile itself were it
can be more
easily maintained.
The alternative today that most of us have to use is to
create our own
build.{sh,cmd,bat} and place the correct -lib args in the
script. But
then you may have to maintain that script too during the
life of the
project.
My aim is to try to provide an in-buildfile alternative.
Jose Alberto
-Original Message-
From: didge [mailto:[EMAIL PROTECTED]
Sent: 02 April 2004 01:16
To: Ant Developers List
Subject: RE: antlib and classloaders
How about just supporting an equivalent of an LD_LIBRARY_PATH for
antlibs, called ANTLIB_PATH or some such?
didge
-Original Message-
From: Matt Benson [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 1:58 PM
To: Ant Developers List
Subject: Re: antlib and classloaders
I'm not sure I followed your suggestion. As far as
allowing a way
to automagically include stuff without adding it to the base
installation, Antoine added the -lib option and Conor
extended it
to pull all jars from directories on (looks like) a path-style
argument
specified with
that option (as well as including the directories
themselves). So now
I can store lots of antlib.xml files right on the
filesystem, say
under $HOME/.ant/lib in multiple package structures,
set ANT_ARGS
to include -lib $HOME/.ant/lib and voila! I can now modify
commonly-used antlibs all I want.
Now we can conceive of auto-installers that modify
$HOME/.antrc to
append -lib options to ANT_ARGS to point to 3rd-party
stuff... since
windows systems are less likely to use shared Ant
installations, Un*x
is the most useful place for this stuff.
-Matt
--- Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
Hi, I have been giving some thought on ways to solve this
nagging issue of needing to put antlib jars on the lib
directory.
We hear over and over people wanting to keep their third party
libraries out of -lib because they are only for an
specific project.
As I see it, our road block has been how to tell in
succinct way in
the buildfile that when loading the namespace
antlib:foo.bar
you should use this or that classpath or classloader.
A simple solution could be to achieve this by name
association:
- When ANT tries to find and load the resource for
antlib:foo.bar
it will first look for a reference named foo.bar
representing
a classloader (or classpath?). If an object of the
correct type is
found, then this classloader will be user for
resolving and loadding
the antlib, otherwise the default classloader will
be use, as it is
today.
So with this in place, one could write things like:
project name=x xmlns:lib=antlib:foo.bar
classpath id=foo.bar./classpath
lib:mytask / !-- The antlib loaded using
the classloader for
foo.bar --
/project
Before jumping on a code proposal, does this sound a
the right
or good solution? Does this cover enough of the use cases?
Let me know what you people think.
Jose Aberto
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
-
To unsubscribe, e
RE: antlib and classloaders
How about just supporting an equivalent of an LD_LIBRARY_PATH for antlibs, called ANTLIB_PATH or some such? didge -Original Message- From: Matt Benson [mailto:[EMAIL PROTECTED] Sent: Thursday, April 01, 2004 1:58 PM To: Ant Developers List Subject: Re: antlib and classloaders I'm not sure I followed your suggestion. As far as allowing a way to automagically include stuff without adding it to the base installation, Antoine added the -lib option and Conor extended it to pull all jars from directories on (looks like) a path-style argument specified with that option (as well as including the directories themselves). So now I can store lots of antlib.xml files right on the filesystem, say under $HOME/.ant/lib in multiple package structures, set ANT_ARGS to include -lib $HOME/.ant/lib and voila! I can now modify commonly-used antlibs all I want. Now we can conceive of auto-installers that modify $HOME/.antrc to append -lib options to ANT_ARGS to point to 3rd-party stuff... since windows systems are less likely to use shared Ant installations, Un*x is the most useful place for this stuff. -Matt --- Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Hi, I have been giving some thought on ways to solve this nagging issue of needing to put antlib jars on the lib directory. We hear over and over people wanting to keep their third party libraries out of -lib because they are only for an specific project. As I see it, our road block has been how to tell in succinct way in the buildfile that when loading the namespace antlib:foo.bar you should use this or that classpath or classloader. A simple solution could be to achieve this by name association: - When ANT tries to find and load the resource for antlib:foo.bar it will first look for a reference named foo.bar representing a classloader (or classpath?). If an object of the correct type is found, then this classloader will be user for resolving and loadding the antlib, otherwise the default classloader will be use, as it is today. So with this in place, one could write things like: project name=x xmlns:lib=antlib:foo.bar classpath id=foo.bar./classpath lib:mytask / !-- The antlib loaded using the classloader for foo.bar -- /project Before jumping on a code proposal, does this sound a the right or good solution? Does this cover enough of the use cases? Let me know what you people think. Jose Aberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib and classloaders
The only issue I have with your suggestions is the fact that
they require the user to express dependencies outside the project
itself.
This may be fine for many, but if you have to deal with multiple
projects
that require different sets of dependencies, it would be nice if one
could express this in the buildfile itself were it can be more easily
maintained.
The alternative today that most of us have to use is to create our own
build.{sh,cmd,bat} and place the correct -lib args in the script.
But then you may have to maintain that script too during the life of the
project.
My aim is to try to provide an in-buildfile alternative.
Jose Alberto
-Original Message-
From: didge [mailto:[EMAIL PROTECTED]
Sent: 02 April 2004 01:16
To: Ant Developers List
Subject: RE: antlib and classloaders
How about just supporting an equivalent of an LD_LIBRARY_PATH
for antlibs, called ANTLIB_PATH or some such?
didge
-Original Message-
From: Matt Benson [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 1:58 PM
To: Ant Developers List
Subject: Re: antlib and classloaders
I'm not sure I followed your suggestion. As far as
allowing a way to automagically include stuff without
adding it to the base installation, Antoine added the
-lib option and Conor extended it to pull all jars
from directories on (looks like) a path-style argument
specified with
that option (as well as including the directories
themselves). So now
I can store lots of antlib.xml files right on the filesystem, say
under $HOME/.ant/lib in multiple package structures, set
ANT_ARGS to include -lib $HOME/.ant/lib and voila!
I can now modify commonly-used antlibs all I want.
Now we can conceive of auto-installers that modify $HOME/.antrc to
append -lib options to ANT_ARGS to point to 3rd-party
stuff... since
windows systems are less likely to use shared Ant
installations, Un*x
is the most useful place for this stuff.
-Matt
--- Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
Hi, I have been giving some thought on ways to solve
this nagging
issue of needing to put antlib jars on the lib
directory.
We hear over and over people wanting to keep their
third party
libraries out of -lib because they are only for an
specific project.
As I see it, our road block has been how to tell in
succinct way in
the buildfile that when loading the namespace
antlib:foo.bar you should
use this or that classpath or classloader.
A simple solution could be to achieve this by name
association:
- When ANT tries to find and load the resource for
antlib:foo.bar
it will first look for a reference named foo.bar
representing
a classloader (or classpath?). If an object of the
correct type is
found, then this classloader will be user for
resolving and loadding
the antlib, otherwise the default classloader will
be use, as it is
today.
So with this in place, one could write things like:
project name=x xmlns:lib=antlib:foo.bar
classpath id=foo.bar./classpath
lib:mytask / !-- The antlib loaded using
the classloader for
foo.bar --
/project
Before jumping on a code proposal, does this sound a
the right or good
solution? Does this cover enough of the use cases?
Let me know what you people think.
Jose Aberto
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib and classloaders
Mariano's original question was why
was classpath ignored in an antlib definition.
antlib
typedef name=task classname=org.mytasks.Task loaderref=mytasks.ref
classpath
fileset dir=${env.MY_TASKS_HOME}/lib includes=**/*.jar/
/classpath
typedef name=task2 classname=org.mytasks.Task2 loaderref=mytasks.ref/
/antlib
This could be supported easily in the current code base.
-i.e. if an typedef/taskdef in an antlib sets the classpath, this classpath
will be used instead
of the antlibdefinition classpath.
The only problem with this is that the user build script needs to set the
correct property
before the antlib is activated.
Peter
Mariano Benitez wrote:
I have this issue in mind:
Since I need to provide antlibs to my customers, I would like them to
have to manually configure as less as possible, that means that the
previous way of saying -b myapp/antlib was quite cool.
The problem is that I do need to control the classloader where the
tasks are loaded, because I cannot copy the whole list of jars in my
app to the antlib classpath. Maybe by just copying ONE jar to antlib
is just fine, and inside the antlib.xml control the classloading.
Maybe only making the antlib.xml file available in the ant base
classpath would be another way.
Following your proposal, inside my antlib.xml I would define the
classpath for the antlib itself, leaving all configuration inside
there, and not having to manually define a classpath outside the
antlib. I know this can be achieved by using an import task, that is
the solution I will implement in 1.6.1, but having all the
classloading issues inside the antlib file itself is more simple for
the user of the antlib. Also reduces the main ant classpath.
Well, those are my 2 cents, hope is clear, antlibs are great and I
would like them to keep evolving and making it better.
MAriano
Jose Alberto Fernandez wrote:
Hi, I have been giving some thought on ways to solve this nagging
issue of needing to put antlib jars on the lib directory.
We hear over and over people wanting to keep their third party
libraries out of -lib because they are only for an specific project.
As I see it, our road block has been how to tell in succinct way in the
buildfile that when loading the namespace antlib:foo.bar you should
use this or that classpath or classloader.
A simple solution could be to achieve this by name association:
- When ANT tries to find and load the resource for antlib:foo.bar
it will first look for a reference named foo.bar representing
a classloader (or classpath?). If an object of the correct type is
found, then this classloader will be user for resolving and loadding
the antlib, otherwise the default classloader will be use, as it is
today.
So with this in place, one could write things like:
project name=x xmlns:lib=antlib:foo.bar
classpath id=foo.bar./classpath
lib:mytask / !-- The antlib loaded using the classloader for
foo.bar --
/project
Before jumping on a code proposal, does this sound a the right or good
solution? Does this cover enough of the use cases?
Let me know what you people think.
Jose Aberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib and classloaders
Hi, This sounds nice but does it save that much on project name=x xmlns:lib=antlib:foo.bar typedef resource=foo/bar/antlib.xml uri=antlib:foo.bar classpath./classpath /typedef lib:mytask / !-- The antlib loaded using the classloader for foo.bar -- /project Peter Jose Alberto Fernandez wrote: Hi, I have been giving some thought on ways to solve this nagging issue of needing to put antlib jars on the lib directory. We hear over and over people wanting to keep their third party libraries out of -lib because they are only for an specific project. As I see it, our road block has been how to tell in succinct way in the buildfile that when loading the namespace antlib:foo.bar you should use this or that classpath or classloader. A simple solution could be to achieve this by name association: - When ANT tries to find and load the resource for antlib:foo.bar it will first look for a reference named foo.bar representing a classloader (or classpath?). If an object of the correct type is found, then this classloader will be user for resolving and loadding the antlib, otherwise the default classloader will be use, as it is today. So with this in place, one could write things like: project name=x xmlns:lib=antlib:foo.bar classpath id=foo.bar./classpath lib:mytask / !-- The antlib loaded using the classloader for foo.bar -- /project Before jumping on a code proposal, does this sound a the right or good solution? Does this cover enough of the use cases? Let me know what you people think. Jose Aberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib and classloaders
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Mariano's original question was why
was classpath ignored in an antlib definition.
antlib
typedef name=task classname=org.mytasks.Task
loaderref=mytasks.ref
classpath
fileset dir=${env.MY_TASKS_HOME}/lib includes=**/*.jar/
/classpath
typedef name=task2 classname=org.mytasks.Task2
loaderref=mytasks.ref/ /antlib
This could be supported easily in the current code base.
-i.e. if an typedef/taskdef in an antlib sets the classpath,
this classpath will be used instead of the antlibdefinition classpath.
Maybe the parent classloader should be that the antlibdefinition
classpath.
But yes I agree with you.
The only problem with this is that the user build script
needs to set the correct property before the antlib is activated.
Which I think it is not much to ask.
I have a conceptual problem of usability on an antlib written like this,
remember, in the broader sense, the antlib is written by a third party
for the
usage of unrelated users in unrelated projects.
Having a classpath in there, constricts the user of the library to
follow
whichever layout criteria the third-party decides.
Which does not seem to be right.
Now, that does not mean that I am against such capability, to use in
very closely controlled projects.
Jose Alberto
Peter
Mariano Benitez wrote:
I have this issue in mind:
Since I need to provide antlibs to my customers, I would
like them to
have to manually configure as less as possible, that means that the
previous way of saying -b myapp/antlib was quite cool.
The problem is that I do need to control the classloader where the
tasks are loaded, because I cannot copy the whole list of
jars in my
app to the antlib classpath. Maybe by just copying ONE jar
to antlib
is just fine, and inside the antlib.xml control the classloading.
Maybe only making the antlib.xml file available in the ant base
classpath would be another way.
Following your proposal, inside my antlib.xml I would define the
classpath for the antlib itself, leaving all configuration inside
there, and not having to manually define a classpath outside the
antlib. I know this can be achieved by using an import
task, that is
the solution I will implement in 1.6.1, but having all the
classloading issues inside the antlib file itself is more
simple for
the user of the antlib. Also reduces the main ant classpath.
Well, those are my 2 cents, hope is clear, antlibs are great and I
would like them to keep evolving and making it better.
MAriano
Jose Alberto Fernandez wrote:
Hi, I have been giving some thought on ways to solve this nagging
issue of needing to put antlib jars on the lib directory.
We hear over and over people wanting to keep their third party
libraries out of -lib because they are only for an
specific project.
As I see it, our road block has been how to tell in
succinct way in
the buildfile that when loading the namespace antlib:foo.bar you
should use this or that classpath or classloader. A simple
solution
could be to achieve this by name association:
- When ANT tries to find and load the resource for
antlib:foo.bar
it will first look for a reference named foo.bar representing a
classloader (or classpath?). If an object of the correct type is
found, then this classloader will be user for resolving
and loadding
the antlib, otherwise the default classloader will be use,
as it is
today.
So with this in place, one could write things like:
project name=x xmlns:lib=antlib:foo.bar
classpath id=foo.bar./classpath
lib:mytask / !-- The antlib loaded using the
classloader for
foo.bar --
/project
Before jumping on a code proposal, does this sound a the right or
good solution? Does this cover enough of the use cases?
Let me know what you people think.
Jose Aberto
-
---
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib and classloaders
From: Peter Reilly [mailto:[EMAIL PROTECTED] Hi, This sounds nice but does it save that much on project name=x xmlns:lib=antlib:foo.bar typedef resource=foo/bar/antlib.xml uri=antlib:foo.bar classpath./classpath /typedef lib:mytask / !-- The antlib loaded using the classloader for foo.bar -- /project Well I could ask the same question about antlib's namespace. Why having some magic URI when users could just write: typedef resource=foo/bar/antlib.xml uri=antlib:foo.bar/ and make the loading explicit. As the URI protocol antlib: provides a shortcut for the typedef/ above, I am just thinking on providing something similar for the classpath declaration when needed. classpath id=foo.bar./classpath BTW, do we have the concept of classloader as a first class object? I can never remember. One thing that one wants to have is a way to define one classloader that can be used by multiple antlibs so that the tasks and types are compatible. Using classpath/ may befine different classloaders and at the end you loose the ability to use them as building blocks. Do we have a way to guarantee that the same classloader can be used in two diferent places? Jose Alberto Peter Jose Alberto Fernandez wrote: Hi, I have been giving some thought on ways to solve this nagging issue of needing to put antlib jars on the lib directory. We hear over and over people wanting to keep their third party libraries out of -lib because they are only for an specific project. As I see it, our road block has been how to tell in succinct way in the buildfile that when loading the namespace antlib:foo.bar you should use this or that classpath or classloader. A simple solution could be to achieve this by name association: - When ANT tries to find and load the resource for antlib:foo.bar it will first look for a reference named foo.bar representing a classloader (or classpath?). If an object of the correct type is found, then this classloader will be user for resolving and loadding the antlib, otherwise the default classloader will be use, as it is today. So with this in place, one could write things like: project name=x xmlns:lib=antlib:foo.bar classpath id=foo.bar./classpath lib:mytask / !-- The antlib loaded using the classloader for foo.bar -- /project Before jumping on a code proposal, does this sound a the right or good solution? Does this cover enough of the use cases? Let me know what you people think. Jose Aberto - -- - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib and classloaders
The only problem with this is that the user build script needs to set the correct property before the antlib is activated. Which I think it is not much to ask. I have a conceptual problem of usability on an antlib written like this, remember, in the broader sense, the antlib is written by a third party for the usage of unrelated users in unrelated projects. Having a classpath in there, constricts the user of the library to follow whichever layout criteria the third-party decides. Which does not seem to be right. The context in which I say this is: I have a big application (www.fuego.com) that provides ant tasks to perform most of its admin operation, it is a requirement to have the application installed and then define a property fuego.basedir that tells where the app is installed. The main problem is that I cannot bundle all the required files to use the application in a single antlib, it would be extremely big and hard to update/patch/etc. without lots of manual intervention. My intention is to minimize the manual steps to have a fuego antlib working, so the xmlns:fuego=antlib:fuego.tools.ant was great. Using an include.xml file is a good workaround but that implies that on every build besides the xml namespace they need to do one more step, that is a 100% increase in the number or changes they need to run fuego. :) I guess that most big application might follow this kind of path, having a small antlib file, and refer to the dependencies that are in the application install dir. I completely agree that for most basic/optional (core) tasks would include all the dependencies in the antlib, but for a big app it is not possible. I guess my case is the one for tasks that are bundled in other applications. For example, if the Tomcat guys bundle their tasks with them, why should you copy all the jasper stuff to an antlib instead of reference them from the antlib.xml MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib and classloaders
From: Mariano Benitez [mailto:[EMAIL PROTECTED] The context in which I say this is: I have a big application (www.fuego.com) that provides ant tasks to perform most of its admin operation, it is a requirement to have the application installed and then define a property fuego.basedir that tells where the app is installed. The main problem is that I cannot bundle all the required files to use the application in a single antlib, it would be extremely big and hard to update/patch/etc. without lots of manual intervention. Have you thought about using the Class-Path attribute on the manifiest of the ANTLIB jar itself? If your libraries location are relative to your antlib-jar location (e.g., in a subdir) then that should work fine since Java will add the jars to the classloader. My intention is to minimize the manual steps to have a fuego antlib working, so the xmlns:fuego=antlib:fuego.tools.ant was great. Using an include.xml file is a good workaround but that implies that on every build besides the xml namespace they need to do one more step, that is a 100% increase in the number or changes they need to run fuego. :) I guess that most big application might follow this kind of path, having a small antlib file, and refer to the dependencies that are in the application install dir. I completely agree that for most basic/optional (core) tasks would include all the dependencies in the antlib, but for a big app it is not possible. I guess my case is the one for tasks that are bundled in other applications. For example, if the Tomcat guys bundle their tasks with them, why should you copy all the jasper stuff to an antlib instead of reference them from the antlib.xml MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib and classloaders
Jose Alberto Fernandez wrote: From: Mariano Benitez [mailto:[EMAIL PROTECTED] The context in which I say this is: I have a big application (www.fuego.com) that provides ant tasks to perform most of its admin operation, it is a requirement to have the application installed and then define a property fuego.basedir that tells where the app is installed. The main problem is that I cannot bundle all the required files to use the application in a single antlib, it would be extremely big and hard to update/patch/etc. without lots of manual intervention. Have you thought about using the Class-Path attribute on the manifiest of the ANTLIB jar itself? This will not work too good as the jars get added to the global/default classloader and this may cause conflicts (multi commons_xx.jar for example). Peter If your libraries location are relative to your antlib-jar location (e.g., in a subdir) then that should work fine since Java will add the jars to the classloader. My intention is to minimize the manual steps to have a fuego antlib working, so the xmlns:fuego=antlib:fuego.tools.ant was great. Using an include.xml file is a good workaround but that implies that on every build besides the xml namespace they need to do one more step, that is a 100% increase in the number or changes they need to run fuego. :) I guess that most big application might follow this kind of path, having a small antlib file, and refer to the dependencies that are in the application install dir. I completely agree that for most basic/optional (core) tasks would include all the dependencies in the antlib, but for a big app it is not possible. I guess my case is the one for tasks that are bundled in other applications. For example, if the Tomcat guys bundle their tasks with them, why should you copy all the jasper stuff to an antlib instead of reference them from the antlib.xml MAriano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib and classloaders
So what's to say that we can't build up an ANTLIB_PATH just like we build up
CLASSPATHs using classpath?
didge
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Friday, April 02, 2004 2:46 AM
To: Ant Developers List; [EMAIL PROTECTED]
Subject: RE: antlib and classloaders
The only issue I have with your suggestions is the fact that
they require the user to express dependencies outside the project
itself.
This may be fine for many, but if you have to deal with multiple
projects
that require different sets of dependencies, it would be nice if one
could express this in the buildfile itself were it can be more easily
maintained.
The alternative today that most of us have to use is to create our own
build.{sh,cmd,bat} and place the correct -lib args in the script.
But then you may have to maintain that script too during the life of the
project.
My aim is to try to provide an in-buildfile alternative.
Jose Alberto
-Original Message-
From: didge [mailto:[EMAIL PROTECTED]
Sent: 02 April 2004 01:16
To: Ant Developers List
Subject: RE: antlib and classloaders
How about just supporting an equivalent of an LD_LIBRARY_PATH
for antlibs, called ANTLIB_PATH or some such?
didge
-Original Message-
From: Matt Benson [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 01, 2004 1:58 PM
To: Ant Developers List
Subject: Re: antlib and classloaders
I'm not sure I followed your suggestion. As far as
allowing a way to automagically include stuff without
adding it to the base installation, Antoine added the
-lib option and Conor extended it to pull all jars
from directories on (looks like) a path-style argument
specified with
that option (as well as including the directories
themselves). So now
I can store lots of antlib.xml files right on the filesystem, say
under $HOME/.ant/lib in multiple package structures, set
ANT_ARGS to include -lib $HOME/.ant/lib and voila!
I can now modify commonly-used antlibs all I want.
Now we can conceive of auto-installers that modify $HOME/.antrc to
append -lib options to ANT_ARGS to point to 3rd-party
stuff... since
windows systems are less likely to use shared Ant
installations, Un*x
is the most useful place for this stuff.
-Matt
--- Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
Hi, I have been giving some thought on ways to solve
this nagging
issue of needing to put antlib jars on the lib
directory.
We hear over and over people wanting to keep their
third party
libraries out of -lib because they are only for an
specific project.
As I see it, our road block has been how to tell in
succinct way in
the buildfile that when loading the namespace
antlib:foo.bar you should
use this or that classpath or classloader.
A simple solution could be to achieve this by name
association:
- When ANT tries to find and load the resource for
antlib:foo.bar
it will first look for a reference named foo.bar
representing
a classloader (or classpath?). If an object of the
correct type is
found, then this classloader will be user for
resolving and loadding
the antlib, otherwise the default classloader will
be use, as it is
today.
So with this in place, one could write things like:
project name=x xmlns:lib=antlib:foo.bar
classpath id=foo.bar./classpath
lib:mytask / !-- The antlib loaded using
the classloader for
foo.bar --
/project
Before jumping on a code proposal, does this sound a
the right or good
solution? Does this cover enough of the use cases?
Let me know what you people think.
Jose Aberto
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib and classloaders
I'm not sure I followed your suggestion. As far as allowing a way to automagically include stuff without adding it to the base installation, Antoine added the -lib option and Conor extended it to pull all jars from directories on (looks like) a path-style argument specified with that option (as well as including the directories themselves). So now I can store lots of antlib.xml files right on the filesystem, say under $HOME/.ant/lib in multiple package structures, set ANT_ARGS to include -lib $HOME/.ant/lib and voila! I can now modify commonly-used antlibs all I want. Now we can conceive of auto-installers that modify $HOME/.antrc to append -lib options to ANT_ARGS to point to 3rd-party stuff... since windows systems are less likely to use shared Ant installations, Un*x is the most useful place for this stuff. -Matt --- Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Hi, I have been giving some thought on ways to solve this nagging issue of needing to put antlib jars on the lib directory. We hear over and over people wanting to keep their third party libraries out of -lib because they are only for an specific project. As I see it, our road block has been how to tell in succinct way in the buildfile that when loading the namespace antlib:foo.bar you should use this or that classpath or classloader. A simple solution could be to achieve this by name association: - When ANT tries to find and load the resource for antlib:foo.bar it will first look for a reference named foo.bar representing a classloader (or classpath?). If an object of the correct type is found, then this classloader will be user for resolving and loadding the antlib, otherwise the default classloader will be use, as it is today. So with this in place, one could write things like: project name=x xmlns:lib=antlib:foo.bar classpath id=foo.bar./classpath lib:mytask / !-- The antlib loaded using the classloader for foo.bar -- /project Before jumping on a code proposal, does this sound a the right or good solution? Does this cover enough of the use cases? Let me know what you people think. Jose Aberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: antlib namespaces
Sorry I lost the thread. And I'm still uncertain. It seems to me that no matter what (to continue with the earlier examples), this should be valid: myns:mytask myns:mytype / /myns:mytask but it doesn't work in beta2. Again, only: myns:mytask mytype / /myns:mytask works. I got the idea about explicitly declaring the local namespace so that the nested elements can be unqualified, but shouldn't fully-qualified elements work under any scenario? If not, why not? -Matt __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib feedback
On 17 Jul 2003, peter reilly [EMAIL PROTECTED] wrote: patch: 7203 add ant-type +1 A minor nit - please add an @author for yourself to IntrospectionHelper 8-), there already is too much in it that I shouldn't get credit (or blame ;-) for. patch: 7204 add antlib (xml form for type/task definitions) won't find time to look into it in depth before tomorrow. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib feedback
On Mon, 2003-07-21 at 15:47, Stefan Bodewig wrote: On 17 Jul 2003, peter reilly [EMAIL PROTECTED] wrote: patch: 7203 add ant-type +1 A minor nit - please add an @author for yourself to IntrospectionHelper 8-), there already is too much in it that I shouldn't get credit (or blame ;-) for. Ok. patch: 7204 add antlib (xml form for type/task definitions) won't find time to look into it in depth before tomorrow. Excellent. Cheers, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib feedback
On Thu, 2003-07-17 at 20:23, Antoine Levy-Lambert wrote: Hi Peter, +1 could you add also somewhere in the manual an explanation what ant-type means and which tasks or datatypes support it. I will try. The other changes (new custom condition, filter and selector type support in particular, and the new add[configured](type) introspection pattern) also need manual entries. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antlib feedback
Hi Peter, +1 could you add also somewhere in the manual an explanation what ant-type means and which tasks or datatypes support it. Antoine - Original Message - From: peter reilly [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 7:34 PM Subject: Antlib feedback Hi Is there any feedback for the two latest patches for antlib? http://issues.apache.org/bugzilla/show_bug.cgi?id=19897 patch: 7203 add ant-type patch: 7204 add antlib (xml form for type/task definitions) Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib
On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote: Whatever we adopt, it definetly need to be written from scratch. :-) Cool. All I had to go on was the code. If we agree that roles are based on the interface implemented by the nested element, that is good. It was my main concern. I still don't really see the need for roles but that's just me :-) Go for it. Conor
Re: antlib / proposal of Peter Reilly
Stefan Bodewig wrote: On 21 May 2003, Stefan Bodewig [EMAIL PROTECTED] wrote: I've seen that Costin and Conor prefer that antlibs specify their URI themselves. Could anybody please explain why OK, let me try to summarize your answers: Peter says - letting the user chose the URI may create problems if we want to add implicit meaning to URIs in the future. I think the same problem will arise if we let antlib writers chose the URI so we need to solve it differently. We could reserve all schema names starting with ant for internal use and prohibit anybody from using it, for example. To be consistent :-), I think we should let antlib writers pick arbitrary URIs either, at least in the first release. My proposal is to use the base package name of the implementation. Antlib authors can choose any package name they want - we should only require that the antlib URI matches the package. ( it's just one sugestion - I can live with any alternative, including UUIDs if that's what other people want :-) Conor and Costin - that's how you normally do it in the XML namespace context. Well, true. That doesn't necessarily mean it was a good idea 8-) There are quite a few bad ideas in XML ( schema is probably the winner in this category ). However requiring the namespace ( and the DTD ) URI to be stable is not a bad idea IMO. Costin Conor and Costin - if you read the build file and URIs are fixed you'll know which antlib is used. Well, that makes sense to me, thanks, the piece I was missing. Stefan
Re: antlib
Conor MacNeill wrote: On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote: Whatever we adopt, it definetly need to be written from scratch. :-) Cool. All I had to go on was the code. If we agree that roles are based on the interface implemented by the nested element, that is good. It was my main concern. I still don't really see the need for roles but that's just me :-) Go for it. I don't think it's just you, I'm on the same side. Probably a small poll on the remaining issues would help clarify where the majority stands. I think most people are willing to accept a range of solutions, and a lot is a matter of taste and prefference. So far I've heard the strong opinion of Jose on roles - and I'm not sure on the other's opinions. There are 2 negative opinions so far. If we decide to add roles, I would like to be clear where other committers stand. Costin
Re: antlib
On Thu, 22 May 2003, Conor MacNeill [EMAIL PROTECTED] I still don't really see the need for roles I'm not convinced either. Stefan
Re: antlib
I think that roles add clarity to description of datatypes or components. I liked the syntax of the antlib descriptor proposed by Jose Alberto, which in my example with shapes would have been : antlib version=1.5 task name=computearea class=org.apache.demo.ComputeAreaTask/ task name=computeperimeter class=org.apache.demo.ComputePerimeterTask/ role name=shape class=org.apache.demo.ShapeInterface/ ... shape name=circle class=org.apache.demo.Circle/ shape name=square class=org.apache.demo.Square/ ... /antlib Reading this, and knowing that computearea and computeperimeter accept shapes as nested element, a build file writer would know that circle/ and square/ can be nested inside computearea/ and computeperimeter/. This descriptor also says that ShapeInterface should have a special meaning for ant, which for instance Serializable, Cloneable, ... do not necessarily have. However, if , as it sounds, I am the only committer who expresses support for roles, I will give up on that subject. Antoine - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 22, 2003 7:02 AM Subject: Re: antlib Conor MacNeill wrote: On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote: Whatever we adopt, it definetly need to be written from scratch. :-) Cool. All I had to go on was the code. If we agree that roles are based on the interface implemented by the nested element, that is good. It was my main concern. I still don't really see the need for roles but that's just me :-) Go for it. I don't think it's just you, I'm on the same side. Probably a small poll on the remaining issues would help clarify where the majority stands. I think most people are willing to accept a range of solutions, and a lot is a matter of taste and prefference. So far I've heard the strong opinion of Jose on roles - and I'm not sure on the other's opinions. There are 2 negative opinions so far. If we decide to add roles, I would like to be clear where other committers stand. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib / proposal of Peter Reilly
Sounds great. - Original Message - From: peter reilly [EMAIL PROTECTED] To: Ant Developers List [EMAIL PROTECTED] Sent: Thursday, May 22, 2003 10:56 AM Subject: Re: antlib / proposal of Peter Reilly On Saturday 17 May 2003 19:59, Costin Manolache wrote: My main concern is the same as Conor's - having this decoupled and done in few steps. Ok I will chop it up into a sequence of patches. That means you have to start with add(Type), then anttypdef, then onerror. The first patch adds the add(Type) introspection method and implements this in condition, filterchain, tokenfilter, selector and path. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: antlib
On Thu, 22 May 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Reading this, and knowing that computearea and computeperimeter accept shapes as nested element, a build file writer would know that circle/ and square/ can be nested inside computearea/ and computeperimeter/. So roles make the antlib descriptor more expressive, this is true. I'm not sure that the build file writer is going to read the antlib descriptor, though. This descriptor also says that ShapeInterface should have a special meaning for ant, which for instance Serializable, Cloneable, ... do not necessarily have. OK. With roles, would an arbitrary implementation of ShapeInterface that was not bundled with the antlib and was not declared to be in role shape be accepted as nested element in computearea/? If the answer is yes, then roles would be optional and would mainly be used to make things more explicit, right? This is fine with me. Stefan
Re: antlib / proposal of Peter Reilly
On Thursday 22 May 2003 10:29, Stefan Bodewig wrote: On Thu, 22 May 2003, peter reilly [EMAIL PROTECTED] wrote: Ok I will chop it up into a sequence of patches. Thanks. The first patch adds the add(Type) introspection method and implements this in condition, filterchain, tokenfilter, selector and path. I'm +1 for this patch, and only have three nits, none of which require yet another patch IMHO: I have made the patch anyway... * I'd like to have a null check on obj in ComponentHelper.createComponent before passing it to project or invoking init on it. Yikes I was using old (pre-anttypedefinition) code - I had fixed this but .. * I'd like to see some more braces in one-line ifs 8-) Ok.. * some more @since tags would be nice (I said it would be nits ;-) Added some more .. Cheers, Peter
Re: antlib
Stefan Bodewig wrote : With roles, would an arbitrary implementation of ShapeInterface that was not bundled with the antlib and was not declared to be in role shape be accepted as nested element in computearea/? If the answer is yes, then roles would be optional and would mainly be used to make things more explicit, right? This is fine with me. Stefan It is perfectly possible to program ant so that roles are optional and just make things more explicit. Roles could be used to disambiguate situations where a component class implements several interfaces which have a meaning for ant, say Shape and Block for instance, and a task accepts both shapes and blocks as nested elements. I will gladly wait until the patches of Peter Reilly are committed before implementing roles. In this case, to fit to the wish of Costin to develop roles so that they exist also outside of antlibs, I would : 1 ) create a roledef task, 2 ) add an optional role attribute to typedef, 3 ) make changes in helper classes so that if a typedef has a role assigned to it, it is only accepted as a nested element in the add method taking the role interface as parameter. Antoine Antoine
RE: antlib
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] On Thu, 22 May 2003, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Reading this, and knowing that computearea and computeperimeter accept shapes as nested element, a build file writer would know that circle/ and square/ can be nested inside computearea/ and computeperimeter/. So roles make the antlib descriptor more expressive, this is true. I'm not sure that the build file writer is going to read the antlib descriptor, though. But remember we want to be able to say this same things inside build files so we can declare things not in antlibs. This descriptor also says that ShapeInterface should have a special meaning for ant, which for instance Serializable, Cloneable, ... do not necessarily have. OK. With roles, would an arbitrary implementation of ShapeInterface that was not bundled with the antlib and was not declared to be in role shape be accepted as nested element in computearea/? I would say you need to declare it as a shape or some other role-name defined by ShareInterface. The same way you need to declare something as a Task before you can use it as such. If the answer is yes, then roles would be optional and would mainly be used to make things more explicit, right? This is fine with me. Jose Alberto
Re: antlib
On Thu, 22 May 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] I'm not sure that the build file writer is going to read the antlib descriptor, though. But remember we want to be able to say this same things inside build files so we can declare things not in antlibs. OK. With roles, would an arbitrary implementation of ShapeInterface that was not bundled with the antlib and was not declared to be in role shape be accepted as nested element in computearea/? I would say you need to declare it as a shape or some other role-name defined by ShareInterface. Which means roles are not optional, even in a non-ambiguos case. What would be the benefit? The same way you need to declare something as a Task before you can use it as such. There are people who want to make this unnecessary 8-) Stefan
Re: antlib / proposal of Peter Reilly
On Mon, 19 May 2003, peter reilly [EMAIL PROTECTED] wrote: 1) are build script authors allowed to specify arbitary URIs for ant type definitions? I do not think this is a good idea. I've seen that Costin and Conor prefer that antlibs specify their URI themselves. Could anybody please explain why - and at the same time please also explain why user choice would be bad here? I feel I must be missing something. 2) what should ant do with URIs that it does not recognize? a) use current method - unknown elements b) ignore them c) explicty say that the ns uri is not supported d) convert them to Text in task/typedefs (the suggestion below) I'm on the fence between a) and b) and wouldn't like either c or d too much. Stefan
Re: antlib / proposal of Peter Reilly
On Wednesday 21 May 2003 08:21, Stefan Bodewig wrote: On Mon, 19 May 2003, peter reilly [EMAIL PROTECTED] wrote: 1) are build script authors allowed to specify arbitary URIs for ant type definitions? I do not think this is a good idea. I've seen that Costin and Conor prefer that antlibs specify their URI themselves. Could anybody please explain why - and at the same time please also explain why user choice would be bad here? I feel I must be missing something. I do not mind user choice, but I am concerned that allowing arbitary uris will restrict future devl. of ant. Because future interpretation of uris by ant may break build files that use those uris. 2) what should ant do with URIs that it does not recognize? a) use current method - unknown elements b) ignore them c) explicty say that the ns uri is not supported d) convert them to Text in task/typedefs (the suggestion below) I'm on the fence between a) and b) and wouldn't like either c or d too much. My code has ProjectHelper2 doing b) (ignoring them) but this could also be done by UnknownElement. Peter.
RE: antlib
From: Conor MacNeill [mailto:[EMAIL PROTECTED] On Wed, 21 May 2003 06:58 pm, Antoine Levy-Lambert wrote: I still think that the roles concept is good and I would like to make a separate proposal for roles. My idea would be along the following lines, supposing that ant is being used by specialists of geometry : taskdef name=computearea class=org.apache.demo.ComputeAreaTask/ taskdef name=computeperimeter class=org.apache.demo.ComputePerimeterTask/ roledef name=shape class=org.apache.demo.ShapeInterface/ typedef name=circle class=org.apache.demo.Circle role=shape/ typedef name=square class=org.apache.demo.Square role=shape/ How this would work : - taskdefs are normal, just to understand how this would be used - roledef : creates a hash table linking a role name with an interface - role attribute in typedef : do something so that introspectionhelper will translate addConfigured(org.apache.demo.ShapeInterface) in the ComputeAreaTask and ComputePerimeterTask into : Just to be clear, this was not Jose Alberto's original Role model proposal :-) There, I believe, it was the task (container) that implemented the interface, not the element being added. I am strongly against that approach. Well I have to say you are mistaken, in my proposal the task (container) implemented the addConfigured(InterfaceRole) method. The interface was for the thing being passed (the child element, after possibly some adaptor). With your approach, I wonder why we need all the machinery. Why not just do this: If a class supports addConfigured(ShapeInterface) AND we have a type circle for which there is no nested creator (addCircle, createCircle, etc) AND there is a global typedef of circle ANDthe typedef'd class for Circle is assignment compatible with ShapInterface Then instantiate org.apache.demo.Circle and pass it to the addConfigured method. With this approach there is no need for roledef, hashtables and you are not restricted to interface types. It should even work for mylib:newcircle :-) The reason had to do with been able to deal with object (classes) that may implement multiple interfaces. The code should not pick just any arbitrary interface for which it happens to be an addConfigured(Interface) in the container and just use it. If the object implements 5 interfaces for which we have addConfigured(InterfaceN) which one should we used? Definetly it should not be taken by chance. Part of the reason for the infrastructure is to try to minimize this cases and allow users to resolve when this issues arise. If your implementation class can be used to acomplish 5 different things then a well written antlib can give diferent names when roles may appear on the same task. Still you just have to maintain your one implementation class, but at the ANT level you provide 5 different roles. As I have always maintained, this approach only gives one point of flexibility in a task for a given type. If I have a ShapeMapper task which has a fromShape and a toShape, I can only use this technique to extend one of these elements. It is this reason why I prefer type specifiers. Nevertheless, perhaps both approachs can be supported and we would benefit from the syntactic niceness of not requiring type specifiers in many situations. The task writer could decide. For tasks which just need flexibility in one element add() or addConfigured() could be used while type specified could be available for tasks that need that flexibility. I have no problem with that. Although I wish we could explore if there are alternatives without the need for type-specifiers. But I do not hold my breath. Jose Alberto
RE: antlib
Antoine, Great job, I think you have sumarized alot of the discussion quite well. Thanks, Jose Alberto -Original Message- From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] Sent: 21 May 2003 09:58 To: Ant Developers List Subject: antlib I have prepared a few days ago some html pages located under http://ant.apache.org/projects/antlib/index.html They might be interesting if you want to read more about the proposal of Jose Alberto Fernandez. These pages do not explain yet the proposal of Peter Reilly due to the fact that I had prepared them right before Peter submitted it. I still think that the roles concept is good and I would like to make a separate proposal for roles. My idea would be along the following lines, supposing that ant is being used by specialists of geometry : taskdef name=computearea class=org.apache.demo.ComputeAreaTask/ taskdef name=computeperimeter class=org.apache.demo.ComputePerimeterTask/ roledef name=shape class=org.apache.demo.ShapeInterface/ typedef name=circle class=org.apache.demo.Circle role=shape/ typedef name=square class=org.apache.demo.Square role=shape/ How this would work : - taskdefs are normal, just to understand how this would be used - roledef : creates a hash table linking a role name with an interface - role attribute in typedef : do something so that introspectionhelper will translate addConfigured(org.apache.demo.ShapeInterface) in the ComputeAreaTask and ComputePerimeterTask into : addConfiguredCircle and addConfiguredSquare the role attribute would allow an expansion of the addConfigured method to suit different typedef names which are expected in the project. Antoine
Re: antlib
On Wed, 21 May 2003 08:31 pm, Jose Alberto Fernandez wrote:
Well I have to say you are mistaken, in my proposal the task (container)
implemented the addConfigured(InterfaceRole) method. The interface was
for the thing being passed (the child element, after possibly some
adaptor).
Well I am glad to hear I am wrong. Until 7 days ago, the code in your proposal
was this (Project.java)
public Object createInRole(Object container, String type) {
Class clz = container.getClass();
String roles[] = symbols.findRoles(clz);
Object theOne = null;
Method add = null;
It certainly implies the roles are associated with the Container class, not
the nested type name. findRoles is checking if
Role.isImplementedBy(container class).
Right now that method has been removed from Project.java and nothing I see
calls findRoles. Actually I don't really understand how the proposal
currently hangs together.
The reason had to do with been able to deal with object (classes) that may
implement multiple interfaces. The code should not pick just
any arbitrary interface for which it happens to be an
addConfigured(Interface) in the container and just use it. If the object
implements 5 interfaces for which we have addConfigured(InterfaceN) which
one should we used? Definetly it should not be taken by chance. Part of the
reason
for the infrastructure is to try to minimize this cases and allow users to
resolve when this issues arise.
Won't this be relatively rare (i.e. a class implementing multiple interfaces
being passed to a task accepting more than one of those interfaces)? If the
nested element is implementing multiple interfaces won't it also support
multiple roles? Or do I need to typedef the same class into two different
typenames, one for each role. So, if my circle also implements a
org.apache.demo.BlockInterface interface, will it support the block role.
Is it (extending Antoine's example)
roledef name=block class=org.apache.demo.BlockInterface/
typedef name=circle class=org.apache.demo.Circle role=shape, block/
or
roledef name=block class=org.apache.demo.BlockInterface/
typedef name=circle class=org.apache.demo.Circle role=shape/
typedef name=circleblock class=org.apache.demo.Circle role=block/
The first option would mean roles are no better at selecting a method than a
search based on the implemented interfaces. The second would be OK, but I
think we are getting pretty messy. An instance supporting multiple interfaces
can't be passed to different tasks using different interfaces. A circleblock
instance could not be passed to a task taking a ShapeInterface, because it is
not in that Role. A class supporting multiple interfaces is probably intended
to be used as both types of objects at different times.
How does the multiple role situation allow users to resolve when this issues
arise? What am I missing?
Overall, I still see it as a lot of complexity for the exceptional case.
Conor
Re: antlib
- Original Message -
From: Conor MacNeill [EMAIL PROTECTED]
To: Ant Developers List [EMAIL PROTECTED]
Sent: Wednesday, May 21, 2003 1:54 PM
Subject: Re: antlib
On Wed, 21 May 2003 08:31 pm, Jose Alberto Fernandez wrote:
Well I have to say you are mistaken, in my proposal the task (container)
implemented the addConfigured(InterfaceRole) method. The interface was
for the thing being passed (the child element, after possibly some
adaptor).
Well I am glad to hear I am wrong. Until 7 days ago, the code in your
proposal
was this (Project.java)
public Object createInRole(Object container, String type) {
Class clz = container.getClass();
String roles[] = symbols.findRoles(clz);
Object theOne = null;
Method add = null;
It certainly implies the roles are associated with the Container class,
not
the nested type name. findRoles is checking if
Role.isImplementedBy(container class).
Right now that method has been removed from Project.java and nothing I see
calls findRoles. Actually I don't really understand how the proposal
currently hangs together.
Conor, it is well possible that the proposal currently has some errors in
the code. I have had to do a lot of surgery on the proposal to make it
compile, without understanding fully a number of classes such as
ComponentHelper, IntrospectionHelper. Originally, these classes were in the
proposal; I had problems with them due to the evolution of Project.java in
the main branch, and I simply removed them - probably wrongly - from the
proposal.
The reason had to do with been able to deal with object (classes) that
may
implement multiple interfaces. The code should not pick just
any arbitrary interface for which it happens to be an
addConfigured(Interface) in the container and just use it. If the object
implements 5 interfaces for which we have addConfigured(InterfaceN)
which
one should we used? Definetly it should not be taken by chance. Part of
the
reason
for the infrastructure is to try to minimize this cases and allow users
to
resolve when this issues arise.
Won't this be relatively rare (i.e. a class implementing multiple
interfaces
being passed to a task accepting more than one of those interfaces)? If
the
nested element is implementing multiple interfaces won't it also support
multiple roles? Or do I need to typedef the same class into two different
typenames, one for each role. So, if my circle also implements a
org.apache.demo.BlockInterface interface, will it support the block
role.
Is it (extending Antoine's example)
roledef name=block class=org.apache.demo.BlockInterface/
typedef name=circle class=org.apache.demo.Circle role=shape,
block/
or
roledef name=block class=org.apache.demo.BlockInterface/
typedef name=circle class=org.apache.demo.Circle role=shape/
typedef name=circleblock class=org.apache.demo.Circle role=block/
The first option would mean roles are no better at selecting a method than
a
search based on the implemented interfaces. The second would be OK, but I
think we are getting pretty messy. An instance supporting multiple
interfaces
can't be passed to different tasks using different interfaces. A
circleblock
instance could not be passed to a task taking a ShapeInterface, because it
is
not in that Role. A class supporting multiple interfaces is probably
intended
to be used as both types of objects at different times.
How does the multiple role situation allow users to resolve when this
issues
arise? What am I missing?
Overall, I still see it as a lot of complexity for the exceptional case.
Conor
I would go for the second solution, that is define circle and circleblock as
two different xml tags.
It is one way to make sure that the right add method is called.
I would see another argument for roles. A Java class can implement a number
of interfaces, some of which are currently not relevant to ant for the
purpose of choosing an addConfiguredXYZ method. For instance, a datatype
could implement Cloneable, Serializable, etc and these interfaces are not
relevant for ant.
I do not see a lot of complexity in this role business. I don't think that
adding a role attribute in the typedef task will make things much heavier
for users. Probably ant users are never going to have a look at all these
typedef, taskdef, roledef and just use whatever is in their antlib
descriptor or in a resource file supplied with third party ant tasks and
datatypes.
The advantages of roles would be to allow a very deterministic style of
programming.
There would be however a half lazy solution :
- implement a roledef/ task such as
roledef name=shape class=org.apache.demo.ShapeInterface/
roledef name=block class=org.apache.demo.BlockInterface/
- and just rely on introspection to map typedefs to roles (that is to look
which interfaces the class of a typedef implements)
In this case, all components containing an
addConfiguredXYZ
Re: antlib / proposal of Peter Reilly
Stefan Bodewig wrote: On Mon, 19 May 2003, peter reilly [EMAIL PROTECTED] wrote: 1) are build script authors allowed to specify arbitary URIs for ant type definitions? I do not think this is a good idea. I've seen that Costin and Conor prefer that antlibs specify their URI themselves. Could anybody please explain why - and at the same time please also explain why user choice would be bad here? I feel I must be missing something. That's consistent with most of the current uses of XML namespaces - you don't see users picking their favorite XHTML or XSLT namespace URI. It's also about tools - things like autocompletion in an xml editor, transformations, etc. I can add more - but I'm curious about the reverse, why would you consider letting the users pick the namespace URI ? If someone looks at a build.xml file, and see an antlib:net.sf.contrib he'll probably know what tags are used and understand it. If he sees myFavoriteAntlib - and this is associated with contrib in some imported xml file - it'll be a bit harder ( he can still guess from the ifs ). Costin 2) what should ant do with URIs that it does not recognize? a) use current method - unknown elements b) ignore them c) explicty say that the ns uri is not supported d) convert them to Text in task/typedefs (the suggestion below) I'm on the fence between a) and b) and wouldn't like either c or d too much. Stefan
Re: antlib / proposal of Peter Reilly
Costin Manolache wrote: That's consistent with most of the current uses of XML namespaces - you don't see users picking their favorite XHTML or XSLT namespace URI. To elaborate on this: the original intention of namespaces was to provide universal names for elements. This means a:section xmlns:a=http://www.w3.org/1999/xhtml; is a XHTML section, which is diffferent from the docbook simplified section a:section xmlns:a=http://oasis.org/docbook; which is in turn different from every element with the local name section in any other namespace. Think of the namespace name (the URI, not the prefix) as part of the universal, galactic wide unique element name. (actual URIs for the samples above may differ). I can add more - but I'm curious about the reverse, why would you consider letting the users pick the namespace URI ? Indeed, especially considered that the namespace prefix may already be arbitrarily choosen. Picking the namespace URI (more correctly: the namespace name) makes only sense if semantics other than identification is associated with it. The crowd over there at XML-DEV consistently argues against this. It may seem natural to use the namespace name to point to something (i.e. use it for location rather than identification), but the namespace spec authors recommended to use URIs for namespace names because URIs are the closest things to universal names we currently have, and not because there's something interesting at the other end. The problem is that everyone expects something different at the other end of the namespace: some want to point it to a schema for the vocabulary, some like to find an XHTML description, others prefer some sort of RSS metadescription, and on this list, surprise, an implementation class or a Jar seems to be a favorite. J.Pietschmann
Re: antlib / proposal of Peter Reilly
peter reilly wrote: There are a number of issues here. 1) are build script authors allowed to specify arbitary URIs for ant type definitions? I do not think this is a good idea. I agree - I also preffer URIs that are interpreted in a certain way ( package names ), however we could support both. A URI that starts with antlib: will be parsed and the package used. Other URIs will be treated in a different way - either as arbitrary strings and matched against an explicit definition ( like the xml catalog ), or we may discover better things in future. 2) what should ant do with URIs that it does not recognize? a) use current method - unknown elements That seems the most reasonable and safe - it is what it does with unknown elements ( in no-namespace case ), I don't see why it should be different. b) ignore them c) explicty say that the ns uri is not supported d) convert them to Text in task/typedefs (the suggestion below) I would prefer b) as it allows other processing of the xml content - say in an xml processing pipeline. d) is also nice. 3) Should all processing outside Project/Target be done by PH2#ElementHandler? I think one should be able to plug in handlers for different URIs, or URI patterns. My UnknownUriHandler is an (possibly not very good) example. My preference would be to not put any more functionality in ProjectHelper2, but operate on the tree. PH2 should just create the tree. Costin
Re: antlib / proposal of Peter Reilly
Hi Costin,
I will reply to these e-mails separately, if this is ok.
On Saturday 17 May 2003 19:59, Costin Manolache wrote:
Sorry for the late reply, I had almost no acces to internet ( or time )
last week.
My main concern is the same as Conor's - having this decoupled and done
in few steps.
peter reilly wrote:
On Thursday 15 May 2003 07:56, Conor MacNeill wrote:
I would prefer to use the XML schema attribute for this.
Mmmm, this would be confusing as the XML schema attribute
has an associated URI http://www.w3.org/2001/XMLSchema; which
implies a lot more that a reference to an ant type.
Schema-style attributes - maybe. XMLShema itself is one of the worst
things in XML (IMO), I would preffer we stay as far away as possible - but
I'm ok with using some ideas.
I have done a quick review of you proposal. I wonder if we can split
this into smaller chunks to make it easier to understand and review. For
example, the onError stuff could be split out, as could the URL handling
code for separate consideration. Smaller chunks are easier to handle.
This is true, but difficult to do. Some of the implementations of the
different features change/improve if other features are present. For
example the implementation of onerror uses the new anttypedefintion
class. The implementation of the psuedo task antlib uses the add(Type)
mechanism rather than explicity stating addTypedef and addTaskdef, this
allowed other tasks that extend Definer to used in the antlib task (for
example a definer that wraps Runnable objects as ant tasks, or
a future implemation of roles).
That means you have to start with add(Type), then anttypdef, then onerror.
I could do this, but it would take a little time... The implementation
of add(Type) has been different after each of my updates...
One reason I combined them all together was to get a feeling on the
solution when all the pieces were in place.
Also from a practical point of view, I find it difficult to maintain
multiple patched ant versions.
I think we are talking about the main branch - so there is no
patched ant version to maintain. From a practical point of view, it
is much easier to review and accept smaller chunks.
Anyway, it seems to me that you have combined the namespace URI and
element names in certain places. Examples: In component helper changes,
for method createComponent, you say
the name of the component, if
the component is in a namespace, the
name is prefixed withe the namespace uri
dropping the antlib: and adding :.
Why not pass the URI and local name to the component helper and not have
to parse it out in componentHelper. Your approach also precludes URIs
that contain ':' (I know you disallow these elsewhere but I don't see
any reason to combine these, anyway)
Initially I was going to do this, but here is a lot of places in the code
that assume that a task/type is mapped from a string and not from the
tuple
{ns uri, local name}.
J.Pietschmann suggested in
http://marc.theaimsgroup.com/?l=ant-devm=105233644225128w=2
that one can use a mapping of {uri, name} to a string ns-uri+^+name
when migrating a project to namespaced XML.
I agree using a combined NS + Element may be simpler.
I would suggest ns-uri:name ( i.e. : instead of ^ ). It is easy to extract
the name with lastIndexOf(). It's just cosmetic, of course.
This is exactly what my patch on friday does :-).
My current mapping is not good as it drops the antlib: prefix and thus
excludes other uri prefixes, so I will change this. The current code does
exclude URI that contain :, this is a combination of a bug and by
design. The bug is that I should have used lastindexof and the design is
that the code only deals with NS URIs that start with antlib: for
type/task definitions. The code for the mapping should be done in one
place (maybe as a static method in ProjectHelper).
In any case, antlib: or any prefix should _never_ be used in resolutions.
Only the URI. The prefix is just a syntactic shortcut, the URI is the one
that matters.
I'm not sure where TaskAdapter went. createNewTask seems to return null
if the class is not a Task - probably handled somewhere else.
This is by design and for BC reasons. If the type class is not a Task,
and the type does not have an Adapter to a Task class, the
CM#createNewTask() will not create the class. taskdef/ will does this
(for example the condition task), and the unit tests contain an adapter
for Runnable objects. The code in CM does not treat TaskAdapter as a
special case.
I think taskdef should be treated as a special typedef with TaskAdapter
as adapter.
( i.e. use typedef as the main definition mechanism, and taskdef as
a shortcut for types with optional TaskAdapter adapters ).
This is exacty what taskdef is in the patch :-). It derives
from typedef and sets the adapterClass to TaskAdapter, and the adaptoClass
to Task. The
Re: antlib / proposal of Peter Reilly
On Saturday 17 May 2003 20:13, Costin Manolache wrote: peter reilly wrote: for example: typedef resource=org/acme/mydefinitions.xml classpath=classes/ to allow loading of tasks/types from different 3rd party with some tasks haveing the same name, I have added a prefix attribute. taskdef resource=net/sf/antcontrib/antcontrib.properties prefix=antcontrib./ taskdef resource=.../antelope.properties prefix=antelope/ What is the prefix doing ? Is it related with NS, or are you using it with non-namespaces ant ? I don't think it's a good idea to try to support both NS and prefix.element notation. For simple antfiles, just place all elements in the default NS ( i.e. no ns is used ). If name conflicts - use the standard mechanism to resolve name conflicts, which in XML is the namespaces. It would be confusing to have another way to solve name conflicts. +1 After playing with the code, I have found that the build script visible prefix is not needed and it is not a good idea (i.e. confusing). My current code has removed the prefix and antlib attributes to typedef. The uri attribute is left to allow the build script author to place the definitions in a different XML NS if required. Peter
RE: antlib / proposal of Peter Reilly
From: peter reilly [mailto:[EMAIL PROTECTED] On Saturday 17 May 2003 19:59, Costin Manolache wrote: I think taskdef should be treated as a special typedef with TaskAdapter as adapter. ( i.e. use typedef as the main definition mechanism, and taskdef as a shortcut for types with optional TaskAdapter adapters ). This is exacty what taskdef is in the patch :-). It derives from typedef and sets the adapterClass to TaskAdapter, and the adaptoClass to Task. The html page for taskdef in the friday patch makes this explicit. I have some WorkInProgress code to allow this to be specified in a buildfile. extendtype name=taskdef typedef adapter=org.apache.tools.ant.TaskAdapter adaptto=org.apache.tools.ant.Task/ /extendtype extendtype is a WIP name for a cut-down templating feature, it defines new types from other types with some attributes pre set. Well I am glad, you guys are rediscovering role definitions one feature at the time. :-) Jose Alberto
Re: antlib / proposal of Peter Reilly
On Saturday 17 May 2003 20:16, Costin Manolache wrote: Antoine Levy-Lambert wrote: I am having a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897 This proposal seems to address most of the points discussed in this mailing list concerning the antlib thread of discussion. I was thinking maybe we do not need to look further and we could commit this contribution ? I would be glad to hear your comments concerning : 1) the functionality provided by the contribution 2) the implementation I am quoting Peter Reilly here : This patch adds 4 new features (the code is interrelated, but may be split). * adapter attribute added to typedef +1 * add(Type) method added to introspection rules +1 * typedef can read an xml defintion file +1 - but I need further review of the XML DTD ( and maybe some changes ) * namespace support for xml defintions (antlib:) So one can do project xmlns:acme=org.acme.anttasks acme:hello path path=build.xml/ /acme:hello /project +1 We should also support the antlib classpath=cp resource=... uri=NSURI The above should be typedef classpath=cp resource=.. uri=NSURI/. The antlib task in my proposal is not meant to be used in a build script. acme:hellp xmlns:acme=NSURI This would allow arbitrary NSURIs ( for people who like meaning-free URIs) and allow the classpath association. I do not want meaning-free URIs. I want ant to ignore URIs that it does not understand. At the time of processing the typedef's uri, the parsing has been complete, so my rule is that uri's used in typedef/ have to start with antlib:. typedef classpath=cp resource=.. uri=antlib:arbitarystring/ where arbiratystring is an arbitary string, but the package from is treated specially with first encountered. An example of using other URIs is http://www.w3.org/TR/2003/WD-xhtml2-20030506/xhtml20_relax.html#a_xhtml20_relaxng I include an example in friday's patch: src/etc/testcases/xmlns.xml which is a build file and a html page. Peter
Re: antlib / proposal of Peter Reilly
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
Peter,
acme:hellp xmlns:acme=NSURI
This would allow arbitrary NSURIs ( for people who like
meaning-free URIs)
and allow the classpath association.
I do not want meaning-free URIs.
I want ant to ignore URIs that it does not understand.
At the time of processing the typedef's uri, the parsing has
been complete, so
my rule is that uri's used in typedef/ have to start with antlib:.
I don't quite see why it would be impossible to have meaning-free URIs.
Nothing is impossible..., but it is difficult to have meaning-free URIs and to
support (as in ignore) other URIs.
I would like ant to ignore other namespaces so that it is a civilized member
of the xml community.
For example the following specifies which processor deals with which
element tag:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo message=hello world/
h:html
h:bodyhello world/h:body
/h:html
/project
the above produces hello world as an ant script and hello world in an NS
aware browser.
I
think it makes perfectly sense. Namespaces are to avoid name clashes.
This is not the only reason for XML namespaces. The standard says
that are to allow elements and attributes that are defined for and used
by multiple software modules.
Ant
doesn't either force you to use certain Java package names when
implementing tasks.
Can't the typedef/ task just add another antlib to the Project?
? this is what typedef/ does
typedef classpath=cp resource=.. uri=antlib:arbitarystring/
where arbiratystring is an arbitary string, but the
package from is
treated specially with first encountered.
I think an URI like antlib:arbitarystring is quite confusing as well.
I would agree with you here. Maybe another pattern could be allowed?
I only have a problem with an arbitrary uri ;-)
IMO
an URI starting with antlib: should always mean that the following
denotes a package with that antlib. What would happen if I had a Java
package on the classpath called arbitarystring?
The definitions are appended to the definitions defined in {converted
package}/antlib.xml.
This is the same behaviour as definitions going into the default namespace.
Peter
RE: antlib / proposal of Peter Reilly
From: peter reilly [mailto:[EMAIL PROTECTED]
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
I don't quite see why it would be impossible to have
meaning-free URIs.
Nothing is impossible..., but it is difficult to have
meaning-free URIs and to
support (as in ignore) other URIs.
I would like ant to ignore other namespaces so that it is a
civilized member
of the xml community.
For example the following specifies which processor deals with which
element tag:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo message=hello world/
h:html
h:bodyhello world/h:body
/h:html
/project
the above produces hello world as an ant script and hello
world in an NS
aware browser.
I really think this is the very worst that we can do to ANT.
The above example is nore than just confusing, it seem to me
quite meaningless. I can see situations where could be valid
for ANT not to interpret another NS but not just plain ignore it.
For example it would be nice if I could write the following:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo file=out.html
h:html
h:bodyhello world/h:body
/h:html
/echo
/project
with the result being a file out.html containing:
h:html xmlns:h=http://www.w3.org/1999/xhtml;
h:bodyhello world/h:body
/h:html
But in here we are not ignoring the XHTML, instead we are
able to interpret it to be equivalent to TEXT for the purpose
of parsing. Which is not the same.
BTW, this is what things like XSLT do when you use other namespaces.
I
think it makes perfectly sense. Namespaces are to avoid
name clashes.
This is not the only reason for XML namespaces. The standard says
that are to allow elements and attributes that are defined
for and used
by multiple software modules.
Besides of the issue of how to completly ignore things (as you wanted above)
all your different NS that you force people to use (all the diferent antlib:xxx)
are all process by the same software module (i.e., ANT).
The thing I do not like is that it continues forcing us to have a CORE
which has special rules to manage its special NS and any other libraries
which are force to use NS designators.
Moreover, it means that until the end of time we will have to continue
shipping ANT as a monolitic gigantic antlib containing every definition
for CORE and OPTIONAL tasks. Why? Because that is the only way to have
them all using the default namespace.
If instead we use uninterpreted URIs which are only there for collision solving
then we can chop things in reasonable componets and still being able to
use them in a backward compatible manner.
IMO
an URI starting with antlib: should always mean that the following
denotes a package with that antlib. What would happen if I
had a Java
package on the classpath called arbitarystring?
The definitions are appended to the definitions defined in {converted
package}/antlib.xml.
This is the same behaviour as definitions going into the
default namespace.
In your example above you use 'xmlns=ant:core' instead of
'xmlns=antlib:org.apache.tools.ant...'
so it does not seem to be the same behaviour, there is something magical about
CORE.
If you were to tell me that there is some sort of implicit
'xmlns=antlib:' for the core
that I could accept, but I really dislike having some other special notation.
Notice that in Java, the only special thing about the language is the it
provides
an implicit 'import java.lang.*;' that is all, appart from that the language
makes
absolutely no distinctions between Java CORE and any third party libraries.
Everybody plays by exactly the same rules.
That is what I would like to achieve at the end of this exercise.
Jose Alberto
Re: antlib / proposal of Peter Reilly
Yikes!!
There are a number of issues here.
1) are build script authors allowed to specify arbitary
URIs for ant type definitions?
I do not think this is a good idea.
2) what should ant do with URIs that it does not recognize?
a) use current method - unknown elements
b) ignore them
c) explicty say that the ns uri is not supported
d) convert them to Text in task/typedefs (the suggestion below)
I would prefer b) as it allows other processing of the xml content -
say in an xml processing pipeline. d) is also nice.
3) Should all processing outside Project/Target be done by PH2#ElementHandler?
I think one should be able to plug in handlers for different URIs, or URI
patterns. My UnknownUriHandler is an (possibly not very good) example.
On Monday 19 May 2003 15:33, Jose Alberto Fernandez wrote:
From: peter reilly [mailto:[EMAIL PROTECTED]
On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
I don't quite see why it would be impossible to have
meaning-free URIs.
Nothing is impossible..., but it is difficult to have
meaning-free URIs and to
support (as in ignore) other URIs.
I would like ant to ignore other namespaces so that it is a
civilized member
of the xml community.
For example the following specifies which processor deals with which
element tag:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo message=hello world/
h:html
h:bodyhello world/h:body
/h:html
/project
the above produces hello world as an ant script and hello
world in an NS
aware browser.
I really think this is the very worst that we can do to ANT.
He came, He saw, He destroyed...
Some xml applications ignore content outside its domain, some
do not..
The above example is nore than just confusing, it seem to me
quite meaningless. I can see situations where could be valid
for ANT not to interpret another NS but not just plain ignore it.
For example it would be nice if I could write the following:
project xmlns:h=http://www.w3.org/1999/xhtml;
xmlns=ant:core
echo file=out.html
h:html
h:bodyhello world/h:body
/h:html
/echo
/project
with the result being a file out.html containing:
h:html xmlns:h=http://www.w3.org/1999/xhtml;
h:bodyhello world/h:body
/h:html
But in here we are not ignoring the XHTML, instead we are
able to interpret it to be equivalent to TEXT for the purpose
of parsing. Which is not the same.
BTW, this is what things like XSLT do when you use other namespaces.
I
think it makes perfectly sense. Namespaces are to avoid
name clashes.
This is not the only reason for XML namespaces. The standard says
that are to allow elements and attributes that are defined
for and used
by multiple software modules.
Besides of the issue of how to completly ignore things (as you wanted
above) all your different NS that you force people to use (all the diferent
antlib:xxx) are all process by the same software module (i.e., ANT).
No, I think that URI handlers should be pluggable in and not all
XML should be processed via the ElementHandler / UnknownElement /
IntrospectionHandler and RuntimeConfigurable classes.
XML NS Uri's introducded via antlib/typedef should be processed via
the ANT software module (in my view). But other sources - for example
Mbean support may use a different collection of classes.
The thing I do not like is that it continues forcing us to have a CORE
which has special rules to manage its special NS and any other libraries
which are force to use NS designators.
Moreover, it means that until the end of time we will have to continue
shipping ANT as a monolitic gigantic antlib containing every definition
for CORE and OPTIONAL tasks. Why? Because that is the only way to have
them all using the default namespace.
If instead we use uninterpreted URIs which are only there for collision
solving then we can chop things in reasonable componets and still being
able to use them in a backward compatible manner.
I do not follow your argument here. What difference do uninterpreted URIs
make to the ANT being an gigantic antlib?
IMO
an URI starting with antlib: should always mean that the following
denotes a package with that antlib. What would happen if I
had a Java
package on the classpath called arbitarystring?
The definitions are appended to the definitions defined in {converted
package}/antlib.xml.
This is the same behaviour as definitions going into the
default namespace.
In your example above you use 'xmlns=ant:core' instead of
'xmlns=antlib:org.apache.tools.ant...' so it does not seem to be the same
behaviour, there is something magical about CORE.
Initially I had the default being antlib:org.apache.tools.ant.., but I
dropped that for two reasons:
1) for bc reasons, the definitions defined by typedef or
at start up (copy, concat...)
Re: antlib / proposal of Peter Reilly
Sorry for the late reply, I had almost no acces to internet ( or time )
last week.
My main concern is the same as Conor's - having this decoupled and done
in few steps.
peter reilly wrote:
On Thursday 15 May 2003 07:56, Conor MacNeill wrote:
I would prefer to use the XML schema attribute for this.
Mmmm, this would be confusing as the XML schema attribute
has an associated URI http://www.w3.org/2001/XMLSchema; which
implies a lot more that a reference to an ant type.
Schema-style attributes - maybe. XMLShema itself is one of the worst
things in XML (IMO), I would preffer we stay as far away as possible - but
I'm ok with using some ideas.
I have done a quick review of you proposal. I wonder if we can split this
into smaller chunks to make it easier to understand and review. For
example, the onError stuff could be split out, as could the URL handling
code for separate consideration. Smaller chunks are easier to handle.
This is true, but difficult to do. Some of the implementations of the
different features change/improve if other features are present. For
example the implementation of onerror uses the new anttypedefintion
class. The implementation of the psuedo task antlib uses the add(Type)
mechanism rather than explicity stating addTypedef and addTaskdef, this
allowed other tasks that extend Definer to used in the antlib task (for
example a definer that wraps Runnable objects as ant tasks, or
a future implemation of roles).
That means you have to start with add(Type), then anttypdef, then onerror.
Also from a practical point of view, I find it difficult to maintain
multiple patched ant versions.
I think we are talking about the main branch - so there is no
patched ant version to maintain. From a practical point of view, it
is much easier to review and accept smaller chunks.
Anyway, it seems to me that you have combined the namespace URI and
element names in certain places. Examples: In component helper changes,
for method createComponent, you say
the name of the component, if
the component is in a namespace, the
name is prefixed withe the namespace uri
dropping the antlib: and adding :.
Why not pass the URI and local name to the component helper and not have
to parse it out in componentHelper. Your approach also precludes URIs
that contain ':' (I know you disallow these elsewhere but I don't see any
reason to combine these, anyway)
Initially I was going to do this, but here is a lot of places in the code
that assume that a task/type is mapped from a string and not from the
tuple
{ns uri, local name}.
J.Pietschmann suggested in
http://marc.theaimsgroup.com/?l=ant-devm=105233644225128w=2
that one can use a mapping of {uri, name} to a string ns-uri+^+name
when migrating a project to namespaced XML.
I agree using a combined NS + Element may be simpler.
I would suggest ns-uri:name ( i.e. : instead of ^ ). It is easy to extract
the name with lastIndexOf(). It's just cosmetic, of course.
My current mapping is not good as it drops the antlib: prefix and thus
excludes other uri prefixes, so I will change this. The current code does
exclude URI that contain :, this is a combination of a bug and by
design. The bug is that I should have used lastindexof and the design is
that the code only deals with NS URIs that start with antlib: for
type/task definitions. The code for the mapping should be done in one
place (maybe as a static method in ProjectHelper).
In any case, antlib: or any prefix should _never_ be used in resolutions.
Only the URI. The prefix is just a syntactic shortcut, the URI is the one
that matters.
I'm not sure where TaskAdapter went. createNewTask seems to return null
if the class is not a Task - probably handled somewhere else.
This is by design and for BC reasons. If the type class is not a Task, and
the type does not have an Adapter to a Task class, the CM#createNewTask()
will not create the class. taskdef/ will does this (for example the
condition task), and the unit tests contain an adapter for Runnable
objects. The code in CM does not treat TaskAdapter as a special case.
I think taskdef should be treated as a special typedef with TaskAdapter
as adapter.
( i.e. use typedef as the main definition mechanism, and taskdef as
a shortcut for types with optional TaskAdapter adapters ).
For the most part it looks OK to me. I'd need to look more closely to
fully comprehend it but thought you might like some feedback.
Same here. If it can be split into smaller pieces - you have my +1 on the
overal proposal ( each piece will be reviewed separately and may need some
changes based on the review ).
Costin
Re: antlib / proposal of Peter Reilly
peter reilly wrote: for example: typedef resource=org/acme/mydefinitions.xml classpath=classes/ to allow loading of tasks/types from different 3rd party with some tasks haveing the same name, I have added a prefix attribute. taskdef resource=net/sf/antcontrib/antcontrib.properties prefix=antcontrib./ taskdef resource=.../antelope.properties prefix=antelope/ What is the prefix doing ? Is it related with NS, or are you using it with non-namespaces ant ? I don't think it's a good idea to try to support both NS and prefix.element notation. For simple antfiles, just place all elements in the default NS ( i.e. no ns is used ). If name conflicts - use the standard mechanism to resolve name conflicts, which in XML is the namespaces. It would be confusing to have another way to solve name conflicts. Costin
Re: antlib / proposal of Peter Reilly
Antoine Levy-Lambert wrote: I am having a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897 This proposal seems to address most of the points discussed in this mailing list concerning the antlib thread of discussion. I was thinking maybe we do not need to look further and we could commit this contribution ? I would be glad to hear your comments concerning : 1) the functionality provided by the contribution 2) the implementation I am quoting Peter Reilly here : This patch adds 4 new features (the code is interrelated, but may be split). * adapter attribute added to typedef +1 * add(Type) method added to introspection rules +1 * typedef can read an xml defintion file +1 - but I need further review of the XML DTD ( and maybe some changes ) * namespace support for xml defintions (antlib:) So one can do project xmlns:acme=org.acme.anttasks acme:hello path path=build.xml/ /acme:hello /project +1 We should also support the antlib classpath=cp resource=... uri=NSURI acme:hellp xmlns:acme=NSURI This would allow arbitrary NSURIs ( for people who like meaning-free URIs) and allow the classpath association. Costin
Re: antlib / proposal of Peter Reilly
On Thu, 15 May 2003 12:56 am, peter reilly wrote: I have merged the ant-type code into my antlib code. However it uses a magic attribute name ant-type to achieve the effect and not as discussed before - the namesspaced attribute name like - ant:type. I can easily do a name-spaced attribute name for this, however if this is done there will be only one object in the xml name space uri - type. Would this be reasonable? I would prefer to use the XML schema attribute for this. I have done a quick review of you proposal. I wonder if we can split this into smaller chunks to make it easier to understand and review. For example, the onError stuff could be split out, as could the URL handling code for separate consideration. Smaller chunks are easier to handle. Anyway, it seems to me that you have combined the namespace URI and element names in certain places. Examples: In component helper changes, for method createComponent, you say the name of the component, if the component is in a namespace, the name is prefixed withe the namespace uri dropping the antlib: and adding :. Why not pass the URI and local name to the component helper and not have to parse it out in componentHelper. Your approach also precludes URIs that contain ':' (I know you disallow these elsewhere but I don't see any reason to combine these, anyway) I'm not sure where TaskAdapter went. createNewTask seems to return null if the class is not a Task - probably handled somewhere else. I'm not sure about addType methods. It usually limits only one element to being extensible - consider a task taking two filesets for different reasons. OTOH, I guess a lot can be done with it. The element names in IntrospectionHelper would need to have URIs as well, won't they? For the most part it looks OK to me. I'd need to look more closely to fully comprehend it but thought you might like some feedback. Conor
Re: antlib / proposal of Peter Reilly
On Thursday 15 May 2003 07:56, Conor MacNeill wrote:
On Thu, 15 May 2003 12:56 am, peter reilly wrote:
I have merged the ant-type code into my antlib code.
However it uses a magic attribute name ant-type to
achieve the effect and not as discussed before - the
namesspaced attribute name like - ant:type.
I can easily do a name-spaced attribute name for this,
however if this is done there will be only one object in
the xml name space uri - type. Would this be reasonable?
I would prefer to use the XML schema attribute for this.
Mmmm, this would be confusing as the XML schema attribute
has an associated URI http://www.w3.org/2001/XMLSchema; which
implies a lot more that a reference to an ant type.
I have done a quick review of you proposal. I wonder if we can split this
into smaller chunks to make it easier to understand and review. For
example, the onError stuff could be split out, as could the URL handling
code for separate consideration. Smaller chunks are easier to handle.
This is true, but difficult to do. Some of the implementations of the
different features change/improve if other features are present. For
example the implementation of onerror uses the new anttypedefintion
class. The implementation of the psuedo task antlib uses the add(Type)
mechanism rather than explicity stating addTypedef and addTaskdef, this
allowed other tasks that extend Definer to used in the antlib task (for
example a definer that wraps Runnable objects as ant tasks, or
a future implemation of roles).
Also from a practical point of view, I find it difficult to maintain multiple
patched ant versions.
Anyway, it seems to me that you have combined the namespace URI and element
names in certain places. Examples: In component helper changes, for method
createComponent, you say
the name of the component, if
the component is in a namespace, the
name is prefixed withe the namespace uri
dropping the antlib: and adding :.
Why not pass the URI and local name to the component helper and not have to
parse it out in componentHelper. Your approach also precludes URIs that
contain ':' (I know you disallow these elsewhere but I don't see any reason
to combine these, anyway)
Initially I was going to do this, but here is a lot of places in the code
that assume that a task/type is mapped from a string and not from the tuple
{ns uri, local name}.
J.Pietschmann suggested in
http://marc.theaimsgroup.com/?l=ant-devm=105233644225128w=2
that one can use a mapping of {uri, name} to a string ns-uri+^+name
when migrating a project to namespaced XML.
My current mapping is not good as it drops the antlib: prefix and thus
excludes other uri prefixes, so I will change this. The current code does
exclude URI that contain :, this is a combination of a bug and by design.
The bug is that I should have used lastindexof and the design is that
the code only deals with NS URIs that start with antlib: for type/task
definitions. The code for the mapping should be done in one place (maybe
as a static method in ProjectHelper).
I'm not sure where TaskAdapter went. createNewTask seems to return null if
the class is not a Task - probably handled somewhere else.
This is by design and for BC reasons. If the type class is not a Task, and
the type does not have an Adapter to a Task class, the CM#createNewTask()
will not create the class. taskdef/ will does this (for example the
condition task), and the unit tests contain an adapter for Runnable objects.
The code in CM does not treat TaskAdapter as a special case.
I'm not sure about addType methods. It usually limits only one element to
being extensible - consider a task taking two filesets for different
reasons. OTOH, I guess a lot can be done with it.
The add[Configured](Type) methods are meant more for container like objects -
like the antlib task, the filterchain type or the condition base class. It
also allows custom extensions (e.g. new conditions) to be dropped in by third
party classes without special treatment.
The polymorphic feature is I think to be used for fixed elements in objects
that are not containers - the javac src/ nested element for example.
javac...
src ant-type=... .../
(or
src poly:type=... .. xmlns:poly=ant poly uri/)
/javac
The element names in
IntrospectionHelper would need to have URIs as well, won't they?
UnknownElement converts the {uri,name} to a componentname before
calling IH#createElement()
For the most part it looks OK to me. I'd need to look more closely to fully
comprehend it but thought you might like some feedback.
Thanks, and cheers.
Peter
Re: antlib / proposal of Peter Reilly
This is true, but difficult to do. Some of the implementations of the different features change/improve if other features are present. For example the implementation of onerror uses the new anttypedefintion class. The implementation of the psuedo task antlib uses the add(Type) mechanism rather than explicity stating addTypedef and addTaskdef, this allowed other tasks that extend Definer to used in the antlib task (for example a definer that wraps Runnable objects as ant tasks, or a future implemation of roles). Also from a practical point of view, I find it difficult to maintain multiple patched ant versions. True The add[Configured](Type) methods are meant more for container like objects - like the antlib task, the filterchain type or the condition base class. It also allows custom extensions (e.g. new conditions) to be dropped in by third party classes without special treatment. This (addConfigured) is important for antlibs to work. Antoine
RE: antlib / proposal of Peter Reilly
From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] I am having a look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19897 This proposal seems to address most of the points discussed in this mailing list concerning the antlib thread of discussion. I was thinking maybe we do not need to look further and we could commit this contribution ? I would be glad to hear your comments concerning : 1) the functionality provided by the contribution 2) the implementation Well I have not given the fight on the need for roles and separate symbol-tables for different Types. I would like for someone to explain how ejbjar, jspc, serverdeploy can have vendor dependent weblogic, jboss, etc. within this model. I am quoting Peter Reilly here : This patch adds 4 new features (the code is interrelated, but may be split). * adapter attribute added to typedef * add(Type) method added to introspection rules * typedef can read an xml defintion file * namespace support for xml defintions (antlib:) So one can do project xmlns:acme=org.acme.anttasks acme:hello path path=build.xml/ /acme:hello /project where the class path contains the org/acme/anttasks/antlib.xml and the antlib.xml file contains: antlib typedef name=hello classname=org.acme.anttasks.Hello/ /antlib As I have mentioned before, I have problems with this. It means that users are forced to use name spaces even if there are no collisions on the names of the components in the antlib, just because there is no way to find the antlib.xml otherwise. I do not see an antlib task specified in the project, does that means that I need to put all the jars in the classpath of ANT? I hope that is not a requirement. I think users need to be able to specify the classpath they want to use for their libraries just like they do for taskdef. ToDo: add in support for ant-type polymorphism and addConfigured(Type). also more error checking and unit tests. ant-type polymorphism is not a priority for me, but addConfigured support is. Given the fact that the objects being passed are opaque for all purposes of the parent element, it makes little sense to pass an uninitialized object to the parent (which is what add(Type) does) instead of passing an initialized object (what addConfigured(Type) should do). Jose Alberto
