Re: @author tag recommendation
To put things in a different perspective - Software is written by people. We donate our work and time to ASF, but I don't think that owning the copyright and all the rights on the code gives ASF the right to remove the author names from their work. As for the legal argument that is constantly used by ASF board to justify anything - if signing on the code I write exposes me to legal risks, I am willing to take them. There are plenty of open source projects where developers keep both attribution and copyright on their code. If ASF lawyers consider that non-anonymous code is threatening the foundation - perhaps it needs better lawyers. Letting fear to drive an open source project is IMO a very bad management. Costin Dirk-Willem van Gulik wrote: On Mar 15, 2004, at 11:49 PM, Conor MacNeill wrote: As a result, I would like to open a discussion on the ant-dev list to see the impact of this change in policy, particularly on non-committers - i.e. the people who make the odd, but important, contribution to the project, people who may become stronger contributors in the longer term. (recycling an older cocoon post with some edits) One way to look at this is that @author tags are in a way factually 'wrong'; in most cases it just signals which person wrote the first skeleton of that code; but subsequently it was fixes, peer-reviewed and looked at by a whole community. Also do not forget the many people in your community which help with QA, Documentation, user-feedback and so on. To put one person in the (hot) seat for what is essentially a group effort is perhaps not quite right. Secondly what we 'sell' as the ASF brand is a code base which is peer reviewed, quality controlled and created by a sustainable group which will survive the coming and going of volunteers. One where knowledge is generally shared and not just depended on one single individual. This is one of the key reasons why large companies, governments, etc have a lot less qualms about using apache than using most other open source; we mitigate the worry that it depends on a single person, and can implode or fork without warning, right from the get-go. Finally - a lot of developers do live in countries where you can get sued. The ASF can provide a certain level of protection; but this is based on the KEY premisse that there is oversight and peer review. That what we ship is a _community_ product; and that everything is backed by the community and cannot be attributed to a single person. Every commit gets peer review; ever release requires +1s' and are backed by the community as a whole. @author tags are by necessity incomplete and thus portrait the situation inaccurately. Any hint or suggestion that parts of the code are not a community product makes defence more complex and expensive. We do not want to temp anyone - but rather present a clean picture with no blemishes or easy targets. And to give this a positive slant; be -proud- of this culture; be proud of being part of something larger of incredible quality. Each of you did not just write a few pesky lines of code surrounded by an @author tag; but where instrumental in getting the -whole- thing work ! And if you are ever trying to understand why cocoon made it this far, and other commercial/open-source projects did not, then do look there; quality and a sense of long term stability. Now the above is not normative - it is just some background, some food for thought and sets a few boundaries[1]. However the ASF has many different communities - and each is responsible for their own code, their own working habits and their own slant on ASF culture. So if for example people here feel strongly that, say, people doing Docs, Translations, QA, release management or bug fixing should be more celebrated then go for it ! Take Care, Have fun, Dw 1:One of the hard boundaries is (to repeat from above) that the ASF release procedure is based on the KEY premisse that there is oversight and peer review. That what we ship is a foundation product; and that everything is backed by the committers, that CLA or software grants are on file, that every commit gets peer review; that releases requires +1s' and are backed by a community process which leaves a paper trail in CVS and on the archived mailing lists. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant CONTRIBUTORS
costin 2004/03/13 00:29:26 Modified:.CONTRIBUTORS Log: Removing my name Revision ChangesPath 1.2 +0 -1 ant/CONTRIBUTORS Index: CONTRIBUTORS === RCS file: /home/cvs/ant/CONTRIBUTORS,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- CONTRIBUTORS 9 Mar 2004 17:26:39 - 1.1 +++ CONTRIBUTORS 13 Mar 2004 08:29:26 - 1.2 @@ -23,7 +23,6 @@ Christopher Charlier Christoph Wilhelms Conor MacNeill -Costin Manolache Craeg Strong Craig Cottingham Craig R. McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Task for the new Pack200 format
Jose Alberto Fernandez wrote: What do people think? I will wait to see what are we interested on doing before aproaching Bill. I know him from my time at Maryland, hope he still remembers me. I'm very interested. If we do get an implementation for JDK1.2 - then it makes sense to have it in the core, so we can unpack antlibs with it :-) ( a better target would be CDC - not JDK1.2 :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Microsoft XML scripting patent
[EMAIL PROTECTED] wrote:
Not only scriptdef. You can do the same (storing) with
target name= description=
script language=
![CDATA[
]]
/script
/target
Exactly, the patent descibes the contents of the ant script
manual page:
http://ant.apache.org/manual/OptionalTasks/script.html
Peter
And on [1] you can see, that´s very old. First version on that location
is from Feb 2001, ANT_13_BRANCH and I think you can find older one...
The version from Feb 2001 [2] contains all these infos I used in the
example.
It seems to be filed in 2000 ( Dec ), so feb 2001 is not old enough for
prior art.
I think JSP have used scriptlets before 2000 - but with %, not proper
XML, and only one language. However I remember variants of JSP using
script language=, with javascript or some other languages.
I don't remember when I've seen the first demo of JSPs using javascript
and VB ( Sam Ruby may know - he was there :-), it should be about the
same time.
It seems like yet another broad patent on common technology...
Maybe Conor could ask the board ?
Costin
Jan
[1]
http://cvs.apache.org/viewcvs.cgi/ant/docs/manual/OptionalTasks/script.html
[2]
http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/docs/manual/OptionalTasks/s
cript.html?content-type=text%2Fplainrev=1.1.2.1
Does the ASF have a layer to check that?
Jan
-Original Message-
From: Antoine Lévy-Lambert [mailto:[EMAIL PROTECTED]
Sent: Friday, February 13, 2004 3:14 PM
To: Ant Developers List
Subject: Re: Microsoft XML scripting patent
[EMAIL PROTECTED] wrote:
So, it sound not like a pattent on scripting, but on
how to store collections of scripts in one file and being
able to execute them.
target as collection of scripts?
Jan
The example provided on the web page showing MS's patent
show an xml
file containing a .bat file and a .vbs script, both
rewritten in some
xml format.
As someone else wrote, it is a little bit like an ant script with
several scriptdefs in it.
The MS patent talks about specific XML elements :
collection
file extension=.bat
commands
/file
/collection
I do not know whether their patent only applies to XML
scripts written
using this particular schema ? Or does the patent claim to
protect *all*
use of XML for scripts, and particularly this particular document
structure ?
Antoine
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HIT
OFFp=1u=/netahtml/search-bool.htmlr=1f=Gl=50co1=ANDd=pt
xts1=XML.ABST.s2=Microsoft.ASNM.OS=ABST/XML+AND+AN/Microsof
tRS=ABST/XML+AND+AN/Microsoft
19. In a computer system having one or more scripts written
in one or
more scripting languages, a computer readable having stored
thereon a
data structure for encompassing the one or more scripts
into a single
file, the data structure comprising:
a file element field for each of the one or more scripts,
wherein each
file element field delimits one of the one or more scripts;
an extension attribute field included in each file element field,
wherein the extension attribute field identifies a
scripting language;
a code element field included within each file element
field, wherein
the code element field contains script instructions in the
scripting
language identified in the extension attribute field;
a name element field within each file element field,
wherein the name
element field contains a descriptive name; and
a description element field within each file element field,
wherein the
description element field contains a functional description.
wherein the data structure is configured to be parsed by a
parser into a
list for presentation to a user and that includes an
identifier for each
of the one or more scripts, the identifier comprising the
descriptive
name and functional description of each script.
20. A data structure as defined in claim 19, further
comprising a CDATA
element field within the code element field, wherein the
CDATA element
field precludes data within the CDATA element field from being
recognized as a format of the data structure.
21. A data structure as defined in claim 19, wherein the file
elements
for the one or more scripts are delimited by a collection element,
wherein the collection element is a root of the file.
...
-
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: Ant 2.0
Steve Loughran wrote:
I know Ant2.0-the-rewrite is essentially dead (and essentially obsolete
through evolution in the codebase), but I still think we ought to
consider using the name as and when the time is appropriate. If we add
enough interesting stuff to 1.7, it could be the time.
Please, not again :-)
One thing that was voted on (positively, I recall), way way back in
time, was for Ant2.0 to fail on undefined properties.
Having just struggled with a build file refactor that introduced the
problem, a problem I only dealt with by resorting to IntelliJ's
property-aware ant file editor, I am starting to think the
fail-on-undefined property mechanism is good.
But at the same time, those echo statements with undefined properties
are ubiquitous, and they need to stay in. And we need the option of
turning strict property evaluation off or on.
My preferred way to do this would be to
1. either or both of
a new command line option,
a new property to set.
to turn strict property evaluation on.
The nice thing about these two is that they can be applied to existing
files. The property set tactic would let you use build.properties to set
the flag, and enable inline in projects that will still work in ant 1.6,
but get complex w/ ant and antcall
2. in strict mode, any expansion of a unknown property into a string
would throw a BuildException
3. But there would be a non-throwing expansion method for code that
explicitly wanted to not fail on missing strings in their .
4. echo, fail and a few others would be modified to use the new non
throwing expansion mechanism.
The problem with this is that while
echo${undefined}/echo would work as intended,
echo message=${undefined} / would always throw an exception.
The only fix there would be a new datatype NonvalidatingString() that
would expand properties but not bail.
Would that be enough? Would it work and be usable?
What about just displaying a warning Use of undefined property foo at
line xxx instead of failing ?
I suppose the problem was that undefined properties were just ignored,
and you had a hard time debugging this ( I had similar problems many
times ).
I would preffer a warning for undefined properties outside echo/fail
instead of the option to fail - since in the second case it may fail in
too many build.xml files, forcing people to just disable it.
Costin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: auto download of antlibs
Steve Loughran wrote: OK, now that Ant1.6 has antlibs, it is time to think of the next step: auto download of antlibs and (perhaps) dependencies. 1. Possible requirements -allow users to specify the URLs of dependent antlibs -allow teams to provide an override point that specifies their location -secure download -only files from trusted sources are fetched. Signed jars ? -caching of downloads, global or per-user -go through proxies -allow antlib providers to move their files (handle redirects) Is this really needed ? -allow antlib providers to mirror, by having a mirror file that lists possible sources I would add: support for sourceforge-like mirrors and click repositories. -support private repositories (intranet/internet, https, authenticated) as well as public sources -make it easy to publish an antlib, and register it in the ant central list And if possible, a single central list :-) Anything else? - support for multiple repository types ? It would be really nice if the tool would be able to fetch RPM/APT dependencies ( from jpackage or a similar repo ), as well as maven and other descriptors. 2. What things implement this? What do Maven and Ruper do? 3. do we want to integrate this with ant, or have some more standalone tool that can be used to keep a component repository up to date, a tool with an ant task for use in a build file. A sort of apt-get for apache stuff... I think having this bundled/integrated with ant would be an excelent idea ! Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 2.0
Steve Loughran wrote: I suppose the problem was that undefined properties were just ignored, and you had a hard time debugging this ( I had similar problems many times ). you can get those messages if you crank up the verbosity, but you still need to go through the lines and look at them. I suppose if we had a better listener model then I could run a listener to filter for the relevant message topic and highlight them. We can increase the level ( warn ? ) and make them more visible ( caps, underline, etc ). Actually - one of the problems I have with the current ant logging is that the default verbosity is a bit too big and sometimes hard to follow. It would be nice if warnings would display the build file and line number, and some progress events ( like targets with no output ) would be moved to verbose. I tought commons-logging logger is a solution, but it's too complicated to configure. I would preffer a warning for undefined properties outside echo/fail instead of the option to fail - since in the second case it may fail in too many build.xml files, forcing people to just disable it. I'd have the default of non-strict; fail-on-undefined would be an option people could turn on for better diagnostics. My point was that it's better to have the default warn instead of having this as an option and fail. If the behavior is fail - it clearly has to be an option, and most people will not be able to use it ( or even know about it - who reads all the manuals ? ). If the behavior is warn - with maybe an option to silence it - people could avoid a lot of errors and it would be easier to debug. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Ant 1.6 : further release plan
Antoine Lévy-Lambert wrote: There have been some bugs fixed since the first ant1.6beta. Thanks Stefan particularly. I am thinking about preparing a second beta on Thursday evening (October 16th). I would also like to make the 1.6 release on October 30th. Cheers, Antoine +1 Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting 1.6 out the door
Dominique Devienne wrote:
As I've been saying all along, lets just introduce a new (unique) notion
for attribute/variable expansion (at use time rather than definition
time), which
is something new in Ant anyhow. No (or less?) backward compatibility
issues, and makes it plain and obvious what is what:
${name} it's a property!
(@name) it's an attribute/variable!!!
I think this is a bad idea.
Chosing between macrodef and ant simplicity - I preffer the second.
There are already a lot of complex rules in ant and antcall and
import, I think the last thing we need is a new syntax for macrodef
variables.
Costin
No context, no unnecessary brain cycles to figure out what is what.
I'll be just as glad as the next guy to use macrodef, I just don't want
that
power to come of the expanse of Ant's simplicitly and user-friendliness.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting 1.6 out the door
Conor MacNeill wrote: What I'd suggest is that soon we branch 1.6 and remove anything that is still settling down. I think we have a few ideas that need to be kicked around before we feel comfortable with them. This work can continue on the HEAD (1.7) while we prepare a release. +1 I'd like to get some thoughts on the above and if you are agreeable, what things you think we should hold over in 1.7. As I see it the major issues we have to consider are 1. import 2. antlib 3. macrodef and presetdef There are surely others so let me know. My position on these issues is 1. import Go with it as is. I think it is useful and useable without coming up against some of the cases we have discussed. How we address those issues can be tackled later, perhaps with a different mechanism. That is bound up in the whole issue of target visibility and overriding. +1 I'm not sure whether we should provide a simple include as well which does no renaming (overrides)? 2. antlib I think this should be in but I am not familiar with its state yet, nor do I think it has had enough testing - might just be my own need to kick the tyres. Are we planning to antlib Ant's own optional jars? In 1.7 I think we need to look at removing antlibs from the root loader when their dependent jars are not available in ANT_HOME/lib. +0 3. macrodef and presetdef These seem to have some issues lately and I suggest we pull these into 1.7 +1 for 1.7 ( +0 for 1.6 ) Costin Comments? Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adding Permissions / Security Manager to Java task and JUnit task
+1 Costin Antoine Levy-Lambert wrote: See : http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22533 I am quoting Martijn Kruithof : The following bug reports are associated with Security Manager issues: http://issues.apache.org/bugzilla/show_bug.cgi?id=6323 and http://issues.apache.org/bugzilla/show_bug.cgi?id=11459 I have written an patch / contribution to add permission handling to the code run inside the Java and JUnit tasks via a common permissions type. The reason no specific permission task has been made with in there nested the JUnit or Java task is that the tasks may need permissions that the code run by these tasks may not have. Manual testing has been performed under JDK 1.4.2 and automated test cases have been added. The build of dist-lite and test is verified to succeed under JDK 1.4.2 The new and modified test cases have been verified to succeed under JDK 1.2.2. (Lots of Failures/Errors there in base!) I will start with my +1 Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Build Time
Stefan Bodewig wrote: On Mon, 18 Aug 2003, [EMAIL PROTECTED] wrote: Something like log4j would allow us to enable debug on a particular target or task. record solves this. Thanks, didn't know about it. Most of the time the debug messages are not logged by anyone IIRC XmlLogger will log all levels. And generates huge files that sometimes are almost useless. I understand the use case and where you are getting at, I don't see a backwards compatible way to change it, though. I expect BuildListeners to play a major role in IDE integration today, changing the interface will break a lot of things. If we make commons-logging/log4j/whatever as part of ant1.6, then in 1.6+ tasks can use it for _debug_ info. Things like the parameter used for javac or exec, or what files are beeing copied can use that. For backward compat, we could keep both paterns - if( project.debug ) - use BuildListener to broadcast the info. if( taskLog.debug || target.debug ) - use commons-logging to debug. It may seem like a huge amount of work - but it can be done incrementally, and at least in my experience this fine tunned debug is needed the most in few tasks ( javac, exec, copy, antcall and maybe few others ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Build Time
Nice work !
Regarding ant logging system - I think we should eventually reopen the
subject and pick a logger API ( I preffer commons-logging, but I won't -1
any other choice ), then start using the normal
if( log.isDebugEnabled()) log()
that prevents useless string concatenations and calls.
Costin
Nicola Ken Barozzi wrote:
Sending this to ant-dev too.
Vadim Gritsenko wrote, On 15/08/2003 23.28:
Just ran Cocoon build under optimize it. Not the clean build, but second
one, when there is nothing to do. It took 6 minutes on 1.6GHz P4 desktop
box. Guess where all this time has been spent? Logging!
45.26%: Project.fireMessageLoggedEvent() method
Made a quick hack of Project, replaced Vector of BuildListeners with
BuildListener[]. Build took 5 minutes.
32.1%: Project.fireMessageLoggedEvent() method
Next hotspot is:
3.78%: DefaultLogger.printMessage
And, after some xerces classes, comes DirectoryScanner - the one who is
doing the actual work:
2.2%: DirectoryScanner.scandir
Does somebody know anybody working on Ant logging system? Is Ant 1.6
better in this regard?
PS Removing synchronized() in this method gives even better results:
build runs 3 minutes, 43 seconds and fireMessageLoggedEvent method takes
just 9.5% of total execution time
PPS Hacked version of Ant-1.5.3's Project.java attached for curious folks
Vadim
Index: src/main/org/apache/tools/ant/Project.java
===
RCS file:
/home/cvspublic/ant/src/main/org/apache/tools/ant/Project.java,v
retrieving revision 1.108.2.12 diff -u -r1.108.2.12 Project.java
--- src/main/org/apache/tools/ant/Project.java 17 Feb 2003 14:21:12
-
1.108.2.12
+++ src/main/org/apache/tools/ant/Project.java 15 Aug 2003 21:26:28
-
@@ -198,7 +198,7 @@
private File baseDir;
/** List of listeners to notify of build events. */
-private Vector listeners = new Vector();
+private BuildListener[] listeners = new BuildListener[0];
/**
* The Ant core classloader - may be codenull/code if using
@@ -347,7 +347,13 @@
* Must not be codenull/code.
*/
public void addBuildListener(BuildListener listener) {
-listeners.addElement(listener);
+synchronized (this) {
+int n = listeners.length;
+BuildListener[] newListeners = new BuildListener[n + 1];
+System.arraycopy(listeners, 0, newListeners, 0, n);
+newListeners[n] = listener;
+listeners = newListeners;
+}
}
/**
@@ -358,7 +364,23 @@
* Should not be codenull/code.
*/
public void removeBuildListener(BuildListener listener) {
-listeners.removeElement(listener);
+synchronized (this) {
+int n = listeners.length;
+int m = 0;
+for (int i = 0; i n; i++) {
+if (listeners[i] != listener
!listeners[i].equals(listener)) {
+m++;
+}
+}
+BuildListener[] newListeners = new BuildListener[m];
+m = 0;
+for (int i = 0; i n; i++) {
+if (listeners[i] != listener
!listeners[i].equals(listener)) {
+newListeners[m++] = listeners[i];
+}
+}
+listeners = newListeners;
+}
}
/**
@@ -367,7 +389,11 @@
* @return a list of build listeners for the project
*/
public Vector getBuildListeners() {
-return (Vector) listeners.clone();
+Vector v = new Vector(listeners.length);
+for (int i = 0; i listeners.length; i++) {
+v.add(listeners[i]);
+}
+return v;
}
/**
@@ -987,7 +1013,7 @@
* Must not be codenull/code.
*/
public void addDataTypeDefinition(String typeName, Class typeClass)
{
-synchronized(dataClassDefinitions) {
+synchronized (dataClassDefinitions) {
Class old = (Class) dataClassDefinitions.get(typeName);
if (null != old) {
if (old.equals(typeClass)) {
@@ -2003,20 +2029,17 @@
private void fireMessageLoggedEvent(BuildEvent event, String
message,
int priority) {
event.setMessage(message, priority);
-Vector listeners = getBuildListeners();
-synchronized(this) {
-if (loggingMessage) {
-throw new BuildException(Listener attempted to access
-+ (priority == MSG_ERR ? System.err :
System.out)
-+ - infinite loop terminated);
-}
-loggingMessage = true;
-for (int i = 0; i listeners.size
Re: beating the dead Ant 1.6 horse
Conor MacNeill wrote: The others are antlib/namespace/polymorph stuff. I'm wondering if we can get to the point where the ant optional tasks are packaged as antlibs and potentially not added to the root loader if their supporting libraries are not also available to the root loader. This would allow them to be taskdef'd in later in a build. What's the status on that ? Any decision on how to deal with the loaders ? I'll have some time next week, I wanted to finish the classloader task - is it still usefull ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch] namespace and antlib
peter reilly wrote: On Tuesday 12 August 2003 13:24, Stefan Bodewig wrote: On Tue, 12 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: On Tuesday 12 August 2003 12:36, Stefan Bodewig wrote: On Fri, 1 Aug 2003, peter reilly [EMAIL PROTECTED] wrote: typedef resource=net/sf/antcontrib/antlib.xml uri=antlib:net.sf.antcontrib classpath=/tmp/ant-contrib.jar/ wouldn't the resource attribute be redundant in that case? Not in this case. The automatic lookup of uri=antlib:net.sf.antcontrib to net/sf/antcontrib/antlib.xml resource currently is done once when the ns prefix is encountered the first time - it does not take place at the typedef/ task. The obvious question would be: Why not? The code handles build scripts like: project xmlns:ac=antlib:net.sf.antcontrib (1) ac:shellscript shell=bash (2) echo helloworld /ac:shellscript typedef uri=antlib:net.sf.antcontrib (3) name=shellscript classpath=testing.classes classname=net.sf.antcontrib.pending.ShellScriptNew/ ac:shellscript shell=bash (4) echo helloword from test shellscript /ac:shellscript /project (1) will associate the ns prefix ac with the uri antlib:net.sf.antcontrib (2) ComponentHelper#createComponent will call #checknamespace for antlib:net.sf.antcontrib and maps it to the net/sf/antcontrib/antlib.xml resource. It then creates a typedef task, and sets the uri and resource to antlib:... and net/sf... and sets the onerror parameter to ignore, this will make available the antcontrib's definitions. ComponentHelper stores the fact that it has implicitly loaded in these definitions so that it does not do this again. 3) This will override the antcontribs' uris definition of shellscript. 4) This will execute the new definition. All this overriding may create some bad maintaince problems. I wish we wouldn't support this feature... Costin I have changed this to ant:*, Hmm, what will be the replacement for antlib:*? Users are allowed to use antlib:*. The restricted uri's are uris that users are not allowed to use in typedef/. as I found when testing that the current code reserves antcontrib: and antelope: Sure, I don't see a problem, though. This makes sense, but would involve some messing with classloaders and scanning of the jar files in ANT_HOME/antlibs. I know. Each time I look at classloaders, my head melts down You are not alone ;-) Seriously, once you've started to really look into classloaders they are not that bad. Only hard to do right (I'm not sure whether I've ever done so 8-). There are sure a lot of things to keep in mind, junit support, classpath delagate, antclassloader, project#setCoreLoader() (not used??) etc ;-) Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
Knut Wannheden wrote:
Sounds great!
In anticipation of this feature I have used a few namespaced properties
for
my custom tasks. And since Ant 1.5 doesn't have any value for these, I've
just made the tasks resolve them explicitly.
This raises a question: Are properties whose values are resolved by custom
PropertyHelpers always converted to Strings? I see that the return type
of PropertyHelper#getPropertyHook(String, String, boolean) has Object as
the
return type. But if that's always converted to a String then my custom
PropertyHelper will need to make sure that this is done correctly, i.e.
that the Object yields a meaningful String representation.
But for tasks which have a setXXX(Object) method it would maybe make sense
to preserve the property value as an Object instance, if that's what's
actually in the buildfile. E.g.
foo xxx=${my:bar}/
would not convert the ${my:bar} property to a String.
If you read the comments on top of PropertyHelper - that was one of the
goals, but I don't think it is implemented yet. The return value for the
property interceptors is already an object, but the code that does property
replacement doesn't know how to deal with ${prop}.
Costin
Cheers,
--
knut
Nicola Ken Barozzi [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Dominique Devienne wrote, On 12/08/2003 15.37:
I'm also interested PropertyHelper, and in particular Costin's
experimental XPath based one. I'd like to be able to define
functions (defined as part of an AntLib) to operate directly on
property values, kind of like XPath functions, and it sounds like
property helper is the way to get this!?!? --DD
Yes. PropertyHelper is a property interceptor, and it simply rocks.
In essence, you register a helper with Ant. Then, at each request for a
property, each registered helper is asked for the property value in
turn; the first one that has it, returns it.
A typical one is the xpath one, as you say, that resolves the request as
an xpath in the Ant Project, if the property starts with xpath:.
Centipede has been using it for a long time, basically to read an xml
file as a property in a more powerful way than simply using xmlproperty.
Now we are doing our own helper that reads the Gump descriptor, the
Maven one, etc and makes them all accessible as a single virtual
descriptor. In this way Ant users can have any descriptor they want and
use that to gather properties and infos for the project.
Just an example of the usage of PropertyHelper.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: override
Jose Alberto Fernandez wrote: From the XSLT bible by Michael Kay (2nd edition page 232): Like inheritance un object-oriented languajes, xsl:import is designed to allow the creation of a library or reusable components, only in this case, the components are modules of stylesheets. And the mechanism works in a very similar way to inheritance. My understanding is that we wanted import/ to allow us to define modules of targets/. You should read the full text of that page, I think a lot of what they want to acomplish in XSLT matches what I think, we need to acomplish in ANT, not sure is the way is done is the best for ANT, and they definetly go deeper than just stylesheet overriding (precedence) they override all kinds of things. Many do not apply to us, but others may. Understanding the import in XSLT is not very easy ( at least for me ) - and I doubt that I'll be able to look at few XSLT using import and figure out the right order ( even if I think I understand the spec ). In any case - I would be very curious to know if there are other people who can claim they like ( and understand ) the XSLT import and feel comfortable understanding xslt files where the precedence rules are used. IMHO ant should try to be a bit easier to use than XSLT. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: override
Jose Alberto Fernandez wrote: One of the problems I have with the rewriting approach is that target names get rewritten y the caller which means that two independent importers may decide to use the same prefix and hence you get a clash. Namespaces or java-style fully-qualified-names are a property intrinsic of the imported file, that is the reason that makes it safe. That's why I think it's better to not try to be too flexible in allowing arbitrary rewriting, but do it in a canonical way: - after a build.xml is read, all un-qualified names get prefixed with the project name and a delimiter ( need some tricks for ant-call, but it's possible ) - you can call a target by the local name as long as it is unique, otherwise you need qualified names. No overloading, no conflicts, no abiguity. Single inheritance (a la Java) requires having syntax that allows for extending only once, something like: project name=q extends=this/other/build.xml.../project if you use something like a task to specify the extend then you may write multiple inheritance and all these ambiguities appear. Could we live with single inheritance and include/ instead of import/? My point is that import is different than extneds. The escenario is that you have your tipical: a target compile depends=precompile target precompile (do-nothing) b target precopile (very complex precompile lib) build: import (a,b) With cross-talk that is all you need to connect the two and get the required effect. Without cross-talk you would need to add more targets to build: With qnames there is no crosstalk. a target a::compile depends a::precompile target a::precompile b target b::precompile build: import a, b You can call a::compile ( which will call a::precompile ), etc. target precompile depends=b.precompile or override-target compile depends=b.precompile, super.compile Too complicated IMO. All import should do is load some build files and deal with the name conflicts in a clear way, without becoming a very hacky solution that nobody understand - and to be honest I have a lot of trouble understanding most of the overriding - even in the simple examples on the thread, I can't imagine what will happen when people start using this with dozens of targets. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: override
Jose Alberto Fernandez wrote: I don't know _any_ programming language where import is used for inheritance. Believe it or not, XSLT is a programming language. :-) And it uses the term import for inheritance. I know XSLT is a programming language, I don't remember it beeing an OO language. And I certainly don't think ant should become a programming language like XSLT. Well, KISS is my concern as well, for import ( which at least in my mind is _very_ different from extend ). I preffer to use import to just import entire files, instead of some attributes and sophisticated rules to determine what target is visible and what target is overriden. What does it mean importing an entire file? I have heard on other languages of including an entire file: C, C++, etc. Yes, C uses the keyword #include, Java uses import. I think import is more intuitive for java programmers, and I'm not sure I get the subtle difference between import and include or why we need both ( unless we want to get some complexity from XSLT ). And if people need an OO feature for ant - that's fine, they can add special tasks ( exted, override, etc ). It is not that easy, you most probably need to change the execution engine, to do it right. Which means changing some of the internal DS of Ant. So it is not just a little task, here and there. That's another argument to keep import simple ( and not turn it into an OO concept ). We have never been talking about java imports. I do not know why you are assumming we were. Because import is making the targets of one file visible in another one. You can consider python and other languages (except C/C++ ) where similar constructs are used. Maybe import shouldn't solve all use cases - just have a different task that solves overriding/replacing some targets. Still, what do you do when including the same target name more than once? Use qualified names. a: compile all depends compile b: compile all depends compile c: import a,b compile all depends a::all, b::all, compile Import a will load a and qualify the names. The equivalent view is: a: a::compile a::all depends a::compile b: b::compile b::all depends b::compile c: import a,b c::compile c::all depends a::all, b::all, c::compile There is no conflict between the 3 compile targets, and each can be used in an unambiguous and clean way. More important - you have access to all targets in all files, and no need to worry about what is overriden by what or order of imports or deep imports. Doesn't matter how a file is imported, you can use all its targets. If you import 2 files, each having a compile target, then you should use qualified names. Like in java import. In Java the qualified name is intrinsic to the imported file; but in the current proporsals the name is given by the importing build, this makes names not to be unique. I consider that an error. If the name is not unique - then report an error. We already have a name in the project name=XXX/, and I'm not sure why we want to define another name given to a project in import, and to add to the confusion - allow a project to be reffered by different names, and worse, to have the same name used for different projects in import statements. Just add the requirement that in order to use import, the project name must be unique, and report an error if 2 files with the same project name are used. None, if 2 targets with the same name are found, you must use qualified names for both ( when calling from outside - Agreed. But you should be able to redefine the target (override) and say what do you want it to mean. Ok - you should be able to say: alias name=mycompile target=a::compile / or even replace name=a::compile with=b::prepare, a::compile / ( what Nicola seem to want ). But not as part of import - this is a different story, different task. It is easy to manipulate the namespace of the project - after the loading is done - and do any kind of changes ( again, python comes to my mind ) Second question: how do we deal with the fact that targets that are not even used have crosstalk between themselves? I don't think you can have crosstalk if you follow the rule that everything is qualified if it has the same name. The probelm with tis is that it does not allow you to write code fragments. Like several blocks of initializations that can be reused but do not define a full build process. Why not ? It just requires you to use them with a qualified name or make their names unique. What it prevents is confusion if you have 2 fragments using the same name. And most of all: how to solve the last two points while keeping it possible for me to retain the use-cases? By adding specialized tasks for your use case ? That is what we were trying to do. I'm confused, I tought we are discussing import :-) Costin
Re: override
with import and the resolution of name conflicts. If people want to replace targets - great, but it's not my use case :-) A clean import is what I need. Second question: how do we deal with the fact that targets that are not even used have crosstalk between themselves? I don't think you can have crosstalk if you follow the rule that everything is qualified if it has the same name. Two points here: - Crosstalk can happen in form of properties - Of course you won't have crosstalk if you use qualified names, this is what Conor says Again, I agree with Conoer :-) That may mean he is right ? I haven't tought about qualified names for properties, but it makes sense too. Let's see: include No problem here, any collision is an error I don't quite see a need for include ( given my view on import :-), but if other people need it - fine with me. override-target I am overriding the previous defined target, and can refer only to the immediately previous one as original.targetname. Overriding can be done multiple times, nesting the calls. import Like include, but gives me the possibility of referring to the imported tasks with a fully qualified name in any case. If there is only one version of a target, it's also available with the original name. Still conused about this [] part [The namespace name has to be specified as a prefix by the one that imports the file, else the project name is used. Projects that are imported must have a name.] If a project imports clashing target names, and thus namespacing is needed, I can still use override-target or target to define a target with the original name. +1 IMPORTANT PART Use case: multi-import(import a,b) target test depends=a.test, b.test a target compile target test depends=compile b target compile target test depends=compile With namespacing I would get: a target a.compile target a.test depends=a.compile b target b.compile target b.test depends=b.compile Now If I redefine compile multi-import(import a,b) target test depends=a.test, b.test target compile depends=a.compile,b.compile Seems ok to me :-) +1 Now for Nick's usecase: Nick Chalko wrote, On 01/08/2003 9.37: I used this feature in centipede. The release antlib has a target called tag-and-release, but it depends on a target called tag However tagis expected to be defined in a different antlib. Currently it is defined in cvsbuild, but it is open for someone to make a vssbuild antlib. So I do think cross talk is a feature but a feature that can be hard to grok. multi-import(import release,cvsbuild) release @importable=only target tag-and-release depends=tag cvsbuild target tag Seems that it should work with the above system. Also multi-import(import release,cvsbuild,vssbuild) Would make it necessary for me to do: override-target tag depends=cvsbuild.tag I'm starting to like override-target :-) Anyway, it seems that all this discussion has brought us back to what I had proposed after Conor pointing out the issue: Nicola Ken Barozzi wrote, On 30/07/2003 10.45: ... OTOMH this could be solved by rewriting all dependencies that are not in the import line. (1)---a multi-import (2)---b (3)---c---d So rewriting should block collisions between (1), (2), (3), but enable them inside those lines. What had been proposed is using fully qualified names in targets that I do not want to be redefined, which could be ok conceptually, but the issue is that the implications of sideways crosstalk between import lines are not transparent to the user, and thus should be avoided. What I need is to be able to import build dependencies along with the targets. Probably the above solution should fix this error and make it work, no? Thanks for taking time to discuss this guys, I appreciate :-) Sorry for repeating what has been discussed, I was very concerned about mixing import with OO and complex name resolution rules ( like in XSLT import :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: override
Thanks for the overview, Nicola ! Just to get you up to speed, the current issue is about multiple inheritance, and how the current system allows cross-import (unwanted?) side-effects, as Conor has brilliantly shown. What I'm not sure I understand is what import has to do with multiple inheritance :-) Most of the problems with cross-import and side effects could be resolved by just using qualified names ( or namespaces ) - like java does to disambiguate imports. A brief recap of decisions taken IIUC: - add an attribute to project: @importable=true, false, only I hope it is not required, and if it is missing it defaults to true. - add possibility of prefix in import declaration import file=xxx prefix=xxy/ This would work as a qualified name ? What's the syntax for the prefixed targets/properties ? Any consideration on using XML namespaces for this ? - all paths are resolved resolved to the importing file basedir The top-level importing file, or the imediate parent ? - keep projectname.ant.file property for relative path resolutions Good. - add include/ task, like entity includes - add override-target/ task to override targets Is this override-target a substitute for extends and OO use of ant ( i.e. a buildfile == class, target==method ) ? If so, wouldn't be more intuitive to just use the real concept - i.e. extends and inheritance ? I know python has a very nice namespacing mechanism where you can replace or add methods dynamically to an object, but I don't know if this is desirable for ant. Threads about import (in order): 1 - ImportTask ant 1.6 2 - ant 1.5.4 : Import 3 - override From thread 2 I wrote: multi-import(import a,b) target test depends=a.test, b.test a target critical target test depends=critical b target critical target test depends=critical Here critical means a.critical to a and b.critical to b, but since they reference a generic critical, they get the only one that remains after being redefined. The problem is that I did not redefine it in the main buildfile! Can this be resolved by making all targets qualified after the build file is read ? That would mean ant will see: top: target top.test depends=a.test, b.test a target a.critical target a.test depdends a.critical b target b.critical target b.test depends=b.critical After reading any build.xml file, ant will just look at all targets and add the project name as a prefix if they don't have one already ( we just need to agree on the separator syntax ). When you look at a build.xml, all targets that don't have prefix are resolved to the current build file - it's pretty easy to understand. That mean you won't be able to use import for crazy overrding of some targets from one file with targets from other file - but if there is a real need for that i have no problem with a python-like mechanism where you can add/replace methods in an object at runtime. As long as it's not disguised as import :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: override
have both. As I have outlined before, imagine I import a file that has a compile and test targets. target compile target test depends=compile I want to be able to do ant compile and have it compile. Thus the compile target should not be renamed. If this is the only compile target in all the imported files, then you should be able to say ant compile. If you import 2 files, each having a compile target, then you should use qualified names. Like in java import. Then when I want to insert a pre-condition to the compile target, I want to be able to redefine the compile target. Reusing it in a differently-renamed target is not ok, as when I call test, it will not have a dependency to the new version of the target. So target compile target newcompile (call:prestuff, compile, poststuff) target test depends=compile That's a nice use-case - but why do you think this is a use case for import ? Just use a rename-target target, or some pre/post or extend. If I call newcompile, it works but calling test will not call the new one, thus making it impossible for me to *decorate* the compile target, thus specializing the template. Makes sense to me - if import would allow this to happen few people will be able to understand a build file. So I consider a good thing that import doesn't allow you to decorate, but instead you should use a specialized task for this use case. The question is: after a multiple import, which compile target becomes the default one, ie the one without renaming? None, if 2 targets with the same name are found, you must use qualified names for both ( when calling from outside - all dependencies and calls from inside an imported build.xml file would use the short name ). Second question: how do we deal with the fact that targets that are not even used have crosstalk between themselves? I don't think you can have crosstalk if you follow the rule that everything is qualified if it has the same name. And most of all: how to solve the last two points while keeping it possible for me to retain the use-cases? By adding specialized tasks for your use case ? As you see, for this usecase, include is not strong enough, as I cannot override, and complete namespacing prevents me from overriding the dependency chain. It's like saying copy is not strong enough to compile java code :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: override
Jose Alberto Fernandez wrote: First I do not think I have all the answers, just to keep things in perspective. What I think I have is a set of principles that I think any viable solution should provide. Lets see if I can put them into words: ;-| 1) I should be able to determine the correctness (loosely used here) of a buildfile by looking at that buildfile (and its dependencies) in isolation. This means that the fact that I am imported by someone else should not affect my correctness (modulo overriden targets). Rewriting of targets, may attempt at this correctness. How can we get something more interesting out of that principle above, I agree is quite generic. Lets see... Does it mean the imported buildfile needs to behave in the same way if it is used standalone or imported ? ( which implies all resolutions should be based on the imported file, etc ) ? 2) It would seem we need to be able to specify whether a target can be overriden or not. We need to be able to define if a target is: private, final, or overidable. Notice that this is a property of the target and not of the way the target is imported. Can you explain a bit more why a build file needs private or final ? I think if the syntax/semantic for the build file gets more complicated than the syntax for java, we are in trouble :-) The meanings are: private == other targets with same name on other files will not override; any mention on dependencies on this file for that target will use this private version; the target is not visible from outside the file. final == target visible from other files but not overidable, it is an error; any mention on dependencies on any file (without a private def) uses this version. overridable == target visible from other files, and overridable; any mention on dependencies on any file will use top level available version. this are just suggestions, other levels of protection may be possible. I hope not. This sounds far too complicated, close to a flexibility syndrome. One think I don't understand is why the import should be used as a OO substitute. Most languages I know define the import in a much simpler way. Maybe I'm missing too much of the context, I'm still trying to get updated with the mailing lists. Costin On a project-fragment, any target dependency not defined in the fragment will be picked up from the visible targets, following the rules above. I would suggest an attribute like: visibility=final|private|overridable you may decide what should be the default. 3) targets can be overriden using target/ which replaces the target completely. Or using override-target which allows expressing dependencies on the overriden target. The syntax in the dependency list is to mention the name of the target itself n the list. override-target name=compile depends=precompile, compile, postcompile/ The compile target in the dependency list refers to the overriden target. Notice that override-target requires target name to already exist and be overridable. 4) To support multiple inheritance, I would allow defining a name for an import. This name is only visible locally and can be used to specify in a dependency list a target comming from an specific import. You can refer that way to any target visible from that import but you cannot refer to inner imports of those that have been overriden. You cannot use the notation to break the visibility rules. import file=xyz name=a/ import file=qrs name=b/ target name=compile depends=a-precompile, b-precompile /target If xyz uses some other import that it names q, I canot say a-q-precompile, because that violates the visibility rules defined in xyz that provided its own target a-precompile. Ok, I will stop now, we can talk about implementation later. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using classloader for Junit
Conor MacNeill wrote: BTW, I don;t really agree with the classloader task being used to modify the effective classpath of running ClassLoaders. I'm sure this will cause trouble too. Seems to break some of the properties are immutable philosophy of ant. No - not really an Ant level issue. I am concerned by the scenario where a classloader with a child can not find a class on the first instance causing the child to load the class. If that class is later added to the loader's classpath, it becomes possible for parent to load the class and then we have a parent and child loader with the same class loaded bad stuff happens. That's a pretty common case in tomcat or any container using reverse loaders, and usually nothing bad happens. Jboss is also using a flat loader where classes are added dynamically - and seems to be fine in most cases ( or at least more reliable than other alternative ). The classloader scheme is actually much safer than what jboss is using. I'm sure there will be some combination of loaders where classloader may generate an error, but it's better than any other scheme that I know or tried so far. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using classloader for Junit
Nick Chalko wrote:
After I slept on it, I thought of how I could extend the antclassloader
to handle the situations I need.
I am considering a antlibclassloader /
That will explicitly allow the optional ant task to be loaded in the
child classloader.
I may even go so far as automatically adding this fileset
${ant.home}/lib/ant-*.jar to the classloader.
That should handle the usecase I have in mind.
Are you talking about a single child loader for all optional tasks ?
This may work - if you use normal delegation. The code that instantiate
the tasks needs to have a reference to the child loader, and I don't
think core tasks have dependencies on the classes in the optional.
peter reilly wrote:
Ah, I see.
That would be nice, but the classloader task is not
yet complete.
The part that loads junit.jar to the main loader is complete.
There are other possible enhancements to create arbitrary loaders
or support reloading which are not yet implemented.
Costin
Peter
On Thu, 2003-06-19 at 08:52, Nick Chalko wrote:
peter reilly wrote:
Check the ant faq http://ant.apache.org/faq.html#delegating-classloader
In essence you need to place the junit.jar file in ${ant.home}/lib
I had hoped that was what the classloader/ task would let me avoid.
-
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 / 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: [VOTE] Peter Reilly as committer
+1 Costin Conor MacNeill wrote: Hi, I would like to propose Peter Reilly as an Ant committer. He has submitted a number of patches that advance the Ant core fanctions as well as helping out answering questions on the user list. I think we've all seen that he has the persistence required :-) I will start with my +1 Conor
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: [PMC VOTE] Adoption of Bylaws
Conor MacNeill wrote: PMC members, I'd like to move towards adoption of the bylaws draft. http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/proposal/ant-site/anakia/docs/bylaws.html?rev=1.16 Could you please view this and vote indicating your position. If you wish to vote -1 because you don't believe the bylaws include all they should, that's OK, of course, but please give me details on what changes are required. Thanks Conor +1 Costin
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
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: Roles (was: antlib)
exactly what behavior you want. 5) Use of the ns form project xmlns:myxyz=ant:net.sf.antcontrib/ means that there is no need for antlibs. Indeed having them would be confusing. To mis-quote the perl mantra, there should be only one way to do things. There is no lib, just a definition file in the classpath. What do you mean ? An antlib is a jar with a descriptor and a URI ( either a package name - or something else ). I mean that one does not need to use jars for this. The class path is sufficient. +1 To support this I would propose the following: 1: define the xml format of the definition file. I would propose a root element of antdef and nested elements of typedef and taskdef and a possible description nested element and/or attribute. Or antlib as root element ? As I said above my implemation uses an ant task for this, using the same name for the root element of the descriptor and for a different task would cause interesting problems for the implementation. Ok. 4: Implement the XML ns changes to use the xml definition file possibly using a predefined filename and using a package name. Not sure I understand - which part are you talking about ? I mean that I am making no assumtions on the location of the definition file, in the class path, or in the jar or in the meta-data part of the jar or meta inf attribute pointing to the xml file or having two xml files one pointing to the other Ok. Well - even if the NS is not used to load the descriptor, I still think it would be good to at least recommend the package to be used as ns. ( and certainly not http:// or file:// :-) Costin
RE: Roles (was: antlib)
Jose Alberto Fernandez wrote: As someone already said, it's about not reinventing the wheel, not about enabling the use of fancy tools. But as ubiquitous and accepted as XML namespaces are, I see many things that could be gained from using namespaces. Also, I suspect most users familiar with XML will have had some dose of contact with namespaces. But ANT is not for experience XML users but for Java programmers or C or .NET (with the new tasks). ANT is popular because it is simple to use you do not have construccions that require you to read a full spec to understand. I am not against NS, but I am against forcing people to use them just because. And you instead propose to use something as complex - but different. Your rewriting task names to resolve conflicts is in no way better than use namespace to resolve conflicts. User of ant will be far better learning the standard way to resolve conflicts than learning your syntax and rewriting. We do force people to use XML, and we force them to use a specific DTD ( copy ... ) and semantics. Even Perl forces people to use a certain syntax and rules. If you have a solution to the name conflict that is far better than using the standard solution - then we can consider it. But renaming task names is certainly not. So again you have a two tier world where some things are more core than others. Me as a library provider need to decide now whether to ship my library with a property file so that it can be incorporated seemingly into ANT namespace or use an XML definition and force my users to learn NS. Hu Yes. In the first case you'll need to be very carefull to avoid naming conflicts, and you may not be able to benefit from some tools. In the second - you'll force users to use NS - which is a standard used in almost all XML specifications today. We already forced them to learn XML in the first place, and learning NS won't be a waste of time. project xmlns:cont=urn:uri-supplied-by-ant-user antlib location=antcontrib.jar ns=urn:uri-supplied-by-ant-user/ cont:if/ /project I thing this is what I meant (in escense), with the understanding that: a) the user can use the same URI on several antlibs (any conflicts are his problem) The namespace is _not_ under user control, at least according to W3C. You can't just use whatever URI you want for XSLT or XHTML - the URI of a specification/DTD is defined by that specification. The equivalent of a namespace in a programming language is the package. What you are suggesting is equivalent in letting users pick whatever package they want for a java class, at runtime. BTW, if we are still talking about java programmers using ant - I doubt we'll have that many users who don't understand how package work and have a big shock learning about XML namespaces. Costin
Re: Roles (was: antlib)
Conor MacNeill wrote: On Thu, 8 May 2003 12:30 am, Costin Manolache wrote: The URI however should be chosen by the antlib author ( maybe based on some rules specific to ant ), and should serve as an ID of the library. My proposal is to use the (main) package name. There are other options - but I don't think every end user using it's own name for an antlib is a good one. +1 I believe the URI should be defined by the antlib builder, not the user. It should be opaque - no semantic structure, at least from Ant's processing. An antlib should just declare to what namespace URI it belongs and then that antlib's defs would be accessible through that namespace in the build file. Can you explain why you don't want a semantic structure ? I don't understand why using a java package name - i.e. the base package of the library - as ns is worse than using an arbitrary string. And I don't unserstand why not using the URI in a meaningfull way - to locate the descriptor. If we use an arbitrary string - we'll still have to use a declaration to associate it with a resource. Of course - using the URI as a file is bad, using it as a HTTP is not very good either. But a java package name has all the characteristics that a namespace name needs, and it's intuitive for java developers. This would allow multiple antlibs to belong to a single namespace, which might be useful for extension purposes. So, something like this What would be the benefit ? IMO it would be more confusing. Even if we don't care about tools - having a namespace associated with a clear set of elements and tags is good for clarity. antlib uri=blah taskdef typdef /antlib Antlibs could potentially declare themselves to belong to the default namespace. This would handle Ant's existing optional tasks. This facility might be restricted to antlibs found in a particular location. +1 - the default namespace is a special case. My problem is with spaghetti-namespaces ( that change names or can be combined ). project xmlsns:antcontrib=ant:net.sf.antcontrib antcontrib:if ... would become: project antlib uri=ant:net.sf.antcontrib if In the first case - if's namespace can be used to locate/load the lib. In the second - an explicit load into the default namespace. A classloader could probably be associated with the URI, picking up all antlibs declaring the URI. For advanced uses - ok. For common use - I think using the main class loader and adding the antlibs ( and their dependencies ) to the main loader is far better. By advanced use I mean the case where you want to use multiple versions of an antlib at the same time, or antlibs that have conflicting deps, etc. Costin Just some thoughts Conor
RE: Roles (was: antlib)
Let's not reinvent the wheel here. The solution for names conflicts is namespaces - not rewriting. If we use a prefix, let's stick with what everyone else is using. Inventing some original solution ( that may or may not be easier or more flexible than the W3C solution ) won't make things better for the user. antlib location=antcontrib.jar prefix=myxyz- / myxyx-if ... is not easier than project xmlns:myxyz=ant:net.sf.antcontrib myxyz:if ... Costin Jose Alberto Fernandez wrote: Hi guys, I was away on vacation so hasn't been around to make comments about the entire discussion. I will try to sumarize here some comments that go across several messages I have read today. The current antlib provides a way for the user of a particular antlib to rename one or more elements that are in conflict with elements of some other antlib it tries to use. As the renaming is local to the project there is no problem; it is up to the user of the antlib to decide what names to use to refer to the loaded things. For example I may use the foreach class of antcontrib but for reasons of my project being in need to also use a foreach defined by some other third party which works diferently. So I could just load it and rename it lets say to forall and use it in my project using that name. It is up to me as the user of the antlib. From the discussion this last few days I like the idea from (I think) Peter/Nicola of having short and long names where the long names are form by adding a prefix defined not by the antlib writer, but by the antlib user: antlib location=antcontrib.jar prefix=myxyz- / which would allowme to use either: if/ or myxyz-if it is upto the user to decide what to use. Of course the same would be for the tasks (i.e., taskdef) that allows loading individual tasks into roles. The same rules of collisions and conflict resolution apply. The important point is for the user (which is the one who has to deal with name clashes) to have control of the final naming scheme used in his/her buildfile. And we are not impossing any wierd semantics or making assumptions, if I decide to use the same prefix for two antlibs it is up to me to make sure there are no conflicts. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 02 May 2003 14:35 To: [EMAIL PROTECTED] Subject: Re: Roles (was: antlib) On Wed, 30 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: The problem you are overlooking is the case of weblogic element in ejbjar, jspc, serverdeploy, etc. Maybe not really overlooking but understimating. The alternative would be to use weblogicjspc and weblogicdeploy for the different interfaces. If they come from different antlibs, we really should use XML namespaces to resolve this. But I now understand that having a table per interface may be convenient (though not strictly necessary). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Roles (was: antlib)
Stefan Bodewig wrote: On Tue, 06 May 2003, Costin Manolache [EMAIL PROTECTED] wrote: Jose Alberto Fernandez wrote: The important point is for the user (which is the one who has to deal with name clashes) to have control of the final naming scheme used in his/her buildfile. Let's not reinvent the wheel here. The solution for names conflicts is namespaces - not rewriting. +1 to both. Make the use choose the namespace for the antlib he/she wants to use. If you're reffering to the prefix - of course, that's how NS works. The URI however should be chosen by the antlib author ( maybe based on some rules specific to ant ), and should serve as an ID of the library. My proposal is to use the (main) package name. There are other options - but I don't think every end user using it's own name for an antlib is a good one. Costin
Re: Roles (was: antlib)
format of the definition file. I would propose a root element of antdef and nested elements of typedef and taskdef and a possible description nested element and/or attribute. Or antlib as root element ? I'm pretty sure sooner or later we'll have some conditions or echo or even paths :-) And also dependencies in one form or another. But for start typedef should be enough. I wouldn't use taskdef - just a typedef and the fact that implements Task or has an adapter that implements task 2: either extend the typedef/ task to use the definition file in the same way as property files are deal with at the moment or provide a task - antdef [resource=... | file =...] [classpath attributes and nested elements from typedef/ Again - antlib ... :-) 3: release/document the classloader/ task to manipulate the classpath. Sorry - tomcat took much more than I expected last weekend. 4: Implement the XML ns changes to use the xml definition file possibly using a predefined filename and using a package name. Not sure I understand - which part are you talking about ? Costin Peter On Wednesday 07 May 2003 06:14, Costin Manolache wrote: Let's not reinvent the wheel here. The solution for names conflicts is namespaces - not rewriting. If we use a prefix, let's stick with what everyone else is using. Inventing some original solution ( that may or may not be easier or more flexible than the W3C solution ) won't make things better for the user. antlib location=antcontrib.jar prefix=myxyz- / myxyx-if ... is not easier than project xmlns:myxyz=ant:net.sf.antcontrib myxyz:if ... Costin Jose Alberto Fernandez wrote: Hi guys, I was away on vacation so hasn't been around to make comments about the entire discussion. I will try to sumarize here some comments that go across several messages I have read today. The current antlib provides a way for the user of a particular antlib to rename one or more elements that are in conflict with elements of some other antlib it tries to use. As the renaming is local to the project there is no problem; it is up to the user of the antlib to decide what names to use to refer to the loaded things. For example I may use the foreach class of antcontrib but for reasons of my project being in need to also use a foreach defined by some other third party which works diferently. So I could just load it and rename it lets say to forall and use it in my project using that name. It is up to me as the user of the antlib. From the discussion this last few days I like the idea from (I think) Peter/Nicola of having short and long names where the long names are form by adding a prefix defined not by the antlib writer, but by the antlib user: antlib location=antcontrib.jar prefix=myxyz- / which would allowme to use either: if/ or myxyz-if it is upto the user to decide what to use. Of course the same would be for the tasks (i.e., taskdef) that allows loading individual tasks into roles. The same rules of collisions and conflict resolution apply. The important point is for the user (which is the one who has to deal with name clashes) to have control of the final naming scheme used in his/her buildfile. And we are not impossing any wierd semantics or making assumptions, if I decide to use the same prefix for two antlibs it is up to me to make sure there are no conflicts. -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 02 May 2003 14:35 To: [EMAIL PROTECTED] Subject: Re: Roles (was: antlib) On Wed, 30 Apr 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: The problem you are overlooking is the case of weblogic element in ejbjar, jspc, serverdeploy, etc. Maybe not really overlooking but understimating. The alternative would be to use weblogicjspc and weblogicdeploy for the different interfaces. If they come from different antlibs, we really should use XML namespaces to resolve this. But I now understand that having a table per interface may be convenient (though not strictly necessary). Stefan - 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: Roles (was: antlib)
Jose Alberto Fernandez wrote: From: Wannheden, Knut [mailto:[EMAIL PROTECTED] Let's not reinvent the wheel here. The solution for names conflicts is namespaces - not rewriting. I agree. With the new ProjectHelper2 everything should be in place to start using namespaces. I have no problem on allowing people to use namespaces, but I do have a problem on forcing people to use them just because some others want to use some fancy XML tool. The buildfile belongs to the user and s/he should be in charge. Namespaces are the common solution used to resolve name conflicts. I have a big problem on using some original solution like renaming tasks with some prefix. This has nothing to do with fancy XML tools ( in fact, very few editors are able to deal nicely with namespaces ). We have a problem - name conflits - and one solution. I like Perl and the there is more than one way to do things, but in this case we have a standard solution that everyone uses, and it would be very confusing and wrong to force the user to learn a different one. This would also allow antlibs to have a DTD or XML Schema which could be used in XML editors or for validation. Well ANT's XML is the result of introspection, and we already know our object model cannot be represented by a simple DTD. I see no way or reson to enforce 3rd party libraries to define their objects to be DTD-able. I am not sure about XMLSchema but my hopes are not too high. I agree with you on this one. XMLSchema is one of the worse things I've seen. However it is possible to associate a DTD/schema with (most) of the ant ( we even have a dtd generator, that works great with emacs, I use the DTD every day ). And some users may choose to create build files with editors using only the subset of ant that is supported by the editor ( i.e. fits the restrictions of the DTD/schema ). Also namespaces lets the antlib user specify what prefix to use. But it doesn't allow two antlibs to use the same prefix in the context of the same element, which I think is good. This sounds proper in theory, but in practice lets see: 1) Lets assume that we still want to be able to chop ANT jars between core and different optional jars which have specific dependencies of diferent packages and such. 2) Now because they are in different antlibs it would mean I am forced to use different namespaces for each. Why ? I think most people agreed that using the jar file name as a namespace URI is not the best solution. If we go with the package name ( or other solution where the ns is fixed by the antlib creator ) - you can have the files in multiple jars. For package name - the descriptor will have to be in that package. 3) So now you have people using 3rd party tasks like antcontrib without problem and without conflicts, but they would have to change not just one line (to use the antlib) but every bloddy use of the tasks just because they are forced to use name spaces. I think you started with wrong assumptions here. There is no need to change anything in the core or optional tasks, you can have an antlib that uses multiple jars ( and most likely antlibs will eventually use some dependency mechanism and have mutliple jars ). I doubt many people will be fill happy about that, and the backward compatibility consequences. If you really want you can use short names with namespaces as well. Just set the default namespace locally. I have no problem using XML namespaces as long as they are independent of the antlib and under complete user control (not antlib designer control). In other words the user should be able to decide if s/he wants to load the library on some particular namespace or in the default namespace which is the one used by core. The namespace is not under user control - by definition. Read the W3C spec, it is designed to be fixed, stable, durable, etc. And there is no point in the user changing the namespace URI - the ns is the id or name of the library. Regarding use of the core namespace if no name conflicts: +1 So if I say: antlib location=antcontrib.jar/ I will be able to use: if/, switch/, etc. But is I do: project xmlns:cont=mylibs Again - the URI is not under user control, but under the antlib author control. Just like the if and the other task names. Allowing the user to rename tasks would be very wrong and confusing. ( let's rename delete to copy, then import few files - and figure out what the build file is actually doing ). antlib location=antcontrib.jar usens=cont/ /project then I can use cont:if/, cont:switch/, etc. Costin Which means that the default value for the 'usens' attribute is which assumes some implicit namespace definitions like: xmlns=ant-namespace and probably xmlns:ant=ant-namespace which uses as kosher namespaces as possible, I think. Jose Alberto
cvs commit: ant/src/main/org/apache/tools/ant ComponentHelper.java
costin 2003/05/04 19:17:28
Modified:src/main/org/apache/tools/ant ComponentHelper.java
Log:
Remove one method - it wasn't used, and it seems it's not powerfull enough for
all cases discussed. The method that takes UnknownElement, ns, tag should
be able to cover everything ( by having access to UE you get access to parent
and all the tree - so any kind of policy can be implemented )
Of course - nothing calls this method yet. Switching UnknwonElement and the
normal component creation is easy - but there are many pieces of code that
call the old method.
Revision ChangesPath
1.8 +24 -26ant/src/main/org/apache/tools/ant/ComponentHelper.java
Index: ComponentHelper.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/ComponentHelper.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ComponentHelper.java 3 May 2003 06:27:00 - 1.7
+++ ComponentHelper.java 5 May 2003 02:17:28 - 1.8
@@ -124,28 +124,16 @@
taskClassDefinitions= new AntTaskTable(project, true);
}
-
-/** Creates an ant component..
- *
- * A factory may have knowledge about the tasks it creates. It can return
- * an object extending TaskAdapter that emulates Task/DataType. If null
is returned,
- * the next helper is tried.
- *
- * @param ns namespace if a SAX2 parser is used, null for 'classical' ant
- * @param taskName the (local) name of the task.
- */
-public Object createComponent( String ns,
- String taskName )
-throws BuildException
-{
-if( getNext() != null ) {
-return getNext().createComponent( ns, taskName);
-}
-return null;
-// XXX class loader ? Can use the ns, but additional hints may be
available in taskdef
-//
-}
-
+/** Factory method to create the components.
+ *
+ * This should be called by UnknownElement.
+ *
+ * @param ue The component helper has access via ue to the entire XML
tree.
+ * @param ns Namespace. Also available as ue.getNamespace()
+ * @param taskName The element name. Also available as ue.getTag()
+ * @return
+ * @throws BuildException
+ */
public Object createComponent( UnknownElement ue,
String ns,
String taskName )
@@ -162,17 +150,23 @@
// This is the original policy in ProjectHelper. The 1.5 version
of UnkwnonwElement
// used to try first to create a task, and if it failed tried a
type. In 1.6 the diff
// should disapear.
-component = project.createDataType(taskName);
+component = this.createDataType(taskName);
if( component!=null ) return component;
}
// from UnkwnonwElement.createTask. The 'top level' case is removed,
we're
// allways lazy
-component = project.createTask(taskName);
+component = this.createTask(taskName);
return component;
}
+/** Initialization code - implementing the original ant component
+ * loading from /org/apache/tools/ant/taskdefs/default.properties
+ * and .../types/default.properties
+ *
+ * @throws BuildException
+ */
public void initDefaultDefinitions() throws BuildException {
String defs = /org/apache/tools/ant/taskdefs/defaults.properties;
@@ -229,8 +223,8 @@
* this exception is thrown.
*
* @see #checkTaskClass(Class)
- - */
-public void addTaskDefinition(String taskName, Class taskClass)
+ */
+public void addTaskDefinition(String taskName, Class taskClass)
throws BuildException {
Class old = (Class) taskClassDefinitions.get(taskName);
if (null != old) {
@@ -368,6 +362,10 @@
* Creates a new instance of a task, adding it to a list of
* created tasks for later invalidation. This causes all tasks
* to be remembered until the containing project is removed
+ *
+ * Called from Project.createTask(), which can be called by tasks.
+ * The method should be deprecated, as it doesn't support ns and libs.
+ *
* @param taskType The name of the task to create an instance of.
* Must not be codenull/code.
*
cvs commit: ant/src/main/org/apache/tools/ant Project.java
costin 2003/05/04 19:20:26
Modified:src/main/org/apache/tools/ant Project.java
Log:
ComponentHelper has been checked in for some time - and I don't know
any -1 or major complain.
This removes the duplicated code and switches the component creation
to component helper.
I used it in my workspace for a long time without problem - and the gump
seems to work just like before.
Revision ChangesPath
1.138 +15 -363 ant/src/main/org/apache/tools/ant/Project.java
Index: Project.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/Project.java,v
retrieving revision 1.137
retrieving revision 1.138
diff -u -r1.137 -r1.138
--- Project.java 17 Apr 2003 04:50:27 - 1.137
+++ Project.java 5 May 2003 02:20:25 - 1.138
@@ -169,17 +169,6 @@
/** Name of the project's default target. */
private String defaultTarget;
-/** Map from data type names to implementing classes (String to Class).
*/
-private Hashtable dataClassDefinitions = new AntTaskTable(this, false);
-/** Map from task names to implementing classes (String to Class). */
-private Hashtable taskClassDefinitions = new AntTaskTable(this, true);
-/**
- * Map from task names to vectors of created tasks
- * (String to Vector of Task). This is used to invalidate tasks if
- * the task definition changes.
- */
-private Hashtable createdTasks = new Hashtable();
-
/** Map from target names to targets (String to Target). */
private Hashtable targets = new Hashtable();
/** Set of global filters. */
@@ -289,41 +278,8 @@
public void init() throws BuildException {
setJavaVersionProperty();
-String defs = /org/apache/tools/ant/taskdefs/defaults.properties;
-
-try {
-Properties props = new Properties();
-InputStream in = this.getClass().getResourceAsStream(defs);
-if (in == null) {
-throw new BuildException(Can't load default task list);
-}
-props.load(in);
-in.close();
-((AntTaskTable) taskClassDefinitions).addDefinitions(props);
-
-
-} catch (IOException ioe) {
-throw new BuildException(Can't load default task list);
-}
-
-String dataDefs = /org/apache/tools/ant/types/defaults.properties;
-
-try {
-Properties props = new Properties();
-InputStream in = this.getClass().getResourceAsStream(dataDefs);
-if (in == null) {
-throw new BuildException(Can't load default datatype list);
-}
-props.load(in);
-in.close();
-
-((AntTaskTable) dataClassDefinitions).addDefinitions(props);
-
-
-} catch (IOException ioe) {
-throw new BuildException(Can't load default datatype list);
-}
-
+ComponentHelper.getComponentHelper(this).initDefaultDefinitions();
+
setSystemProperties();
}
@@ -886,41 +842,8 @@
*/
public void addTaskDefinition(String taskName, Class taskClass)
throws BuildException {
-Class old = (Class) taskClassDefinitions.get(taskName);
-if (null != old) {
-if (old.equals(taskClass)) {
-log(Ignoring override for task + taskName
-+ , it is already defined by the same class.,
-MSG_VERBOSE);
-return;
-} else {
-int logLevel = MSG_WARN;
-if (old.getName().equals(taskClass.getName())) {
-ClassLoader oldLoader = old.getClassLoader();
-ClassLoader newLoader = taskClass.getClassLoader();
-// system classloader on older JDKs can be null
-if (oldLoader != null
- newLoader != null
- oldLoader instanceof AntClassLoader
- newLoader instanceof AntClassLoader
- ((AntClassLoader) oldLoader).getClasspath()
-.equals(((AntClassLoader)
newLoader).getClasspath())) {
-// same classname loaded from the same
-// classpath components
-logLevel = MSG_VERBOSE;
-}
-}
-
-log(Trying to override old definition of task + taskName,
-logLevel);
-invalidateCreatedTasks(taskName);
-}
-}
-
-String msg = +User task: + taskName + +
taskClass.getName();
-log(msg, MSG_DEBUG);
-checkTaskClass(taskClass
Tomcat-connectors 1.1M1
I did the JTC_1_1_M1 tag and build for tomcat-connectors-1.1M1. The main purpose is to be able to use the same connector across all tomcat versions - that was one of the goals of tomcat-connectors. The code is identical with the one in tomcat5.0.2 - except the build procedure and packaging. I tried it against tomcat-3.3.1a, tomcat4.0.6, tomcat4.1.18 and tomcat4.1.24 - all seem to work fine. Also included in doc/ are basic instructions for setting it up in each of those versions. Tomcat5.0.2 includes it by default, so no special instructions are needed.
Re: Tomcat-connectors 1.1M1
Ops, wrong group - sorry. Costin Costin Manolache wrote: I did the JTC_1_1_M1 tag and build for tomcat-connectors-1.1M1. The main purpose is to be able to use the same connector across all tomcat versions - that was one of the goals of tomcat-connectors. The code is identical with the one in tomcat5.0.2 - except the build procedure and packaging. I tried it against tomcat-3.3.1a, tomcat4.0.6, tomcat4.1.18 and tomcat4.1.24 - all seem to work fine. Also included in doc/ are basic instructions for setting it up in each of those versions. Tomcat5.0.2 includes it by default, so no special instructions are needed. From my point of view, any bug against the connector in any tomcat version should be fixed by upgrading the connector to the latest common version. Dealing with 4 branches is too expensive - and the connector code is desingned to be common. Please test and let me know if there are any problems. We should have another standalone release at the same time with 5.0.3 that will pick any fix. I uploaded the builds at http://jakarta.apache.org/builds/jakarta-tomcat-connectors/release/v1.1M1 ( I don't think it should go to www.apache.org/dist since it's just a milestone release ). Costin
cvs commit: ant/src/main/org/apache/tools/ant ComponentHelper.java
costin 2003/05/05 06:59:24
Modified:src/main/org/apache/tools/ant ComponentHelper.java
Log:
Last part of component helper merge ( including the fix contains -
containsKey for the test case )
Revision ChangesPath
1.9 +16 -7 ant/src/main/org/apache/tools/ant/ComponentHelper.java
Index: ComponentHelper.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/ComponentHelper.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ComponentHelper.java 5 May 2003 02:17:28 - 1.8
+++ ComponentHelper.java 5 May 2003 13:59:24 - 1.9
@@ -597,26 +597,33 @@
}
protected void initAll( ) {
-if( initAllDone ) return;
+if( initAllDone ) {
+return;
+}
project.log(InitAll, Project.MSG_DEBUG);
-if( props==null ) return;
+if( props==null ) {
+return;
+}
Enumeration enum = props.propertyNames();
while (enum.hasMoreElements()) {
String key = (String) enum.nextElement();
Class taskClass=getTask( key );
if( taskClass!=null ) {
// This will call a get() and a put()
-if( tasks )
+if( tasks ) {
project.addTaskDefinition(key, taskClass);
-else
+} else {
project.addDataTypeDefinition(key, taskClass );
+}
}
}
initAllDone=true;
}
protected Class getTask(String key) {
-if( props==null ) return null; // for tasks loaded before init()
+if( props==null ) {
+return null; // for tasks loaded before init()
+}
String value=props.getProperty(key);
if( value==null) {
//project.log( No class name for + key,
Project.MSG_VERBOSE );
@@ -634,13 +641,15 @@
return taskClass;
}
} catch( Exception ex ) {
+//ignore
}
}
taskClass = Class.forName(value);
return taskClass;
} catch (NoClassDefFoundError ncdfe) {
project.log(Could not load a dependent class (
-+ ncdfe.getMessage() + ) for task + key,
Project.MSG_DEBUG);
++ ncdfe.getMessage() + ) for task
++ key, Project.MSG_DEBUG);
} catch (ClassNotFoundException cnfe) {
project.log(Could not load class ( + value
+ ) for task + key, Project.MSG_DEBUG);
@@ -665,7 +674,7 @@
return taskClass;
}
-public boolean contains( Object key ) {
+public boolean containsKey( Object key ) {
return get( key ) != null;
}
cvs commit: ant/src/main/org/apache/tools/ant ComponentHelper.java
costin 2003/05/02 22:59:35
Modified:src/main/org/apache/tools/ant ComponentHelper.java
Log:
Update with the changes in Project.
This makes ComponentHelper the almost exact duplication of the task creation
code in Project.
Revision ChangesPath
1.6 +12 -4 ant/src/main/org/apache/tools/ant/ComponentHelper.java
Index: ComponentHelper.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/ComponentHelper.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ComponentHelper.java 15 Apr 2003 17:23:15 - 1.5
+++ ComponentHelper.java 3 May 2003 05:59:35 - 1.6
@@ -423,6 +423,7 @@
}
task = taskA;
}
+task.setProject( project );
task.setTaskType(taskType);
// set default value, can be changed by the user
@@ -631,7 +632,9 @@
project.log(Loading with the core loader + value,
Project.MSG_DEBUG);
taskClass=project.getCoreLoader().loadClass(value);
-if( taskClass != null ) return taskClass;
+if( taskClass != null ) {
+return taskClass;
+}
} catch( Exception ex ) {
}
}
@@ -650,12 +653,17 @@
// Hashtable implementation
public Object get( Object key ) {
Object orig=super.get( key );
-if( orig!= null ) return orig;
-if( ! (key instanceof String) ) return null;
+if( orig!= null ) {
+return orig;
+}
+if( ! (key instanceof String) ) {
+return null;
+}
project.log(Get task + key, Project.MSG_DEBUG );
Object taskClass=getTask( (String) key);
-if( taskClass != null)
+if( taskClass != null) {
super.put( key, taskClass );
+}
return taskClass;
}
Re: Roles (was: antlib)
peter reilly wrote: Yes, but more infrastructure is needed. (Also, in current ant cvs, ComponentHelper is not used). It's not used because I wanted some feedback on its interfaces. The code is (almost) the same with the one in Project, and it requires one little step to be enabled and pass the ns. My knowledge on this subject is very small, but here is my understanding (based on looking at jelly source code). To support XML ns one needs to know the uri associated with the namespace prefix. If you look in ProjectHelper2, in the inner ElementHandler - the onStartElement() is called with the URI, tag, qname. It creates UnknownElement(). All that's missing is an unknownElement.setNamespace( uri ) ( and adding the getter and setter in UE ). The same prefix may be associated with different uri in the course of processing an xml file. The prefix is usually not relevant. ElementHelper gets it, but I don't think it should use it in any way. By overriding sax.helpers.DefaultHandler#startPrefixMapping and #stopPrefixMapping, one can find out when the prefix mapping space is active and when it is terminated. This is what jelly does. I'm not sure what jelly does, but SAX2 startElement() callback has the info we need ( i.e. the URI ), I don't thik we really need the prefix. It would be more difficult (I may be wrong here) for ant to use this information as resolving of most of tags is done after the xml parsing has completed. When the UE is created we have the URI - and it's trivial to add it. It is not necessary to do this as .DefaultHander#startElement does pass the uri that is associated with the element. This could get stored in the UnknownElement and used for name resolution. (Attributes would also be be considered). Since namespace processing is active, the code should use getLocalName and not getQName. True ( actually there is no getLocalName/getQName - the sax callback has both ). To support antlibs, I am thinking that one could have a mapping table per uri (for element tags), either within the ComponentHelper, or have a ComponentHelper per uri. ComponentHelper's role is to create components - using URI or whatever else it wants. It can maintain one table per URI - or you can have one CH per URI ( I preffer the first option ). One use case I had in mind for CH was a namespace like jmx:..., where the JMXComponentHelper would use the JMX metadata to create the task ( no ant table ). That's clearly outside the scope of antlib or ant ( it's just a custom task ). Costin Peter On Friday 02 May 2003 15:42, Costin Manolache wrote: peter reilly wrote: \ example: typedef myfileset mypath anttest etc .. copy todir=output fileset ant-type=myfileset dir=src newattribute=MyFileSet attribute/ /copy anttest path ant-type=mypath path=build.xml newattribute=MyPath attribute/ /anttest I assume you meant to write ant:type instead of ant-type... No... Ant does not have the infrastructure at the moment to support XML namespaces, and their associated contexts. AFAIK ant _does_ have now the infrastructure to support and use XML namespaces. It is not using it - because we don't know yet what's the best way to do it, but AFAIK the infrastructure exists. ProjectHelper2 uses SAX2, it preserves namespaces in UnknownElement and the code for creation of tasks/types (ComponentHelper) receives the namespace and the name. CH allows plugins - i.e. any task can hook into the component creation and provide it's own mechanism, so you should be able to implement whatever namespace policy you want. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: ant/src/main/org/apache/tools/ant ComponentHelper.java
costin 2003/05/02 23:27:00
Modified:src/main/org/apache/tools/ant ComponentHelper.java
Log:
The ctor takes Project as param.
Revision ChangesPath
1.7 +1 -1 ant/src/main/org/apache/tools/ant/ComponentHelper.java
Index: ComponentHelper.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/ComponentHelper.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ComponentHelper.java 3 May 2003 05:59:35 - 1.6
+++ ComponentHelper.java 3 May 2003 06:27:00 - 1.7
@@ -524,7 +524,7 @@
if (noArg) {
o = ctor.newInstance(new Object[0]);
} else {
-o = ctor.newInstance(new Object[] {this});
+o = ctor.newInstance(new Object[] {project});
}
if ( project != null ) {
project.setProjectReference( o );
cvs commit: ant/src/main/org/apache/tools/ant/helper ProjectHelper2.java
costin 2003/05/03 07:30:26
Modified:src/main/org/apache/tools/ant UnknownElement.java
src/main/org/apache/tools/ant/helper ProjectHelper2.java
Log:
Plug the namespace uri. One way or another - we'll need it.
Also fix the qname - we need to use the localname.
Originally used qname to avoid breaking build files that used : ( they still
needed to declare a namespace for that previx - otherwise SAX would complain
).
( not sure about the last part - I think some parsers, when validation is
off, will
allow : to be used and pass whatever was used as qname ).
Revision ChangesPath
1.49 +22 -0 ant/src/main/org/apache/tools/ant/UnknownElement.java
Index: UnknownElement.java
===
RCS file: /home/cvs/ant/src/main/org/apache/tools/ant/UnknownElement.java,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- UnknownElement.java 28 Apr 2003 12:42:47 - 1.48
+++ UnknownElement.java 3 May 2003 14:30:25 - 1.49
@@ -73,6 +73,11 @@
* been redefined since original creation.
*/
private String elementName;
+
+/**
+ * Holds the namespace of the element.
+ */
+private String namespace;
/**
* The real object after it has been loaded.
@@ -103,6 +108,23 @@
*/
public String getTag() {
return elementName;
+}
+
+/** Return the namespace of the XML element associated with this
component.
+ *
+ * @return Namespace URI used in the xmlns declaration.
+ */
+public String getNamespace() {
+return namespace;
+}
+
+/** Set the namespace of the XML element associated with this component.
+ * This method is typically called by the XML processor.
+ *
+ * @param namespace URI used in the xmlns declaration.
+ */
+public void setNamespace(String namespace) {
+this.namespace = namespace;
}
/**
1.19 +2 -1
ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java
Index: ProjectHelper2.java
===
RCS file:
/home/cvs/ant/src/main/org/apache/tools/ant/helper/ProjectHelper2.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- ProjectHelper2.java 28 Apr 2003 12:19:18 - 1.18
+++ ProjectHelper2.java 3 May 2003 14:30:26 - 1.19
@@ -753,7 +753,8 @@
/* UnknownElement is used for tasks and data types - with
delayed eval */
-UnknownElement task = new UnknownElement(qname);
+UnknownElement task = new UnknownElement(tag);
+task.setNamespace(uri);
task.setProject(context.getProject());
//XXX task.setTaskType(qname);
Re: Roles (was: antlib)
Stefan Bodewig wrote: On Tue, 29 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: - Should we use (parent, child) tuple to find the class? Should we use (ParentClass, parent, child) tuple ? I'm not sure what the difference is, here. In the second case, the parent class is also used when constructing the child - i.e. introspection or some other info could be used. BTW, by parent I mean parent namespace + parent element name ( even if we don't use ns yet ). OK. I think we'll need ParentClass to apply proper interface resolution. I'm somewhere on the fence, to be honest. Same here :-) I don't see a need for separate namespaces depending on the interfaces, so only using the child's element name (and namespace) could be enough. I'm not sure whether I'm overlooking a problem. Not sure I understand. Namespaces are not required to solve the polymorphism problem. My concern was the API used by ComponentHelper - I would rather add the parent parameter, even if it's not used now, if we expect we'll find some use cases that will require it ( say in 1.7+ ). In a previous mail I said child alone would already break down today. What I had in mind are things like the fail element nested into sound clashing with the fail task - all those things that make a DTD impossible to write for Ant. Adding namespaces could reduce this problem. The fail inside sound could use a different namespace than the core fail element. Without namespaces - the context ( i.e. parent ) seems to be required. In any case - making it available to the helpers that creates the components can't hurt :-) But these existing name clashes only exist for the non-overloaded cases that we are still going to support. I.e. they exist because SoundTask defines addFail(SomeObject) which is fine as it is not ambiguos at all. For overloaded methods - one way or another we'll need additional info from the user. I'm fine with either syntax - I would preffer the type attribute ( which could be an ant:type when we add namespaces ), but I'm ok with either solution. An alternative to a magic namespace would be magic attribute names. We can use attributes that contain dashes dependset zipfileset use-as=srcfileset /dependset use-as quite clearly states the user's intent and it is impossible to have an existing attribute for tasks or nested elements. Sounds good ( not use-as, but magic attribute ). Maybe ant:type would be better ? The attribute should be optional - i.e. required only for overloaded elements, i.e. 2 methods with the same addXXX signature, and it should be matched against the method name. use-as=srcfileset - addSrcfileset() I'm +1 on this solution for the overloading problem, can't think of anything better. Costin
Re: NameSpace antlib was (Re: polymorphism)
J.Pietschmann wrote: Costin Manolache wrote: There are working and valid systems ( Axis, Xslt ) that use the namespace with associated meaning. The expanded XML element/attribute names get a meaning through an processing model, nobody denies this. The problems start if someone associates a specific semantic with the form of a namespace name, for example mandating that it points to a library in order to associate expanded element names with a meaning rather than to use a single spec. I agree that having the NS URI as a file path on the local system wouldn't be perfect. And IMO it would be also bad to use some completely meaningless and random UUID. Something in the middle - like the package name - would be IMO good enough. For example: xmsns:jmxantlib=ant:org.apache.commons.modeler.ant The package can be used to locate an /org/apache.../antlib.xml. Keeping antlib.xml in the package would avoid merging problems ( in META-INF - if you combine 2 jars for example ), and may be even cleaner. Costin
Re: Roles (was: antlib)
Stefan Bodewig wrote: On Mon, 28 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote: If ParentClass has no addMyChild()/createMyChild() method, we'll need to look up in some table and find a class associated with myChild. OK, well, maybe, see below for an alterbative view. We'll then look in ParentClass for an add method with that particular interface as parameter. The use-case is too simple as the ParentClass could have more than one method with that interface (or even different interfaces implemented by the class mapping to myChild). You're right. With addConfigured() proposal - it can have only one method with a particular interface, so this is not a case. Let me think about this use case. - should we add a separate table for child-class association - or just use the typedef ? A single table. Good :-) - Should we use (parent, child) tuple to find the class? Should we use (ParentClass, parent, child) tuple ? I'm not sure what the difference is, here. In the second case, the parent class is also used when constructing the child - i.e. introspection or some other info could be used. BTW, by parent I mean parent namespace + parent element name ( even if we don't use ns yet ). Or just child name - i.e. context-free ? No, would already break down today. In this case I think the first change should be in ComponentHelper signature, which now creates the tasks/types/etc based only on NS and element name. - addComponent( MyRole ) or addMyRole( MyRole ) or both ? I assume you are taking MyRole as the name of the interface here, as I'm not convinced that we need formal roles at all. Not even the name of the interface - just allow the user to use an intuitive name. But you're right - this open the case where multiple interfaces with the same parameter are used, and we'll not know what to call. I.e. a fixed-name method, with overloading to support multiple roles, or one add method per role ? Neither is enough IMHO. - should setComponent be used to indicate single-child ? No. Let's keep set* for Attributes. Ok. Let's take DependSet as an example. It has two kinds of nested FileSets, srcfileset and destfileset. For the sake of discussion lets assume that placing ClassFileSet or ZipFileSet for either kind of FileSet was useful - I think it is at least for ZipFileSet. dependset ... zipfileset src=some.zip/ /dependset with the approach you describe, If we follow the name determines implementation route you've described here, both addSrcfileset(FileSet) and addDestfileset(FileSet) would be candidates for methods to call. We need a way to resolve this - probably via an extra attribute that explicitly says I'm a srcfileset. Something like dependset ... zipfileset src=some.zip element=srcfileset/ /dependset Well, the child is still created by the element name - you are solving what method to call problem. The alternative approach (taken by Mutant IIRC) would look like this dependset srcfileset src=some.zip type=zipfileset/ /depenset I feel this second approach is easier in the (rare?) cases where things are ambiguous, but it also forces people to always explicitly state the type. I'm not sure that the later is a drawback, though. Not allways, only for tasks that have overloaded/ambiguous methods. The type could be the local part of the add method ( addZipfileset ), which sounds intuitive. With this approach the parent completely determines which element names are supported as nested elements and at the same time clearly states which interface is expected from the child element. +1 This makes documenting stuff a lot easier. Imagine the nested elements of copy. copy accepts nested filesets or any element whose name maps to a class that extends org.apache.tools.ant.types.FileSet? I think the learning curve for beginners to grok copy ... classfileset .../ zipfileset .../ /copy is steeper than the alternative copy ... fileset type=classfileset .../ fileset type=zipfileset .../ /copy I'm not really sure myself, I've argued the first approach myself when we discussed it the last time around (because the non-ambiguos case requires less typing 8-) For non-overloaded case - which in the original antlib proposal doesn't seem to even be possible - I think determining the method to call is simple, and no extra info is needed. For overloaded methods - one way or another we'll need additional info from the user. I'm fine with either syntax - I would preffer the type attribute ( which could be an ant:type when we add namespaces ), but I'm ok with either solution. Not sure I understand your position on how to create the child class, the overloaded method is related to what add method to call. You seem to preffer use parent element name and child element name. I'm ok with this - we'll just need to figure what syntax will be used to express this, and change
Re: NameSpace antlib was (Re: polymorphism)
Nicola Ken Barozzi wrote: ... The proposal antlib provides a task antlib which can be used to load libraries manually. Al the same time there are hooks on the code for an autoloading mechanism to be supported. In escence, it would allow ANT's main() to do something like: - get all antlib.xml from the classpath ( using getResources); - process each one of the antlib.xml resources found so that all definitions get registered. All the processing is provided by a static method of the Antlib task. In principle this was designed just for loading the core at load time, we could expand it to allow loading all jars (antlibs) in the classpath, which means all antlibs in the ANT/lib directory. This I really liked but Costin IIRC put it down in favor of compulsory explicit loading. loader ( which is a wrapper around AntClassLoader ) allows adding to the core loader, to solve junit-like problems, but can also allow operations on arbitrary classloaders. I think the class loading - even if it is a very difficult problem - shouldn't be the major concern. There are systems with far more complex needs ( jboss, tomcat, etc ). The main issue is how to enforce ordering to deal with dependencies between the antlibs. Or simply do not deal with dependencies, ie antlibs must not (yet) depend on on the other, except for the core ones. Using an unified class loader ( at least as default ) - like jboss is doing, or like JMX loading policy - has a lot of benefits. It also has some cases that are not well covered - so we'll probably need to deal with both unified loader and loader hierarchy cases. My concerns with getResources() as oposed to getResource( PACKAGE/antlib.xml): 1. startup time. In order to load one library you need to process all of them. It can be resolved with caching the result and looking at .jar modifications. Most likley we'll have dozens of antlibs - and that'll only grow in time. The processing of (all) TLDs at startup ( for tomcat ) adds a very visible overhead on startup, and at least tomcat is a long-running process. 2. Placing multiple antlibs in a single jar may be trickier. 3. It may place too much emphasis on the .jars and filesystem layout. 4. A bit harder to control ( as we know from c-logging and JAXP ), 5. Explicit control over what antlibs are to be used - versus loading everything. Well - I like magic loading, but a lot of things in ant are done explicitely. I have no problem accepting a getResources() solution ( just like I'm ok with using XML - but not any XML :-), but those issues should be considered. A lot of the mess in ant is the result of doing some things without considering all implications or just as side effect of how code happened to work. That's why I'm so strongly for breaking things down to individual problems instead of a bundle solution. Costin
RE: Roles (was: antlib)
in different contexts- by the addFoo() pattern - but I wouldn't want to go in this direction. I think we should either use taskdef/typedef - with the additional attribute for the adapter - or use a new element component ( or even role - but I don't find this very intuitive ) that will replace both taskdef and typdef. For example: component name=elementName className= [adapter=] / I do not mind having a component but with the syntax: role name=roleName className= [adapter=] / component name=elementName role=roleName classNane=. / role could be just component role=role .../ but I think is less clear. Ok, that's something we stand on totally oposed positions. It just doesn't make sense to me having the adapter associated with the role. component name=elementName className= [ adapter= ] / BTW, my prefference would be to actually just use typedef as the definer ( with the additional optional adapter attribute ). But I'm fine with a new element name. Costin
RE: Roles (was: antlib)
. Think of the weblogic element of ejbjar and jspc they are different APIs but the element is named the same. So you first need to collect what possible roles are posible at this point (by looking to all the addInterface as you call it). Then we can go and look for foo on those particular interfaces. If at the end you find one and only one unambiguosly then you succeeded. BTW, the reason I would prefer to use addConfigured is because we have already taken over that method name as one of our patterns, and hence is safer for BC. Using addInterface or addRole my clash with somebodies task that uses those names legitimately today. By addInterface I meant using some specific name, like addCondition or addJspc. But your example makes sense - there are cases where jspc needs to create a different class based on context. I would consider this the non-simple case, and I agree we should be able to eventually handle it with some special syntax. I'm not sure a special name is actually required ( addConfigured) - just an add or set method with the interface/class as parameter, and then match them on type. the idea of using addConfigured as the name in because I think we need to be clear on the parsing rules for this objects. Allowing passing not configured objects seem to make little sense since the implementation is completely blackboxed to the parent node. What about add[INTERFACE_NAME]( INTERFACE_NAME ) ? So you mean something like: addorg.apache.tools.ant.role.Condition(org.apache.tools.ant.role.Condition)? :-( No, just addCondition( org.apache.tools.ant.role.Condition ) when I said the role is the interface I meant it. I see no reason why the name of the interface has to be part of the method name. It's cleaner and more intuitive. And I think it's a common pattern. The actual name of the method is more for users convenience - we use the parameter signatures for the association ( in this case ). set methods work with simple types only - and IMO if we add roles, setROLE( ROLE ) should be used for roles where a single child is allowed, while addROLE( ROLE ) for multi-childs. I just do not want to create more confusion on users. The rules today are quite simple and easy to follow. set for attributes, add/create for subelements. It is a very simple rule. I do not want some new special case that only applies roles. If or when set methods are allowed for single elements or attributes, then we can generalize it to roles also. Ok. The interface for Tasks can have as many adaptors as you want using diferent names to refer to them. Think of role names really as role aliases. Aliases for the same interface, each providing a different adaptor, if needed. What do you mean ? I should use the name task if the task adapter is used, but a different role name if a different adapter is used ? No, the pattern for adapter/wrapper is pretty clear, and your use is wrong. component name=elementName className= [ adapter= ] / BTW, my prefference would be to actually just use typedef as the definer ( with the additional optional adapter attribute ). But I'm fine with a new element name. Yes we disagree, what you present will not solve the case of vendor specific elements like weblogic or jboss whose meaning depends on the context. Would you allowed something like: component name=jboss classname=jboss.ebjjarAPI/ component name=jboss classname=jboss.jspcAPI/ component name=jboss classname=jboss.serverdeployAPI/ Now are you changing the definition of jboss or are you adding distinct definitions for distinct roles. How would anone understand what this means? As I said above, this is a valid case - but it's not the simple or common case. For jboss - you actually need to express that the child name jboss will have different implementations based on the parent ( or some other condition ). Not sure I understand how you would resolve this with your proposal - by defining different roles of jboss ? I can live with having such extra syntax for the non-common case, but not to require it for the common case. BTW, one alternative solution for associating the name with an implementation class is the use of namespaces. Axis does that quite extensively, and seems to work very well. parent ejb:jboss ns:ejb=java:jboss.ejbjarAPIImpl / /parent or something similar. Still we need this if we want to be able to send the responsability for maintaining vendor specific code back to the vendors. Roles came up from the need to achieve exactly that. Adaptor came from looking at the actual mess we have in our type system and try to put some standarized mechanism that can dealt wih it. I think the type system is not that bad ( or at least it's cleaner than the mess you propose :-) Costin
Re: Roles (was: antlib)
. Declaration of implementations (members): A class is declared as belonging to a role by specifying the name to be used when appearing in that role. The same class may belong to multiple roles and may specify the same or different names on each one. The name used for the role during the declaration only determines which Adaptor will be available, if required. Within a role-interface there can only be one object associated with each name. Scoping rules: = This is probably the more dificult aspect since given the way ant and antcall work it means possible redeclarations on every level of recursion. Whether declarations should just supercede one another or be smarter is something to look into. I'll let other comment on this :-) Syntax: == I have left out the issues of how the syntax looks like on purpose. Syntax is just that and I am sure we can reach agreement somehow. It is also clear that we should provide tasks to define roles and declare members of roles direclty on the build. Ok, this is it. If you have any strong opinons about it, let me know. You already know my strong opinion. I think we should either use taskdef/typedef - with the additional attribute for the adapter - or use a new element component ( or even role - but I don't find this very intuitive ) that will replace both taskdef and typdef. For example: component name=elementName className= [adapter=] / Costin Jose Alberto -Original Message- From: peter reilly [mailto:[EMAIL PROTECTED] Sent: 25 April 2003 13:22 To: Ant Developers List Subject: Re: antlib On Friday 25 April 2003 12:24, Jose Alberto Fernandez wrote: Peter, this is exactly my point. For every new thingy that we add we now need to go and modify IntrospectionHelper or something to make special allowances for it. The dynamicelement addition to IntrospectionHelper is general and new thingies can be added without affecting core ant. It is bloating the core like mad and in my opinion it is crazy. We need a unified way to treat this things no matter what the things are. Ant's engine core should not need to know anything about anything. Dynamicelement has the potential to remove code (e.g. all the addNAME methods to conditionbase, selectorbase, and filterchain). The only problem is name clashes. In an ideal world, we should have an engine core with no reference to any task/type or its implementing classes and a core-antlib which provides the classes and definintions for all the task/types/conditions/selectors/mappers that define core java. This can be done with dynamicelement, except for name clashes and mapper (which does not use sub-elements for different filenamemappers). Peter. Ps: I am including mods to IntrospectionHelper.java and DynamicElementHelper.java
RE: antlib
Jose Alberto Fernandez wrote:
Peter,
this is exactly my point. For every new thingy that we add we now need to
go and modify IntrospectionHelper or something to make special allowances
for it.
It is bloating the core like mad and in my opinion it is crazy. We need a
unified way to treat this things no matter what the things are. Ant's
engine core should not need to know anything about anything.
Fine - but do this in core, not in antlib.
Antlib needs to load whatever ant supports. Not to define new things.
I don't have any problem with polymorphism ( or roles ). Nobody said they
shouldn't be added. My only comment is that the implementation of
polymorphism shouldn't be tied with antlib, and I would preffer a solution
that would simplify the core - i.e. interfaces or something like that, that
would allow us to treat all components as components at the low level.
An unified way to treat all the sub-types should be defined and implemented
as part of the core.
We can wait with antlib ( the part that loads whatever-things-ant-supports)
until polymorphism is defined, but I would preffer having antlib included
in ant sooner.
Costin
In an ideal world, we should have an engine core with no reference to any
task/type or its implementing classes and a core-antlib which provides the
classes and definintions for all the
task/types/conditions/selectors/mappers that define core java.
We could even have separate release cycles for it.
THAT is the potential for antlib (and it is not polimorphish).
Jose Alberto
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: 25 April 2003 10:30
To: Ant Developers List
Subject: Re: antlib
On Friday 25 April 2003 08:31, Stefan Bodewig wrote:
On Thu, 24 Apr 2003, Costin Manolache [EMAIL PROTECTED] wrote:
Look - adding roles concept to ant, and adding antlib are 2
separate issues.
+1
I tend to agree - that's why I proposed to get antlib into the main
trunk with support for types and tasks only. At least for starters.
If you want a custom mapper you can do so right now with a data type
and refid. The same is not true for filter readers, conditions or
selectors. But I feel that enabling that would inevitably
lead us to
Not quite true for filter readers.
In CVS HEAD, FilterChain has a currently (deliberate)
undocumented feature of
implementing DynamicConfigurator. The implementation looks up the
name in the types and if present and if the bean implements
ChainableReader
it is used as a ChainableReader.
This is used to support ScriptFilter. Script reader is an optional
ChainableReader which depends on the presence of BSF and thus cannot
be implemented in the same way as the other built-in ChainableReaders.
the more general polymorphism discussion and this is what I
wanted to
avoid 8-).
I have implemented a generalization of FilterChain's
usage of DynamicConfigurator in IntrospectionHelper.
This extends the introspection support to include methods of the form:
public void dynamicElement(type name);
So in my local ant build the relavant part of FilterChain.java is
public void dynamicElement(ChainableReader reader) {
filterReaders.addElement(reader);
}
and of ConditionBase.java
public void dynamicElement(Condition condition) {
conditions.addElement(condition);
}
As regards using roles:
(note: Roles in the antlib proposal are not completely implemented,ie.
there is no condition, mapper or filter implementation so
my comments may be correct).
Roles in the proposal provide three features:
1) they provide a way of limiting the scope of the tag. I assume that
this is meant to be used by introspection in the same way as
the dynamicElement method above.
2) As a consequence of 1), the same identifier by be used to
point to different classes.
3) they provide an optional adaptor to allow classes that do
not support
a requred interface.
These features may be implemented in different ways, for example:
typedef could be extended to have an implements attribute:
typedef name=and classname=o.a.t.ant.taskdefs.conditions.And
implements=o.a.t.ant.taskdefs.conditions.Condition/
and may then only be used in beans that have the method:
public void dynamicElement(Condition condition)
if the class did not implement the condition, a proxy class
could be defined:
typedef name=diskfull classname=acme.disk.DiskFull
implements=o.a.t.ant.taskdefs.conditions.Condition
proxy=acme.ant.ConditionAdaptor/
or one could have a class that defines adaptors:
a new task may define adaptors:
adaptor classname=o.a.t.ant.taskdefs.conditions.Condition
proxy=acme.ant.ConditionAdaptor/
My feeling
RE: antlib
Jose Alberto Fernandez wrote: From: Costin Manolache [mailto:[EMAIL PROTECTED] Fine - but do this in core, not in antlib. But this are changes to core. Granted they are comming as part of the bundle but they are not in antlib. All I ask is to do the changes in the core separately. Costin
Re: Antlib descriptor
Erik Hatcher wrote: - maybe we want antlibs to have some initialization. This can be easily done by allowing more ant elements in the descriptor - maybe we'll want to allow antlib to declare targets - that could be used in depends or antcall ( target name=foo depends=myAntLib:antlibTarget/ ). Wow ok, still pondering Please - don't take this as we should do this. It may be the worst idea ever. What I'm trying to say is that a lot of things we might want later will be simpler, and we won't have to bloat the antlib SAX processor to implement such features. I'm sure there are some valid uses cases and extensions that we may add - even if those 2 use cases are completely wrong. It is very unlikely antlib will never change. Again - those are just examples, there are a lot of things that could be done easily. Even if you don't need any of this - it would be nice to not have to repeat the long and painfull evolution of the main xml processor. It'll take some thinking and convincing for me to see why antlib needs descriptors that get processed like Ant build files. Something as simple as Digester would seem to do the trick (bootstrap craziness?!) but as I said, I want to see what others think and let myself consider your idea a bit more. - consistency. I think it would be a bad idea to use Digester in antlib and another mechanism in ProjectHelper. Plus digester would add dependencies on beanutils, collections - we already have introspection code. I can accept replacing ProjectHelper with Digester - but I would like we use the same mechanism. - same kind of extensibility as ant. It may not be perfect - but at least will be consistent and most people understand it. - We can just use the same ( or almost ) code for taskdef, roles and whatever else we want to allow to be defined in antlib. - very easy to implement ( minor changes in ProjectHelper to parse antlib at top and restrict the childs ). Actually, antlib could be a task ( so antlib elements could be used in a build file - another stupid idea ), and we can just change PH to start with a different root. - easier to maintain. I know we're all SAX experts, but we've seen a lot of tricky aspects in ProjectHelper long evolution. This way we maintain a single parser - and a single behavior. - all the wonderful features that may be easily enabled ( if they prove to not be very bad ideas ). I can add more to the list. Costin
RE: Antlib descriptor
Jose Alberto Fernandez wrote: I am not too keen on having alive ANTS roaming in my classpath. Jar files are passive things, in general having too many in your classpath does not mean you will execute more stuff. I think that is nice and autoinitializing jars (antlibs) sound way too scary at this point. AFAIK the proposal doesn't implement autodiscovery - and we don't know if we will get getResources(META-INF/antlib.xml ) or require explicit antlib In any case - it is easy to give user explicit control. In many systems libraries have a initialization mechanism. We may only allow conditions for example - but I don't see anything fundamentally wrong with this, that would guarantee we'll never want to do this. Same for allowing libraries to define fragments and targets - maybe today most people thing it is a crazy idea, but one year from now we may find it usefull. Of course, we could change the parser then - but we'll accumulate a lot of behaviors that would make this difficult. Costin
RE: polymorphism (was Re: antlib)
Wannheden, Knut wrote:
project
.. init properies .../
use xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/use
/project
Or even:
antelope:if xmlns:antelope=antlib:${ant-contrib.jar} /
In any case - if ComponentHelper is used, it'll get
antlib:/path/to/ant-contrib.jar as first param and if as the second param
- and any helper in the chain can create the task.
I don't like passing the .jar very much - but that's probably the only
way if we want to use META-INF/antlib.xml.
The alternative would be to use /net/sf/antcontrib/antlib.xml (i.e.
descriptor in a package ), and use antlib:net.sf.antcontrib as namespace.
Then getResource() can be used, and we don't have to worry about
multiple jars providing META-INF/antlib.xml - which forces us to use the
.jar file directly.
Costin
That is almost the same thing as I had in mind. Although I've been
thinking about some slight variations to this, where no top-level element
like use/
would be necessary. The Jelly style would be:
project xmlns:antcontrib=antlib:${ant-contrib.jar}
xmlns:antelope=antlib:${antelope.jar}
.. init properies .../
target name=test
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
Here target/ is still toplevel and the antlibs are loaded on project
initialization (or on demand). But I'm not sure I like this automagical
loading. Something inbetween would be this:
project
.. init properies .../
use resource=${ant-contrib.jar} ns=antlib:ant-contrib/
use resource=${antelope.jar} ns=antlib:antelope/
target name=test xmlns:antcontrib=antlib:ant-contrib
xmlns:antelope=antlib:antelope
antelope:if
/antelope:if
antcontrib:foreach ...
/target
/project
which is slightly more verbose, but cleaner IMO. Especially since the
antlib loading is explicit.
--
knut
RE: antlib
Jose Alberto Fernandez wrote: If we are to use XML, let's at least use ant syntax - i.e. antlib taskdef typedef ... /antlib Things people already know and understand, we have all the code to process it, and if we want to extend - it's quite easy. Please, don't invent a new language. But we are. To start with the top element in antlib and not project your things inside are not the taskdef tasks, they are something different (for example the file, resource, classpath, classpathref and loaderRef attributes are meaningless here) What I meant is the antlib descriptor would be an XML file that is a subset of the ant syntax. We can restrict this to taskdef, typeded, condition and few other that we need, and add more later. It will confuse people more than anything else if the two things have the same name. The 2 things will be the same thing. In particular the language that is in the proposal - which IMO is the worst part in it. Sorry to here that. The language was trying to make writing antlibs easier you really only have one basic declaration which defines the elements available to you: role name=X classname=x.y.Z adaptor=p.q.R/ every declaration like this, implicitly makes available a new element tag: X name=Xname classname=Xa.Xb.XC/ That's it. The DTD is dynamic just like the DTD of ANT is dynamic. The only think that the implementation gives you is that the role declarations for task and type are implicitly declared incide the antlib element. That's it. I thought that was as simple as I could do. The problem is that: - instead of only defining the ant lib, it also adds concepts of role. If everyone but me wants roles - I could live with it, but _not_ if they are added as a side effect of the antlib. - do you call this simpler or easier than the properties file that we use currently ? The common use case is defining tasks and datatypes. I support properties because: - that's what people already do. If we need XML later for extra fancy things, very easy to add. - it keeps the overhead to a minimum at runtime - it is _not_ easy to bloat it. Properties files are the most abuse thing in java, tryings to encode as much information as possible in the name of the key. If you take a look at things like log4j and such their P-file configurations are just as full of this.that.1.here=X this.that.1.there=Y The fact that others abuse properties doesn't mean they are wrong. There are a lot of abuses on XML ( far more than properties ). ( I haven't tried the new MSFT office - but I heard that it has some very easy use of XML ). Again - I have no problem if we don't use properties and use XML instead. My requirement ( and I'm going to fight as much as I can for this ) is to keep things _simple_. J2SDK1.2 + defines a mechanism for declaring dependencies. Which is actually required for servlet containers and j2ee. (i.e. the manifest ). Why would we want to invent our own ? JDK only defines a mechanism to indicate which other jars are need to be loaded to find additional classes (which are located relatively to the current jar) I assume you're talking about the ClassPath, which is just a way to specify the CLASSPATH, and has nothing to do with dependencies. I was talking about the real dependency part - with Requires-XXX. This is not dependency declarations. Costin
Re: antlib
Antoine Levy-Lambert wrote: Can you give us some pointers so that we can learn about these Extension-Name and Extension-List elements and understand how they help out for antlib ? http://java.sun.com/j2se/1.4.1/docs/guide/jar/jar.html#Main%20Attributes http://java.sun.com/j2se/1.4.1/docs/guide/extensions/versioning.html Servlet 2.3+ required containers to support this, there are many servers that use this information, many packages already include a manifest and are starting to support this. I'm not saying this is perfect - but it is a reasonable and standard solution, and better than us inventing our own. It defines a hook that allows you to plug your own component factory. You get a namespace and element name as parameter, and you can return any ProjectComponent. It is used like the PropertyHelper ( i.e. a chain, any task can add hooks ). Nothing fancy. Can you supply some Hello World examples of what can be done with the ComponentHelper task or give us pointers to such examples. I'll try to add more documentations and an example. I have no problem with using XML syntax and not properties- if it's a subset of ant, or something close enough. I'm -1 on combining antlib with roles and using the syntax in the proposal. Which problem do you see with this notion of roles ? For me it is clear. Look - adding roles concept to ant, and adding antlib are 2 separate issues. If everyone else except me wants to add roles - and doesn't want to use interfaces, but explicit declarations - I could change my vote to -0 on roles. Using XML for descriptor - fine, as long as it is not a completely new format. Using a subset of ant is IMO a very good solution, and it would allow us to easily enhance it later on. Mixing roles with antlib proposal - that's where I'm strongly -1. Costin
Re: antlib
Erik Hatcher wrote: We don't really need to get hung up on the syntax of a descriptor at this stage. Let's get something working in HEAD and work with it. XDoclet can be used to generate these descriptors anyway, and it likely be considered the best practice way to do it anyway. I think the syntax of the descriptor is pretty important. Xdoclet is great - but the fact that it can generate any descriptor shouldn't mean the syntax of the XML can be anything. The biggest problem with XML is that people just throw away new syntaxes, and claim some tools will support it anyway so it doesn't matter what's inside. Just look at the dozens of RSS versions, or the office XML, or the dozens of configuration XML formats. That's it. The DTD is dynamic just like the DTD of ANT is dynamic. This is where I differ. I like what I've heard so far, but I really don't like the total looseness of Ant build files, and I don't think we should propagate that same scheme. I understand how it evolved and that ease of use was one of the primary factors for Ant's looseness, not to mention that it was around before namespaces were really solidified. The looseness is pretty fundamental in ant, and at least IMO is one of the reasons it works so well. We don't need these descriptors to have dynamic element names, do we? Again, lets not get hung up on the descriptor syntax. Working implementation first - then we can debate the details. We can make it the defining goal for an Ant 1.6 release when all the fiddly details have been ironed out! :) We have had working implementation(s) for quite a while. It's the fiddly details that are the problem. Costin
RE: antlib
Dominique Devienne wrote: From: Costin Manolache [mailto:[EMAIL PROTECTED] Sent: Thursday, April 24, 2003 12:23 PM The common use case is defining tasks and datatypes. So you -1 roles because you don't need them, at the expense of all the people who need to declare more than tasks and datatypes, but conditions, filters, mappers, and for me my own custom extension like the buildpathresolver??? No, because they add complexity to the simple case and to the lower layer. I have nothing against roles - if implemented at a higher layer ( using interfaces, declarations, introspection - or any other means ). I am -1 on bundling the roles with the antlib. You want roles ? Make a proposal for roles. You should be able to use roles without antlib, and you should be able to use antlib without roles. So how do *you* propose we plug in custom implementations of all the things mentioned above, if not with roles? --DD Add them as project compoenents ( or types if we don't merge tasks+type ), and use interfaces, or introspection, or any other form of metadata. Costin
RE: antlib
Dominique Devienne wrote: Tell me what's the point of AntLib if it's just to define tasks/types? That's what currently supports tasks and types. There is no notion of role at this moment in ant. I don't know how you twisted my words into I don't want roles. I just don't want roles implemented this way, and I want the antlib to do one thing well, When roles are added to ant, in one form or another, we can add them to antlib. Are you saying that those roles can't be used without antlib ? Sounds like you have never needed to write anything but custom tasks and types Costin, but it is a major deficiency of Ant not be able to plug in a consistent manner all these other 'types' of typed bean you so easily dismiss. --DD I don't dismiss the the types, nor the consistency. I dismiss bundling the concept of roles with that of antlib, and the idea that there is only one possible implementation for that ( i.e. what's now in antlib ). You can have the same role using interfaces or using introspection or using external metadata. And you can have an antlib that deals with loading components - without caring what kind of components they are, and this is a simpler and better implementation ( IMO ) Costin
Re: antlib
Erik Hatcher wrote: So you believe that anything can go in the XML tags, no design or thinking is needed - because you could translate it with XSL or some tools will process it ? This is getting a bit exaggerated but I don't feel the syntax of an XML descriptor is that relevant right now given the other issues on the table. That's the main point I'm making with this. For Antlib ( i.e. having the task/types loaded ) - the only remaining issues that I know are the descriptor syntax and format ( and it seems most people want the XML, so the syntax remain the only problem in this space ), and the use of namespaces. For NS - it seems we can do it later. For roles - that's IMO a different problem. But the current one does not support adding other components like conditions, mappers, filters, and selectors. Does ant support this ? No, not currently in a pluggable manner. Isn't that the goal for antlib? To load collections of ant components ( whatever ant define as component ). Not to define new component types. Are you saying that all those nice filters, selectors, etc can only be used if loaded by antlib ? You can define a task with taskdef in a regular ant file - why wouldn't you be able to define the condition without using an antlib ? Costin
RE: antlib
Dominique Devienne wrote: Because: 1) Having an xyzdef for every single one adds new elements for nothing, and is not extensible to custom types (like buildpath) to define its own new typed role/interface (buildpathresolver). You only need a componentdef ( or just use the existing typedef ) - and have class implement whatever interface you need. You can define any role you want by having an interface and classes implementing this interface. Costin 2) antlib supercedes taskdef/typedef (which remain for backward compatibility), adding extensibility to other types (within Ant or not)! Why are you getting hang on antlib per se? What's bad about having an in-build-file antlib? It's not worse than a taskdef, and better because extensible to new roles/types/interfaces/beans, whatever! The point being that AntLib doesn't define new component types, it allows *me* and *every other* build file writer to define my own new component types and/or implementation of existing component types. I don't care how you want to implement it! I want the functionality AntLib provides ASAP, so if you don't provide a 'better' proposal that solves the same issue, namely being able to plug in not just types/tasks to Ant which are configured like regular types/tasks, then your -1 squarely goes against my *need*, and the needs of quite a few others; a need I hope you agree is important... --DD
Re: antlib
Stefan Bodewig wrote: On Wed, 23 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: If everything is defined as a component at a low level, then they can be easily introspected to find out what interfaces components implement. This breaks down if there is no specific interface for a role - like task or data-type. And also doesn't address things that can be in multiple roles. Interfaces _and_ patterns. ( and in interface I also include extending some base class like task ). If it has an execute() method - that method will be called, even if you don't extend Task. It would be nice to have init()/destroy() patterns on the datatypes as well. What matters at low level are components. What matters at high level ( i.e. from a target perspective, or a task that includes other tasks, or a datatype that uses some roles or conditions ) are the operations that a component supports. Operations can be expressed by interfaces, or by patterns. It may sound a bit to JMX-ish, but this is something that works amazingly well. Everything in tomcat is becoming a simple JMX component. JBoss ( which is even more complex ) operates in terms of mbeans - with init/start/stop/destroy pattern. If some mbean happens to be a servlet container and another mbean happens to be an EJB container or just a simple logger or set some properties - it doesn't matter. And what's nice is that we don't need to change much in ant to achieve that. We can say it's almost already available. At least for task I'd expect some strong opposition against an interface that marks them up. Hi Costin ;-) Of course. There is no need to have a Task interface, or even require Task to be extended. Ant's strength (IMHO) comes from the lightness of the framework. Just add an execute method to your java bean and you can use it in ant. Very low entry point, no pressure, no strong dependency. JMX is the best analogy, and it's used with success in things far more complex than ant. You only have to support certain operations. That's not to say I'm against using interfaces to define roles - my only problem is to keep the interfaces informative, not required. There is no need to be stricter than JMX - which also uses interfaces, but supports declarative model ( model mbeans - you just use descriptors, and any java object ) or direct calls ( dynamic mbeans ). Costin
RE: antlib
Dominique Devienne wrote: Let's turn around your question: Tell me of a (string) role (beside the special task/type cases) that would not be an interface? What good a bean is, if it's not of an expected Java type? What method or field are you going to use/call on it? Any role. Just like you can put any java class with an execute() method in a task role, or any java bean in a datatype role. Interfaces are fine - they define a set of methods and contract that a class must support. But it is perfectly possible to support the contract without implementing the interface. In JDK1.3+ ( and JMX1.2+) you can use a proxy that implement the interface - but what really matters is the contract, not the syntactic detail. Ant ( and JMX ) have allways had a loose coupling aproach. You can write a lot of tasks without having any dependency on ant. I agree with Costin, all tasks/types become simply beans. You should be able to use any one of these beans in any place it's suitable to use it, i.e. any time the Java type/role requested is part of the bean's type (in the isAssigneableFrom() sense). I agree with you that roles should be associated with an interface. I don't agree that the components need to actually implement the interface, they only need to support the contract. I would like to allow any mbean that has an execute method to be used as an ant task. Or any mbean that supports a particular contract to be used in the associated role - without having to change the mbean and make it depend on ant. The type being requested depends on who requests it. Inside or outside targets, it's any bean. And I mean really any bean: Doesn't need to Exactly. implement anything Ant-related. This is implicitly what we call today a datatype, and they can be id'd. The subset of these beans that also have an execute method are also implicitly tasks. The different subsets of these beans that implements FileSelector are suitable to use within filesets, and tasks deriving from MatchingTask since we're talking about it. I fail to see what is wrong with this scenario. --DD I think it is a good scenario, and the JMX uses prove it is viable. You may like or dislike Jboss - but their modularity and flexibility ( given by JMX and the low-coupling ) is a proven thing. Costin -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 23, 2003 11:12 AM To: [EMAIL PROTECTED] Subject: Re: antlib On Wed, 23 Apr 2003, Dominique Devienne [EMAIL PROTECTED] wrote: Forcing roles to map to an interface is probably a *good* idea! Maybe, hmm, probably, not convinced ... Every single bean would become implicitly a data-type, and the ones with an execute() method implicitly become tasks. Beyond that, all other roles are interfaces. How would you have a task that also is a condition? It implements Condition and has an execute method? [DD] Yes! What's wrong with that? How would you have a datatype that also is a condition? This may be far-fetched, not sure. Stefan
Re: antlib
peter reilly wrote: On Wednesday 23 April 2003 17:57, Dominique Devienne wrote: Yes, it could be a problem. But running the risk of speaking yet another anathema, I'm starting to believe the Jelly approach of using XML namespaces is the right one... +1 Seems simple to implement and fits in with current usage. Proposal: * place tasks.properties and typedefs.properties the jar file as per bugzilla 17844 +1 Eventually it can be an antlib.properties containing all kinds of components. * have an antlib task that defines a name space for the tasks/typedefs in the jar. - default is the global namespace. We already have one, called taskdef. It needs few changes to support both tasks and types ( if we decide to support both ). Or a new task that extends Definer and loads the descriptor automatically. We can start simple with that, then add more as we need it ( from antlib or elsewhere ) * use a variation of dynamictag or dynamicelement to allow the datatypes to be used in supporting tasks / datatypes Costin
RE: antlib
Jose Alberto Fernandez wrote: This is exactly the point, we should try to type things. Roles Why ? We have components that can be used in any role. Metadata can be extracted and used in a variety of ways - descriptors, interfaces, runtime calls ( like in the 3 kinds of mbeans ). But in the end the user of a component decides in what roles he wants to use it and how. are this typed interfaces expected by the set/add method. The component being declared of a particular role, may or may not implement the interface. If it does cool; if not an adaptor will be used to bridge the gap. It is upto the adaptor to decide if the bean is compatible or not. +1 on this part The guy writing the container (the thing with the set/add methods) does not have to deal with introspection or anything of that. As s/he shouldn't. But by allowing adaptors someone can take some cool object and bridge it. I think the container is ant. Not sure who should write the adapters - IMO ant can support this automatically ( by introspection since we can't use 1.3 features). So, since now this objects come from somewhere else, if it is not typed somehow, any object expecting an instance of the role need to do introspection by hand. Not good. No. It is easy to provide this service in ant - just like it is done in JMX. Code using JMX never does introspection - just calls the invoke method. If JDK1.3 is used, he can get a proxy that implements the desired interface. ( I think it can be done for JDK1.2 as well, but a bit harder ). Costin
RE: DynamicTag
Dominique Devienne wrote: 2) DynamicTag is lazy, thanks to UnknownElement. Your rewrite is creating the element at parse-time, my implementation does it only at runtime. Again, I favor delaying the instantiation and configuration. Ant should never have mingled parsing of the XML and instantiation of the model in the first place. +1 ant1.6 is a bit lazier than 1.5. Something that I wish Ant added was the notion of 'role', to partition the task/type namespace. Both our proposals rely on taskdef/typedef to register the extension points. But a custom selector, a custom filter, a custom mapper, a custom buildpath (in my case) all share the same type or task namespace (the mapping from element name to class name). There are I wish Ant didn't make the distinction between task and type so big. All are project components - and the role is given by how they are used. Not having an execute method is the only special thing about a typedef. currently two distinct namespaces, one for tasks, and one for types, and Costin says I'd like to merge the two, when I actually would prefer to have N namespaces, each indexed/keyed by a 'role' string. When a task Maybe something in the middle :-) I'm saying that from the point of view of the processor, all components should be just simple beans, regardless of how they'll be used or what methods they expose in addition to attributes. You may have as many roles as you want - at a higher level, by either implementing some interface or pattern. You may even have components with multiple roles. As long as at the low level they are all treated as javabeans ( or ProjectComponents ). explicitly declares to accept within it selectors for example, it simply declares it wants instances implementing FileSelector.class from the selectors namespace. So the namespace used to resolve the element name to the classname is explicit, rather than implicit, first trying the tasks namespace, and then trying the types namespace. Classes can of course belong to more than one namespace; tahoeresolver could be both a type (types namespace), so it can be declared outside buildpath and refid'd, but it's also a BuildPathResolver.class, of the buildpath/resolvers user-defined (and documented) namespace). That shouldn't be a concern of the low-level ant ( the xml parser, etc ) tough. And we shouldn't have one registry for each type. Costin
Re: [VOTE] Antoine Levy-Lambert as committer
Stefan Bodewig wrote: Hi all, Antoine has continuously been sending in patches since months now, he's played an important role in the zip refactoring and is answering more question on the user list than most of us here. Furthermore Antoine has access to a perforce installation, so he's able to test and fix those tasks. 8-) Finally he's expressed interest in reviving the antlib proposal. I feel it is time to make him a committer and ask you to vote on this. Let me start with my +1 +1
cvs commit: ant/proposal/embed/src/java/org/apache/tools/ant RuntimeConfigurable2.java
costin 2003/04/10 12:14:03
Modified:proposal/embed build.xml
proposal/embed/src/java/org/apache/tools/ant
RuntimeConfigurable2.java
Log:
Patch from Loïc Péron [EMAIL PROTECTED] to compile against ant153
Revision ChangesPath
1.9 +2 -2 ant/proposal/embed/build.xml
Index: build.xml
===
RCS file: /home/cvs/ant/proposal/embed/build.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- build.xml 29 Dec 2002 06:06:27 - 1.8
+++ build.xml 10 Apr 2003 19:14:02 - 1.9
@@ -26,12 +26,12 @@
target name=build depends=main /
- target name=main depends=init
- echoEmbed is no longer supported with ant1.6. It is only used with
ant1.5 ! The dynamic properties work with both, use embed-optional target/echo
+ target name=main depends=init,main-ant15
/target
target name=main-ant15 depends=init
description=Build hacks into ant1.5 to support some 1.6 features
+ echoEmbed is no longer supported with ant1.6. It is only used with
ant1.5 ! The dynamic properties work with both, use embed-optional target/echo
javac srcdir=src/java
debug=${debug}
destdir=${embed.build}/classes
1.9 +3 -2
ant/proposal/embed/src/java/org/apache/tools/ant/RuntimeConfigurable2.java
Index: RuntimeConfigurable2.java
===
RCS file:
/home/cvs/ant/proposal/embed/src/java/org/apache/tools/ant/RuntimeConfigurable2.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- RuntimeConfigurable2.java 7 Mar 2003 11:22:57 - 1.8
+++ RuntimeConfigurable2.java 10 Apr 2003 19:14:03 - 1.9
@@ -288,14 +288,15 @@
if (attributes != null) {
IntrospectionHelper ih =
-IntrospectionHelper.getHelper(p, target.getClass());
+IntrospectionHelper.getHelper(target.getClass());
+p.addBuildListener( ih );
for (int i = 0; i attributes.getLength(); i++) {
String name= attributes.getQName(i);
String value= attributes.getValue(i);
// reflect these into the target
-value = ph.replaceProperties(null, value, null);
+value = ph.replaceProperties(null, value, p.getProperties());
try {
ih.setAttribute(p, target,
name.toLowerCase(Locale.US), value);
Re: VOTE: new committer: Jesse Stockall
Steve Loughran wrote: I nominate Jesse Stockall as a committer as he likes spending time fixing up and refactoring some of the neglected bits of the optional tasks, and if we commit his new patch to the xdocs stuff, we need somebody to go through all the attributes of all the tasks and add the new metadata :) Also he's been a long standing contributor to bits of the project, does all the due diligence on bugzilla and ant-user support, those being the things that matter as much as new code. The quality of the code is Here's my vote: +1 -steve +1 Costin
Re: [Patch] trying solve w2k command line length limitations
Stefan Bodewig wrote: On Mon, 7 Apr 2003, Ignacio J. Ortega [EMAIL PROTECTED] wrote: Which also implies that we'll need to go through Ant's codebase and replace all Class.forName() calls (we better do that anyway 8-). I didnt understand this, why? Class.forName will use the system classloader and not the nice little URLClassLoader your Launcher provides. Many places inside Ant use Class.forName, thereby assuming that everything from ANT_HOME/lib will be available on the system classloader. My understanding is that Class.forName uses the current loader - i.e. the defining loader for the class - which for most tasks is the main AntClassLoader. So far using the ClassLoader task ( which just adds jars to the main loader ) seems to work fine and never run into any problem with Class.forName not finding something. I would also add the JBoss class loading scheme - which is also adding jars, with few twists to support reloading - is also working fine with Class.forName. ( yes, I know I need to write the docs for the loader task - this is the first thing I'll do after I finish with the current tasks ). Costin
Re: Using files in classpath in task file=
Stefan Bodewig wrote: org.apache.tools.vfs.File extends java.io.File But this version cannot be the argument for the (existing) setters. For this to work, IntrospectionHelper will need to take special care (i.e. if setXYZ(java.io.File) is found, actually pass it an instance of org.apache.tools.vfs.File). This is possible, but ... It is a bit hacky, you're right. A cleaner solution would be to add setXYX( java.net.URL ) for tasks that can deal with URLs, and make this works ( i.e. IntrospectionHelper can deal with it ). Not sure if IH can deal with overloaded methods - and how it can distinguish if a String should be converted to File or URL. * Is this generally desirable? mkdir dir=http://www.apache.org// I think this would be better handled by some webDAV antlib. I agree, blindly turning file to URL is not the best solution. protocol foo properly. I find it hard to imagine that we'll be able to convert all tasks that could reasonably be expected to deal with URIs in one go. However we can do it incrementally. Adding an setXYZUrl(URL) attribute should work - without the overloaded method problems. Well - it can be just setXYZUrl( String ). All we need is to add the attributes to the tasks where it is needed. Should we add it to copy ? I don't know :-) But XSLT is a good candidate. Costin
RE: Artima SuiteRunner Task
Dominique Devienne wrote: Hu, not totally. If the AntLib also uses types, you need another typedef, which should also probably needs a loaderref. Since you now use twice the classpath, if needs to be outside and refid'd. In ant1.6 the difference between tasks and types is very small. It would be trivial to load both of them at once. In any case, I don't quite agree with Stefan: the simpler solution is: path id=... / taskdef resource=.. classpathref=.. / I would love to completely remove the different treatment of types - i.e. a task is just like a type with an execute() method, and nothing else, and taskdef loades both kinds. That would be simpler than the current syntax that also require you to do a: typedef resource=... classpathref=... / Costin And what about the junit task? I'd like to not have setup my classpath outside of Ant and build.xml, and avoid having to dump everything in AntLib. I believe it can and should be easier and more flexible. --DD -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: Artima SuiteRunner Task On Wed, 26 Mar 2003, Dominique Devienne [EMAIL PROTECTED] wrote: That said (one more ;-), if Ant ever comes up with an easier way to integrate third party tasks Easier than taskdef resource=...classpath ...//taskdef? Almost impossible. Stefan
Re: Artima SuiteRunner Task
peter reilly wrote: I would include filters, mappers, conditions and selectors to the list. I would exclude them :-) Taks, types, mappers, filters, whatever are just ant components - and they shouldn't need a special syntax from user perspective. We shouldn't treat them ( or types, tasks ) as special - just plain components that happen to perform different functions in the build file. A relatively simple mod to the core ant makes this possible (bugzilla 17199) basically get ConditionBase.java, AbstractFileSet, FilterChain implement DynamicConfigurator. and get UnknownElement (bugzilla 18312) call setProject earlier on created children. Mappers are a little different, I implemented a new attribute to handle this. That's a possible solution, I'll take a look ( in few weeks unfortunately..., hopefully this will be resolved by than by others :-).
Re: [VOTE] JDK 1.1 support
Steve Loughran wrote: +1 At the same time, I dont see a need to run into refactoring everything we have today to move up to 1.2 support, 'just because we can'. It'll make it that much harder to back port patches to the 1.5.x codebase +1 on your comment ( and a preemptive -1 on changing any public method that uses Hashtables to use Maps - just because we can :-). Using Maps in new code or tasks should be fine. Refactoring some of the introspection code - like support for context class loader or jdk1.2 methods - is worth it ( IMO ), as it'll make the code easier to understand. Costin
RE: [VOTE] JDK 1.1 support
Dominique Devienne wrote: Given the above, there are no reasons to limit the 1.6 code base from *any* change that's JDK 1.2 (Java 2) compatible. That includes moving everything to the Java 2 Collections. As long as you don't break the public API. There are quite a few places where Hashtables are used. Hashtable is still part of JDK1.2 AFAIK ( and implements Map), so we are already using Java2 Collections :-) Costin
Re: java 1.1 on linux
Conor MacNeill wrote: On Wed, 19 Mar 2003 05:17 am, Costin Manolache wrote: Ok - last week we had a proposal, discussions on ant-user and ant-dev, and apparently an almost general consensus. What's next ? Should we wait a bit more before making it official by a [VOTE], or just forget the whole thing ? I will propose a vote tonight. I think we are clear that a move to a 1.2 based codebase is desirable. Moving to 1.3 or 1.4 is not yet needed as the features we would make use of are in 1.2 What is less clear to me is whether 1.5 branch should be the last 1.1 codebase or whether it should be 1.6. My preference would be to make it 1.5 since somethings we need to do (i.e. lcp.bat replacement) are best done with a URLClassLoader. 1.6 is still a ways off and if we designate it the last 1.1 release nothing will change for quite a while. It seems a pretty strong majority would preffer 1.5 as the last 1.1. I haven't seen any good argument on why 1.6 should support 1.1 - if people don't need the 1.2 features and are coding for 1.1, then they can very well use ant1.5 as well :-) Yes, URLClassLoader is the 1.2 feature that matters the most. Costin
1.6 milestones ?
Hi, Do we have any plan or idea on when we'll start distributing 1.6 milestone builds ? Tomcat5 is getting stable, and the next milestone will probably include an embeded profile that will be controlled by ant and jmx tasks. It would really help to have a matching ant1.6M1 instead of requiring a head build. I can't volunteer as release manager - and I don't want to push anyone or anything, just want to get an idea about what to expect, so I either remove deps on 1.6 or move ahead. Right now I'm only using classloader, but I'll probably use import ( and I would use 1.6 for the improvements in startup time ) Costin
RE: pointer to half-hearted official MS.NET ant-ish tool
Dominique Devienne wrote:
Not directly related, but I recently read that Maven similarly moved away
from relative path to use absolute paths. They apparently prefix
${basedir} explicitly everywhere. I'm not following the dev forum, but
thought the parallel was worth mentioning. --DD
Well - with the current import semantic, at least one use case will be
forced to use the same style.
My experience so far is that using not one, but multiple path
prefixes is very good - ${libdir}, ${classes}, ${docs}, etc.
The relative paths are very convenient and nice for quick builds
and to locate files in the source tree - but I for target files
I thing it's far better to use prefixes.
Costin
Re: ClassLoader and Properties handling behaviour
Conor MacNeill wrote: Also, I'm a little concerned about violating the classloading hierarchy - it leads to Linkage errors in my experience. I have the same concern with the ClassLoader task. The ClassLoader task is no longer using the classloading hierarchy - the initial version did, and it resulted in the expected Linkage errors ( and related workarounds ). This was needed in [embed] to work around ant1.5 limitations - but when I merged I removed all the hacks, they are not needed in 1.6. By default it'll just add more jars to the main ant loader - and rely on the lazy creation of tasks. The classloader task can be extended to deal with hierarchies and direct/reverse delegation - but the most common use will be to extend the main ant loader. Costin
