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]
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
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
Nicola Ken Barozzi wrote: Yes, most build files have a target named build - but I don't know why would you think about inheritance and OO instead of just qualified names. I don't know _any_ programming language where import is used for inheritance. Well, I pointed out xslt, what about that? ;-) I know. Well, the behavior for properties in ant is inspired from XSLT as well. But I don't think the import in XSLT is intended as an OO construct. Many people don't think XSLT is a very good as a programming language ( even if you can do a lot of logic in XSLT ). As has been pointed out in these threads, Ant is a different beast, and should be treated differenty. +1 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. Then call it include, it's already proposed. Well, C uses #include, java uses import. I don't know if a lot of people will care if it's called one way or another. And if people need an OO feature for ant - that's fine, they can add special tasks ( exted, override, etc ). Hey, that's what we are talking about! IOW, what should Ant give me to get the features I want? include ok, already decided override ok, already decided import ? If include is already decided, then skip import. Add extends or something like that. We are talking about OO concepts and inheritance - in import context. Well, we are not. We are referencing those concepts, but it's not the same thing. Still - replacing/overriding targets in import is very confusing, even on ant-dev. My point is that we should eliminate ambiguities - but not by adding more flexibility and complexity into the import task. If we have so much trouble understanding how import would be used for inheritance, what about all the users who may be java programmers ( where import has a very intuitive meaning, and so does extends ). If it's just a naming issue, let's call it XYZ, I honestly don't care. Just to be clear: current import is *not* projectref. It is not meant to encapsulate another buildfile, and the basedir resolving and the non-namespacing of properties is very clear about this. What is projectref ? Well, we seem to be talking about which target will be visible - with private/public and all this. Very far from java import - where all you can talk about is qualified names if you have 2 classes with the same name. Because Java does not have multiple inheritance, and even more does not have automatic multiple inheritance. I agree that this is a different concept. If java doesn't have mutiple inheritance, why would ant need multiple inheritance. Why would ant need inheritance at all is a different question ;-) The real problem is that importing multiple files may result in the same target name beeing defined multiple times. There is a very simple solution to that - qnames. Ok, so you haven't read all the thread ;-) Maybe it's better if you take a bit of time to reread the thread, as we are repeating stuff here. I'm working on that :-) If I repeat some opinions - that's good. If you import 2 files, each having a compile target, then you should use qualified names. Like in java import. Ok, this is clear, you are saying we should not have an automatic winner in case of multiple colliding import names. Yes. Having a winner is what creates confusion, ambiguity and the need to rewrite or define import as an OO construct. 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 ? Because I called it this way, that's all ;-) What you want is: target compile target pre target post override name=compile targets=pre,compile,post. This can be done inside a single file, no need to use imports at all. Just use a rename-target target, or some pre/post or extend. In fact, as I have explained, Conor proposed override-target, and I like it. But this is only about a a single import, the real issue discussed here is the multiple one. I like it as well, but I don't agree that it is about a single import, it can be very well used inside a single file, with no import at all. If we agree on qnames ( and implicitely no winner or conflicts in import), then override-target and all that becomes even more powerfull - you'll have access to _all_ targets, including the loosers. 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. You mean that a user must do: override-target name=xxx instead of target name=xxx (implicit override)? I'm fine with it, no problem here, again it has been proposed and accepted, but not the issue here. No, that's not what I'm saying :-) I'm not concerned with override-target - only
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
Nicola Ken Barozzi wrote: 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 :-) Because we can import two targets with the same name from different files. Making them work together is conceptually similar. You could try to import 2 classes with the same name in java. It's a syntax error - and if it happen, you must use qualified names. Yes, most build files have a target named build - but I don't know why would you think about inheritance and OO instead of just qualified names. I don't know _any_ programming language where import is used for inheritance. What's the syntax for the prefixed targets/properties ? prefix+targetname example: prefix=a name=b result=ab Hmm. Some delimiter would be good to have. a.b, a-b, a::b, etc. It would make things easier to read and understand. It would also be nice to default to the project name ( and require it to be unique, or use the explicit prefix only if 2 build files have the same name ). - 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 ) ? In a sense yes, but not quite. Import does not fully encapsulate the calling buildfile. @see XSLT include and import for a more similar concept. If so, wouldn't be more intuitive to just use the real concept - i.e. extends and inheritance ? Dunno. 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. KISS. Personally I don't need that (yet) I guess. 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. And if people need an OO feature for ant - that's fine, they can add special tasks ( exted, override, etc ). 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 ? This is what Conor seems to propose IIUC, and what others are not keen on, and instead talk more about the xslt-type import. Well, Conor has one more vote then :-) XSLT is not the easiest XML format ( I don't know many people to consider writting an XSTL is easier than writting an ant build file :-) And the fundamental problem ( IMO ) is using the wrong concept. We are talking about OO concepts and inheritance - in import context. If we have so much trouble understanding how import would be used for inheritance, what about all the users who may be java programmers ( where import has a very intuitive meaning, and so does extends ). Just remember that we are not talking about renaming properties, or resolving basedirs, so it's not full encapsulation, but just dependency-shielding. Well, we seem to be talking about which target will be visible - with private/public and all this. Very far from java import - where all you can talk about is qualified names if you have 2 classes with the same name. I have not yet made up my mind, but it seems that ATM there is a reason favor some kind of namespacing because I see more harm than good in side-effects that come out of not doing it. How this can still solve my usecase is yet to be seen. Maybe import shouldn't solve all use cases - just have a different task that solves overriding/replacing some targets. 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 :-) Well, IMHO I personally don't see a real, strong, compelling reason to have targets have crosstalk between themselves, but I do have an equally strong need to import dependencies. With qualified names, you can
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)
peter reilly wrote: Using property files is nice but with new attributes to typedef (adaptor for example) it would be better to use an xml file/resource. I think we already agreed on XML - there is no reason to continue adding arguments. This should be independent of using antlibs/jars or XML ns. Hence I think that the root element name should not be antlib as this implies more baggage. (Also my work in progress implementation uses an ant task for the xml parsing and the root element name is the task name ;-)). That's what I would do too ( and why I suggested using ant xml processing for the antlib descriptor ) :-) What baggage are you talking about ? Antlib is what we are trying to do, it would be confusing to use another name for the root element. 1) the code to handle XML namespaces in ProjectHelper2 is not yet complete. - namespaces of attributes is not handled yet - the code uses getQName() on the attributes and does not pass the URI of the attributes to the attribute list given to Easy to fix it to localname, but I don't want to get into ns + attributes, let's leave it for ant1.7 :-) ( or at least wait for the component creation to be done ). The NS standard http://www.w3.org/TR/REC-xml-names/ allows one to do somthing like this: project xmlns:html='http://www.w3.org/TR/REC-html40' target name=t echo html:class=reallyimportantmessage/echo /target /project of course it is up to the ant software to understand the xml file, but unsupported attribute 'class' is not a usefull error message in this case. Yes - but let's first implement namespaces on the elements. We can add code to ignore ( for now ) attributes that are in a different namespace than the element - that would allow various annotations or 3rd party tools. After we see how people use namespaces - we can add more features for the attributes. Attribute + NS affects the introspection. - the uris for project/target elements/attributes are not checked. Project and target are owned by ant, you can't redefine them in antlibs. This is true, but using namespaces one could do: project xmlns:html='http://www.w3.org/TR/REC-html40' html:target name=t echohello world/echo /html:target /project which is clearly wrong - but with the current code gives the misleading error: Could not create task or type of type: target There are plenty of wrong things one can do :-) We can fix the message to say html:target or use the URI, it's not a show stopper. - the ns standard allows different types of software processing for the different namespaces, if this is to be supported ProjectHelper2 would need to look at the uri before handing the element to the ElementHandler object (see my previous e-mail on the subject) Not sure I agree ( or understand ) this. The idea is to allow a xml ns to be used for purposes other that defining Unknown Elements. My example was an antdoc xml ns. Still don't get it. PH2 creates an object tree - and various element in the tree can access the tree and do whatever they want. PH2 itself shouldn't be involved in this. 3) In what ns will the introspected attributes and nested elements of the new elements reside? Some of the previous e-mails assume that they belong in the antlib's namespace - but what about datatypes that extend ant's datatypes - e.g mypath. (This is assuming that the attributes/nested elements are found by introspection - for jmx:... this may not be the case - or a different Class than IntrospectionHelper may be used). Those created by IntrospectionUtil - it doesn't matter, it's set by the It does matter from a build script point of view. addon:copypath path refid=x/ remoteurl url=http://; retry=no/ /addon:copypath is different from: addon:copypath addon:path refid=x/ addon:remoteurl url=http://; retry=no/ /addon:copypath The first case is simple - the current rules cover it. For the second - I don't know how could we handle it with the simple patterns ( createPath / addPath ). What's your proposal ? To apply the simple patterns to the local name ? introspection rules. For the new polymorphic tasks - probably the same rules of component creation as in top-level tasks. ( still not sure if we agreed on how many lookup tables we'll use ) 4) the proposed polymorphic element type substitution element type=newtype/ will need to be made ns-aware. either newtype for-element=element/ or the ns prefix - ns uri mapping at the parse time when processing type=newtype will need to be maintained. Probably using the prefix in newtype would be the most intuitive ( element type=antcontrib:if / ), but that will require some tricky change in PH2 to implement. Actually I think change is easy enough. :-) Sorry, I don't understand
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
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
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]
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)
Jose Alberto Fernandez wrote: You'll have a task TaskA, with a method addRoleB. And in XML: taskA ... implementationB1 /taskA TaskA doesn't know anything about the implementation - it will only use an interface ( or base class ) RoleB as parameter. I assume you will need some way to associate the tag implementationB1 with a particular class - and this can be very well be done currently with taskdef or typedef ( or with the new role declaration if you want ). The declaration of the class for implementationB1 as a member of the role is what you do equivalent to taskdef or typedef. Why is this required ? typedef should be enough for most common cases - the role declaration is already included in the .class ( i.e. interfaces implemented by the class ) In any case, all you really need is the tag name and the class name - the roles will be available as interfaces or superclasses. Nothing special for this association. No. If you do it this way it would mean that you cannot expose diferent names for the same class depending on the role. It will also mean that That's not true. You can declare a class with as many names you want. You can have multiple typedef and taskdef, each with a different name, but same class. thing that just happen to implement a role (just because of some inheritance) will be made available even though it makes little sense doing so. Ex. if. if is a task. It makes little sense to allow it as a condition, but because it is implemented by subclassing ConditionBase which would implement the role for conditions, it would mean you will declare it in the condition role. (This seems wrong in principle). Not sure I understand the if example. My feeling is that if should be useable in a condition role. In general - if you extend a class or implement an interface you assume a specific contract. Implementing an interface ( directly or by inheritance) and not supporting that particular role is wrong from an OO programming point of view. Secondly, since classes do not need to implement the interface but may be adapted, you cannot assume much there either. I think I mentioned - this is a special case and it clearly requires a special declaration ( which associates the adapter with the class ). Something like: taskdef name=tomcatEngine class=org.apache.catalina.core.StandardEngine adapter=org.apache.commons.modeler.ant.JMXTaskAdapter / The second part is making IntrospectionHelper recognize a child that doesn't fit the current patterns ( i.e. no addImplementationB1 ), and instead of reporting an error look up the child by the name and create the type, then check the interfaces implemented by the class and see if any method in the parent matches. Is there anything else ? You can only check for those interfaces where the class was registered to use that element name (you cannot blindly look at all possible interfaces). Why do you think it is blindly ? You have a parent that has a: setFoo( Interface1 ) and a child that implements Interface1. We could have both the redundant role and the interface - if you want explicit control ( for example prevent a class for working in a role, even if it implements that interface ). I don't see the use case, but if you really need it. My argument is more for the common or simple case - which I want to be as simple as possible. For your particular use case - using the interfaces would require the least ammount of work and seems very natural. You declare that a task implements an interface - that means ( usually ) it can be used in that role, just like any other class that implements that interface. If you implement Runnable - it is supposed that you can be used as a parameter to Thread. I feel it's a programming error to implement an interface but not support its contract, and it's wrong to require an additional declaration (I really implement the interface). 2) What do they do that is no possible in ANT: They allow IntrospectionHelper to connect an XML subelement eventhough introspection cannot find a create or add/Configured method for it. It is a well typed methanism, the parent object will only be passed objects that it knows how to deal with. And the parent object does not need to have any knowledge of what currently available members are on the role. Yes, parent needs one addXXX method with a typed parameter, and the child needs to be matched against it. What I don't understand is why should we just use the existing typedef and just add this new pattern to IntrospectionHelper. Because the proposal declares on a Role by role basis. There is no assumption the same name will be used for all roles, nor that you want to always register all possible roles. ??? My point is that implements can be used to solve the proble you describe. You can also solve it as in the proposal ( by using the
RE: Roles (was: antlib)
Jose Alberto Fernandez wrote: Assume class C implements role intrefaces P, Q, and R then typedef name=C1 classname=C/ typedef name=C2 classname=C/ will cause two definitions for P and Q each. There is no way to assign different names separately. On the other approach: role name=p classname=P/ role name=q classname=Q/ p name=C1 classname=C/ q name=C2 classname=C/ here you can get different names for different roles if you so wish. If C implements both P and Q, then it can be used as either P or Q. Whetever name you give it. What's the use case for having p useable only in the P role ( when the class supports both roles ), but not in Q role ? Let's not add restrictions and rules just because we can. What is the meaning of: condition property=x and if istrue value=yes/ thenechoyes/echo/then elseechono/echo/else /if istrue value=yes/ /and /condition x should be set, but shall yes be echoed? Although if implements the contract of condition, the meaning of if is to execute its nested tasks also, but for that condition will have to call the execute() by looking at if as a task and not as a condition. So the whole construct falls appart. What do you mean falls appart ? If if implements the contract of condition, it means it should be used as a condition. If it has side-effects - that's part of the implementation, and you should expect them when you use it. If I add a println() in istrue constructor - that will be displayed. If you don't want if to be useable as a condition - don't make it implement condition. Secondly, since classes do not need to implement the interface but may be adapted, you cannot assume much there either. I think I mentioned - this is a special case and it clearly requires a special declaration ( which associates the adapter with the class ). Something like: taskdef name=tomcatEngine class=org.apache.catalina.core.StandardEngine adapter=org.apache.commons.modeler.ant.JMXTaskAdapter / So, how you manage the current data-types which can be used as tasks? Backward compatibility says it needs to be treated internally, but your notation suggests we would have to declare them passing a TaskAdapter otherwise we keep the special cases around in core. Yes, TaskAdapter and taskdef will need to remain special cases for backward compat. And probably tasks will need to be special cases for backward compat. IMO a typedef with a class that implements Task should make that class a task, and be equivalent with a taskdef. With the way the proposal does it, we get the cruft out of core and the declarations will continue to be as before because the adaptor association occurs at the role-name level. I think the proposal adds far more cruft and complexity to the core. Backward compat will require special cases anyway. And associating the adapter with the role is completely wrong use of the pattern. The case of the if for starts. I would like to get an error if I tried to use an if as a condition because if was not designed to be used that way. And we have to deal with the code we already have. Then don't implement the condition interface. That's how OO programming works - if you implement an interface, java allows that class to be passed as parameter to a method. My argument is more for the common or simple case - which I want to be as simple as possible. For your particular use case - using the interfaces would require the least ammount of work and seems very natural. You declare that a task implements an interface - that means ( usually ) it can be used in that role, just like any other class that implements that interface. If you implement Runnable - it is supposed that you can be used as a parameter to Thread. I feel it's a programming error to implement an interface but not support its contract, and it's wrong to require an additional declaration (I really implement the interface). Remember part of the problem is that we need to deal with the code that is already out there which is not neat at all on these respects. However we shouldn't add complexity and make things harder just because some old code is bad. If we think that if shouldn't implement condition - and preventing it to be used as a condition is very important - then we should fix if. BTW, another solution is to enhance the pattern and have a setParent() method in the child. Then if impl. can check the parent and if it's not a task container then throw an exception. If you have an addFoo() and a foo child - I assume the old pattern will be used, not the roles ( backward compat, etc ). The roles would apply if you have a foo child and no addFoo() - you first create foo using the typedef/taskdef/componentDef, then look at the interfaces and find the addInterface() method. You cannot do it this way. Because foo may mean different classes depending on the roles of interest.
Re: Roles (was: antlib)
Jose Alberto Fernandez wrote: What does it all mean? It means we can now write a task, well typed, which can be accept different XML subelements depending on the declarations of other objects present on the build. The vendor specific elements of ejbjar, jspc and others are typical examples of where this capability can be very useful. Other parts of core could benefit of course. Let me see if I understand corectly what you want. You'll have a task TaskA, with a method addRoleB. And in XML: taskA ... implementationB1 /taskA TaskA doesn't know anything about the implementation - it will only use an interface ( or base class ) RoleB as parameter. I assume you will need some way to associate the tag implementationB1 with a particular class - and this can be very well be done currently with taskdef or typedef ( or with the new role declaration if you want ). In any case, all you really need is the tag name and the class name - the roles will be available as interfaces or superclasses. Nothing special for this association. The second part is making IntrospectionHelper recognize a child that doesn't fit the current patterns ( i.e. no addImplementationB1 ), and instead of reporting an error look up the child by the name and create the type, then check the interfaces implemented by the class and see if any method in the parent matches. Is there anything else ? 2) What do they do that is no possible in ANT: They allow IntrospectionHelper to connect an XML subelement eventhough introspection cannot find a create or add/Configured method for it. It is a well typed methanism, the parent object will only be passed objects that it knows how to deal with. And the parent object does not need to have any knowledge of what currently available members are on the role. Yes, parent needs one addXXX method with a typed parameter, and the child needs to be matched against it. What I don't understand is why should we just use the existing typedef and just add this new pattern to IntrospectionHelper. Also notice that Roles do not supercede DynamicConfigurator. On one hand roles let external implementations to be considered as possible subelements of a parent object, on the other hand, DynamicConfigurator allows a node to decide given its current state what is the meaning of a particular element. This cannot be done by roles in the general case, and that is good. Usage of Roles: == The principle is very simple: a) A role is defined by an interface. This interface is the parameter for a new special family of addConfigured(interface) methods. +1 on role defined by an interface ( or base class - I don't see any reason to restrict it to only interfaces ). 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. b) When IntrospectionHelper fails to find a create/add method for the element, it will look at all the roles used in the addConfigured methods and on each of those roles will try to find an object declared with that element-tag name. If one and only one match is found then the instantiation is successful and the new object will be configured; otherwise it is an error and parsing stops. I disagree here. If the role is associated with an interface, then the declaration is part of each task/type class. If you implement/extend that interface/class - then you have this role. Any extra declaration is redundant - unless you want to declare a wrapper ( see below ). c) The configured object may or may not implement the Role interface, if it does not, an Adaptor object may be instantiated as a proxy for the object. Which adaptor is used depends on how the implementation was declared. +1 here - I think the taskdef/typedef declarations ( which I would like merged in a single component declaration ) should take an extra adapter= attribute, to allow this wrapping. d) The resulting object is passed as an argument to the addConfigured() method. +1 ( with the comments above ). Declaration of roles: A role definition associates a name with an (Interface,Adaptor) pair. The only reason for associating a name with the role is to ease notation when declaring members of a role. Why ? All the user needs to do is associate a name with an implementation class. You need the impl. class anyway - and so the name, but the roles will be available as soon as you have the impl. class. You only need an additional attribute if you want to wrap. Notice that the same interface or the same Adaptor may appear in multiple declarations. This only means that depending on the name used the adaptor of choice will be different. There can only be one pair associated with each name. I don't see any reason for that. A class can implement multiple interfaces, so it can have multiple roles. No need to add arbitrary restrictions.
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
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
