Re: Updates to the Maven Artifact Ant tasks
Brett Porter wrote:
...
Just wanted to let you know about the changes I dropped in for the
dependencies and related tasks. Hopefully it is inline with the
feedback you'd been providing.
- added the ability to exclude specific transitive dependencies from
being pulled in from a specific dependency
Definitely needed.
- ability to use a POM to specify dependencies and repositories, in
addition to the ant types
Good. I will use that, as transitive dependencies need that I upload a
POM along with the artifact. I would personally suggest that the ant
types are deprecated.
- full support for external configuration (proxies, authentication
info, repository mirrors, local repository location). The search order
is ~/.ant/settings.xml, then ~/.m2/settings.xml
Good :-)
- ability to export properties or references from the pom:
artifact:setProperty property=parent.artifact.id
expression=project.parent.artifactId pomRefId=maven.project /
artifact:setProperty ref=developers
expression=project.developers pomRefId=maven.project / (not sure
whether this is a useful thing or not - I just thought references
made sense for object types)
I would use PropertyHelper instead:
http://cvs.apache.org/viewcvs.cgi/ant/src/main/org/apache/tools/ant/PropertyHelper.java?view=markup
Here is an example:
http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/XMLDOM.java?view=markup
http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/test.xml?rev=1.9view=markup
In this way, instead of
artifact:setProperty property=parent.artifact.id
expression=project.parent.artifactId
pomRefId=maven.project /
One could do something like:
property name=parent.artifact.id
value=${maven.project:project.parent.artifactId}
This is only in the SVN version at the moment - if you'd like a
development build published just let me know.
Please do, I will use it right away.
Are there other features you see being needed, or is the focus now on
the error handling, validation and testing? Here I only mean Ant
specific things, as other features added to Maven like the dependency
path reporting, version ranges and conflict resolution will work from
the tasks as is, I think.
The only thing I've got left on my list is to incoporate the Maven
profiles support, but we need to play with that more on our end first.
Looks good, bring it on! :-)
--
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: Updates to the Maven Artifact Ant tasks
Brett Porter wrote: ... This looks good, but looking at the examples you gave, I don't see any use of the PropertyHelper? I will have to spend some more time with it later on. Shucks I forgot a link: http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/JXPath.java?rev=1.9.2.1view=markup Let me see if I can make something work myself, I'm starting to feel ashamed of asking so much and not doing anything ;-) Please do, I will use it right away. http://www.ibiblio.org/maven2/org/apache/maven/maven-artifact-ant/2.0-SNAPSHOT/maven-artifact-ant-2.0-20050608.072503-1-dep.jar Installed. -- 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: libraries and m2 artifact :
Brett Porter wrote: On 5/16/05, Steve Loughran [EMAIL PROTECTED] wrote: Example: fetching commons-logging 1.04 Hi Steve, I'm going to work through the issues you filed here. Brett, I appreciate your help, but it's unfair to only rely on your kindness and on you being on this list :-) I have a couple more things to ask. Where should the discussion on the Maven Ant tasks take place IYO? -- 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: [Bug 28444] - Import: Target Handling Bug
Steve Loughran wrote: Phil Weighill-Smith wrote: I missed the beginning of this thread but just want to say that I personally think that import is the best feature in Ant today (apart from Ant's being in the first place, that is)! I find it hard to work with in a big project. problems -risk of adding a new target in an imported build file conflicting with one in the importer (i.e. lack of private scope) -when you override a target, you dont get access to its dependents. Workaround: many pseudo-targets that only model dependencies. Could you please explain more? TIA -once you have sub-projects importing ../../common.xml, they are no longer self contained, which makes it harder to work with outside the existing build tree. I dont see any good solution for the latter. The first and the last problems are in fact worksforme, as the import task is *intended* to pollute the project files that use it to be able to work as needed. In most cases, one would want to use typedef, macrodef or ant instead of importing buildfiles with targets, which should be used only to reuse and extend a base buildfile. -- 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: [Bug 28444] - Import: Target Handling Bug
Jose Alberto Fernandez wrote: Going to the old discussions in how to approach this issues, the thing that bother me most, is that in order to get access to an imported target I need to know the name given to the project on the file that did the import. This in my opinion contradicts the hidding rules of OO programming. I should not need to know about the internals of an imported object. It also means that I have to coordinate all the files I may directly or indirectly import so that there is no project name clashes. Java imports packages that have to be unique based on a naming convention; AFAIK if package names are not unique, you have clashes. Unfortunately now it's too late to reccomend a naming convention. I would advocate to allow the importer the specify the aliasing name it wants to use for the imported things, so one has something like: ... import file=bar.xml as=imp2/ Very nice, I like it. -- 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: [Bug 28444] - Import: Target Handling Bug
Stefan Bodewig wrote: On Thu, 12 May 2005, Dominique Devienne [EMAIL PROTECTED] wrote: ... And targets from different imported build files that conflict (multiple inheritance) should raise an error unless explicitly imported as given by the importer (not the name of the imported project as is the case now). Can't we have this as an addition anyway? Why? -- 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: [patch] FTP.java - adding support for new features in commons-net 1.4.0 and performance improvement
Stefan Bodewig wrote: On Wed, 11 May 2005, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: I do not think we can continue maintaining tasks for every project in the world just because they do not want to depend on ANT. Likewise, you cannot ask for every project to keep an Ant task just because Ant does not want to depend on them ;-) Calm down. We are talking about an existing Ant task that gets used a lot. And so far nobody has asked the commons-net people whether they'd want to maintain it. If you ask me, Ant is the owner of the ftp task and commons-net only a support library. The javacc, antlr or weblogic tasks (for example) are completely different beasts IMHO. Yes. Ant tasks - like any piece of code really - should simply reside where people care about them, fix bugs and enhance them. IMHO this usually happens in Ant if the task is generic enough to be used by most committers, and ftp seems to be the case. -- 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: Little bit of repository surgery
Steve Loughran wrote: ... What do people think about my plan? Any possibility of not duplicating code between Maven/MavenWagon and Ant? -- 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: AW: manual with css
Kev Jackson wrote: ... Forrest, sorry I thought that was for websites (sort of like velocity), but I haven't studied it properly. ... When I've finished (and it's not as manual as it would first appear, although I could do with a transform html tables into docbook tabels script), the manual will be entirely in xml which can then be converted with a style task into html, pdf (via fop) or whatever. That's what Forrest does. Forrest now can generate a site using html as a source, even dirty html (it uses jtidy), so *if* the idea is to go with Forrest, I'd just not do the task of converting all the docs. Besides, pure html is much easier to edit, as any decent html editor may do. -- 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: Patch proposal for 1.6.3: parse a Ant project from a resource
Yves Martin wrote: Jose Alberto Fernandez [EMAIL PROTECTED] writes: ... Of course, if such a place needs to exists for you to store the other files in your project, then the question is why don't you put the buildfile there as well? Good question. Here is the context: - I'm writing a build system with a 'pure' Ant (that may be open-sourced as soon as internal politic debates are over) - My build system plugin structure is simple: a jar with compiled classes and one or many Ant build file as resources. Of course such build file must fulfill constraints to work properly. Have you considered the use of an antlib for it? -- 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: libraries
Matt Benson wrote: ... I think we've had requests for automatic import invocations as well, while we're talking about automatic stuff... I don't understand, could you please explain a bit more in detail? TIA -- 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: libraries
Steve Loughran wrote:
Nicola Ken Barozzi wrote:
Steve Loughran wrote:
...
License is useful, pom may be useful in future...
Do you have a specific idea on this? :-
Not yet, no. But it might be useful to start collecting them.
IMHO it's about defaults.
A simple project always has the same properties in the build file, and
Maven has collected them in an xml file and an object model.
Ant usually uses properties, so we could think that it could make sense
if Ant had an analogous definition of common properties.
Ant tasks could have each a typedef that uses these default values for
auto configuration.
So for a simple project one could just make a property file with these
properties, and call the typedeffed tasks.
Instead of doing:
build.properties
src= whatever
build= whatever
build.xml
project
property file=build.properties /
javac srcdir=${src}
destdir=${build}
fork=yes
/
/project
One would have:
project.properties
ant.project.src.dir= whatever
ant.project.build.dir = whatever
ant.task.javac.fork = yes
build.xml
project
project:javac/
/project
This is why I asked if IYO the pom is useful, as IMHO there could be a
pomproperty task that loads these properties from a pom... is this
similar to what you had in mind?
--
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: libraries
Matt Benson wrote: --- Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Matt Benson wrote: ... I think we've had requests for automatic import invocations as well, while we're talking about automatic stuff... I don't understand, could you please explain a bit more in detail? TIA The most obvious use for automatic imports would be to auto-[type|task]def things for use in the default namespace. This use is arguable as to need; I'm sure this would address other situations but just now I don't remember what those are. ;) ;-) The most important thing IMHO is that antlibs (which are the modern-day type-task-defs) can be automatically downloaded and used just by referencing them. This is a subsequent step after libraries. Having them in the default namespace is IMHO not ok, as it can create unnecessary collisions. Another thing I would like to see is the ability to add directories to Ant's classpath (without using CLASSPATH) so that antlibs could live as standalone XML files in the case where an antlib, for example, consists only of macrodefs and presetdefs and refers to no extra-Ant classes. Well, you just need support for non-jarred antlibs. It seems to me that automatic import opens more problems than it solves, especially when these can be solved better on their own... -- 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: libraries
Steve Loughran wrote: is anyone else using this yet? What is their experience? I am not using it but the Cocoon project, that uses Ant, would like to download artifacts, and I would like to use it for JDNC. I'm not sure how to propose the use of this now, maybe if it were packaged as an antlib and buildable separately... WDYT about Maven Wagon in this regard? I am starting to move to it. I am also thinking of some enhancements 1. For mavenrepository always download pom and license files if present. With pom:boolean and license:boolean flags to enable/disable this. IMHO this is good, and both should be enabled by default. License is useful, pom may be useful in future... Do you have a specific idea on this? :- 2. add a new magic property to let people override the ibiblio mirror for all their projects. Yup. 3. make the default library the same place maven stores their files. Definatley!!! 4. implement Russel's suggestion of fileset+filelist type generation. ; plus whatever changes something to make it easy to turn the libs into the libraries in a WAR/EAR file :-) 5. Better error handling if things fail. Like correct line selection of library tags, maybe better diagnosis. Though what you can do when nothing is there, I dont know. I also think it would be convenient with my life if as well as loading ~/.ant/lib, that we had a properties file with my own customisations, say ~/.ant/build.properties That way I could set up things like proxy, maven repository, etc, in one place and have everything track it. I thought maybe we did this already, but couldnt see it in the docs or the source. -- 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: [RT] Define common project properties and tasks
Jesse Glick wrote: Nicola Ken Barozzi wrote: While I agree that there is some commonality across many Java projects (in that Java has a packaging mechanism that utilizes directories etc. and that these projects commonly produce one or more JAR files) it seems to me that this approach would either be too restrictive on the type of project that could utilize it or that so much customization would be required as to negate the usefulness of it. Netbeans thinks otherwise, and in fact *does* include a basic build. All IDEs have their layout, and tons of projects have used it without customizations. So my $0.02: NetBeans 4.0 does have a basic prepackaged project type (incl. Ant script and *.properties) with a fixed structure suitable for many simple projects. It certainly does not try to please everyone, and in fact people file RFEs constantly asking for more features and configurable options, which cannot all be satisfied. For this reason, the IDE also supports using an arbitrary Ant script for a project (so long as some basic information is given for refactoring etc. to work). Without that feature, I think it would be useless for anyone working in a big organization with a complex setup, or even for a number of smaller projects. I agree. My take is that about helping basic projects, not to be a one stop solution to all build needs. In any case, Phil's objections and comments are very detailed and appropriate, and I feel I have to reply in the same well thought manner. I'll do some more thinking, some hacking, and I'll come back when I have something to show. Thanks :-) -- 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: [RT] Define common project properties and tasks
Phil Weighill-Smith wrote: I'm not trying to rain on anyone's parade, but have you considered... It seems to me that there are as many completely different ways of using Ant as there are projects in this world. If you were to supply a standard build script, ready for customization, what input file structure would it expect? What language would be compiled (if any)? What distribution structure should be created and what files should be used to populate it? What configuration control system should be accessed to obtain the input files (if any)? What common properties would exist? etc. Actually, I have not seen *that* many java project structures. I mean, there is a source dir, a build dir, a tests dir... While I agree that there is some commonality across many Java projects (in that Java has a packaging mechanism that utilizes directories etc. and that these projects commonly produce one or more JAR files) it seems to me that this approach would either be too restrictive on the type of project that could utilize it or that so much customization would be required as to negate the usefulness of it. Netbeans thinks otherwise, and in fact *does* include a basic build. All IDEs have their layout, and tons of projects have used it without customizations. Perhaps better to provide some more sophisticated example build scripts covering the use of Ant on client side and server (multi-JAR) Java projects (and other languages if any contributions could be taken for these). I'd especially like to see examples that: * split the build into several sections (perhaps using subant) in order to generate multiple, tree dependent JARs (i.e. one JAR depends on another but there are no cyclic dependencies) * utilize something like XSLT to generate Ant scripts from simple XML files that define the inter-dependencies within such a multi-part build * use a repository accessor (along the lines of the get libraries stuff that has recently been discussed a lot on this list) to obtain dependency JARs from other projects Krysalis Centipede did this years ago, but the project failed. -- 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]
[RT] Define common project properties and tasks
If Ant defines a name for common project properties, then each task could have a parallel typedef that configures it with these values. In this way, a basic user would only need to write a property file and call the extended tasks without attributes, and have them work correctly OOTB. Same thing for tasks: if Ant provides a basic buildfile with the common targets, then users would only need to import it and customize the parts it needs to customize. WDOT? -- 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: repository
Steve Loughran wrote: ... I must have missed the info on your task; the only one that I knew about was the Krysalis work, and of course Maven itself. I wrote this up fairly quickly and stuck it in to provide a focal point for repository access; this is also why I checked it in before it was working fully. Now is the time to fix what I have started; we have until Axis1.7 ships :) So if you want to merge what I've done with your code, let's go for it. Same for anyone else who wants to contribute. (Ex) Incubator Depot? :-) (note: where-if it makes sense) -- 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: XML Logger conceptual usage
Botond Orban wrote: ... My question would be: Is there any change request which requests that the XMLLogger not to use DOM API, rather some stream? Look here, maybe you can use this if it's still compatible: http://cvs.apache.org/viewcvs.cgi/jakarta-alexandria/proposal/vindico/src/java/org/apache/alexandria/ant/Attic/XMLListener.java?hideattic=0view=markup http://cvs.apache.org/viewcvs.cgi/jakarta-alexandria/proposal/vindico/src/java/org/apache/alexandria/util/Attic/XMLHelper.java?hideattic=0view=markup -- 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: Contribution: dependencies task
Russell Gold wrote: Attached is code and unit tests for a task which will download and manage dependencies from a maven-style remote repository. If you are interested, Incubator Depot http://incubator.apache.org/depot/ has a similar tasl and goals, and we could work together. -- 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: Contribution: dependencies task
Russell Gold wrote: On Thu, 26 Aug 2004 17:24:29 +0200, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Russell Gold wrote: Attached is code and unit tests for a task which will download and manage dependencies from a maven-style remote repository. If you are interested, Incubator Depot http://incubator.apache.org/depot/ has a similar tasl and goals, and we could work together. I must have missed something. The page you cited shows projects to get the *latest* version of dependencies, but not specified versions. Not at all, it's meant to also do what your task does. The Depot Project deals with integrated tools for automating downloading (with security checks), publishing (new artifacts) and managing the contents of the apache repository. It also focuses on additional tools for manipulating metadata of the artifacts. Can you tell me more about Incubator Depot? It's OT on this list, so if you are interested we could talk over at [EMAIL PROTECTED] . -- 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: SQLExec.class feedback attribute proposal
Jose Alberto Fernandez wrote: Had forgoten about this guy. Is it in the docs? Sorry, I don't understand... it's a patch. I have changed it based upon feedback, and am waiting if it's basically ok so that I can add docs to it and finish it off completely. :-) [PATCH] Xml output for the SQL task http://issues.apache.org/bugzilla/show_bug.cgi?id=28681 Maybe we should guide people to use this functionality. -- 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: SQLExec.class feedback attribute proposal
Jose Alberto Fernandez wrote: Would be nice if you finish the submission so we can decide if it should be part of core. And being able to point people to this task. Ok, will add it to my TODO list. It maybe too late for 1.6.2 but none the less... Np, I hope it can be of good use in any case (it has been for me :-) -- 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: SQLExec.class feedback attribute proposal
Jose Alberto Fernandez wrote:
...
To tell you the truth, I think the whole business of printing
results of queries using SQLTask was a mistake, and should have
been defined on a separate task that can do real XML output of
results that one can manipulate and format in watever fashion.
The current arrangement is a product of the early days of ANT.
The last version of the xml extractor patch uses an external task for
extracting. Is this something that could be of interest?
[PATCH] Xml output for the SQL task
http://issues.apache.org/bugzilla/show_bug.cgi?id=28681
Usage example:
taskdef name=extractorxml
classname=org.apache.tools.ant.taskdefs.SQLExtractorXML/
extractorxml id=myextractorxml/
sql driver=...
url=...
userid=...
password=...
print=yes
output=${work.dir}/outputfile.xml
extractorRef=myextractorxml
${data.sql}
/sql
--
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: Alias names for imported targets
Jose Alberto Fernandez wrote: ... Is there anything missing in macrodef that does not allow you using it? Why, as you say, are you using the wrong strategy to solve your problem? Because I've realized this just some days ago, mostly on this thread :-) ... To tell you the truth, I haven't found in my builds the killer app for import/, but I have found numerous places to use macrodef/. That's probably because you were looking for 'extends', and import, as we have seen here, is not about it as you seem to need. Import is more like AOP, where you insert a target in the dependency tree. I think we need to start developing some patterns (AntWiki?) on how to properly use the tools we have and detect what is missing and what is pottentially bad coding, or tends to produce unmaintainable builds. I think we just now start to have enough experience to start looking at this questions. Yes, finally I think so too. Because of this I have also started a thread on the antworks mailing list addressing these points. Thanks all for the discussion! :-) -- 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: Alias names for imported targets
Jose Alberto Fernandez wrote: Looks like spaguetti buildfiles to me. No ofence, but if the build have this kinds of fragile dependencies, will anyone else understan what is going on 6 month from now? That is what is wrong with spaguetti code. All this restriction in OO inheritance are there to limit developers capability of writing spaguetti. We still do, but... Import overriding is not about OO inheritance, it's about target dependency injection, which is not quite the same thing. Look, if you import in Java packages that have the same class and then want to use a specific one, you must use fully qualified names. Why can't I in Ant? What does this have to do with inheritance? Ant import is *different* from other mechanisms, so analogies can help but are not the same thing. -- 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: Alias names for imported targets
Dominique Devienne wrote: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote: ... All this restriction in OO inheritance are there to limit developers capability of writing spaguetti. We still do, but... Import overriding is not about OO inheritance, it's about target dependency injection, which is not quite the same thing. Look, if you import in Java packages that have the same class and then want to use a specific one, you must use fully qualified names. Why can't I in Ant? What does this have to do with inheritance? Ant import is *different* from other mechanisms, so analogies can help but are not the same thing. Hmmm... I've recently read quite a bit about dependency injection and IoC on the Spring, HiveMind, and MartinFowler sites, and I don't think Ant's import/target override mechanism has anything to do with it. I think you must be meaning something else that what this term has recently been used to describe... :-)) Yes, I mean something different, and it's funny to see this misunderstanding. What I was trying to say is that importing targets one gets new target dependencies, not only new targets. Namespaced Antlibs do not do this: what I get are extra tasks, which do not do things automatically. When importing instead I get targets that can automatically get wired to others, thus getting called in the existing dependency resolution. The closest cousin to Ant I can think of is XSL. Again, another analogy! :-) XSL has a proper include/import model, and also the Java equivalent to super., where an overriding matching template can explicitly invoke the overridden template. But that's it! You can never otherwise distinguish what comes from the main stylesheet from what comes from included or imported stylesheets, directly or not. It's still different... Having this access just break encapsulation and would lead to spaguetti buildfiles, as Jose Alberto puts it. I see that you two are particularly firm in this, and to be honest I'm just trying to play the other side for the sake of discussion. On the pther hand, I am not convinced by your reasoning, as it's subjective, not objective (mine is too). Let me try to take a step back and ask you a question: what is import for? Originally it was to do all sort of things for extending builds, but then some very clever coder came up with macrodef and typedef, and most of the reasons of import fell. If I want a particular target to be called, I should not want a target, but a macrodef. When import was first put in there, some really wanted it to work like a sort of macrodef, and most, including myself, are using it for this purpose. In *this* case, having the feature discussed here makes sense. In *this* case, using the inheritance analogy does *not* make sense. IMHO this is the reason why we are not understanding wach other, as we think of different use cases. Could it be that we should simply hint that in this case one should use a macrodef instead of a target? I start to think that this 'feature' should not be allowed because of this. -- 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: Alias names for imported targets
Dominique Devienne wrote: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] I've looked into the code (gosh, I still remember part of it :-) The following path is OTOMH, without even compiling, it should be a start. Implementing this is not the issue... I know, I haven't replied to /your/ mail, but Stefan's original one. In any case, the reason is simple: sometimes it happens that I want to rely on *that* *particular* task in *that* imported buildfile, no matter what happens in the future. Imagine that I depend from an init task in an imported buildfile... I would depend on it in many targets. Now, imagine, and it's not that far fetched, that I have another init target that is imported or defined, and that I have to recheck all the places where I have declared my dependency... It all boils down to what you want to call. Personally I prefer to *declare* what I want, not go check later that an extra target breaks my initial intentions (that are surely forgotten by that time). Is it clear now? -- 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: Alias names for imported targets
Nicola Ken Barozzi wrote:... task-target -- 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: namespaced targets via import
Stefan Bodewig wrote: On Thu, 27 May 2004, Erik Hatcher [EMAIL PROTECTED] wrote: It would be nice if all imported build file targets were namespaced regardless of whether the targets were overridden or not. +1 - as an alternative to using the unadorned target name. Yes, it would be nice to have this too. Also any idea about how difficult it would be to have all properties defined in imported builds also be namespaced, to avoid collisions? -- 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: [Ant Wiki] Updated: AntTasks
Dominique Devienne wrote: ... Is there no way to moderate Wikis? Or at least the changes that include URLs? --DD Hmmm... I don't find anything like it that works with MoinMoin :-/ ATM we are finding that blocking bad IPs is giving decent results. In any case, this is where we are heading at: http://wiki.cocoondev.org/Wiki.jsp?page=Doco Excerpt: Features at a glance 1. super-easy editing (should satisfy wiki lovers) 2. minimal, efficient and secure workflow (should satisfy board@ legal concerns) 3. should allow the creation of static content (should satisfy infrastructure@ load concerns and mirror@ concerns) 4. should aim to reduce the production of custom code to a minimum (all code should go back to the projects that it depends on, if makes sense to do so) 5. should come up with structured XML content well organized in a versioned repository (should aim to make content long-lasting and easily repurposed) 6. should aim at complete internationalization of the content Forrest is almost there for the final generation, Lenya is proceeding well and Slide has just released a new version. -- 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: [Ant Wiki] Updated: AntTasks
Dominique Devienne wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Editor: StefanBodewig [EMAIL PROTECTED] this is getting silly -[http://www.marcihellishland.com marci hellish vacation rentals] -[http://www.marcihellishland.com marci hellish home] -[http://www.marcihellishland.com marci hellish house] So people are high jacking the Wiki to boost their Google search results? I guess Wikis work on the assumption only benevolent people edit it... --DD PS: I changed the URLs, to not boost these peoples anymore (if it's them). Unfortunately on the Cocoon wiki we found out that they were still happy to even only write them and have them removed, as we get commit notifications that get archived and keep their link public forever. -- 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: ANT 1.7 features suggestion
Dominique Devienne wrote:
From: Alexey N. Solofnenko [mailto:[EMAIL PROTECTED]
Actually if is too wordy. A mall target if=XXX is translated into
Complex conditions are big. A small expression language like XXX
YYY would be much nicer.
I so agree with you! That expression language could (should IMHO!) be XPath
(JXpath or Jaxen are candidates, or the Xalan one?) where Ant properties
would be available as XPath properties, and some of Ant's condition made
into XPath functions.
The PropertyHelper aready does this in the embed proposal, since almost
2 *years*. I had written the XMLDOM task for it, and that are also Jexl
and Velocity versions.
http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/
http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/
Examples from:
http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/test.xml?rev=1.9only_with_tag=MAINview=markup
echo message=jexl /references/myJars:
${jexl:ant.references.myJars} /
echo message=jxPath /targets[1]: ${jxpath:/targets[1]} /
echo message=jxPath /references: ${jxpath:/references} /
echo message=jxPath /[EMAIL PROTECTED]'myJars']:
${jxpath:/[EMAIL PROTECTED]'myJars']} /
echo message=jxPath /references/myJars:
${jxpath:/references/myJars} /
echo message=XMLDOM:
${jxpath:/references/test.xml/root/project/@name} /
--
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: ANT 1.7 features suggestion
After the import task, what about this, that downloads 'plugins' and
imports them?
http://antworks.sourceforge.net/
project name=sample default=compile
!-- Pickup the ability to import Antlets --
typedef resource=org/krysalis/antworks/importer/antlib.xml
classpath=${user.home}/.antworks/lib/antworks-importer.jar
/
importer name=my-plugin-0.2
href=http://url-to/plugin/; /
target name=all depends=compile,dist /
/project
--
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: Ant 1.7
Antoine Lévy-Lambert wrote: ... The xdocs stuff require time to get the method for processing the xml to html right, and even more to migrate the existing content to new formats. Once it will be finished, it should improve a little bit the homogeneity of the doc, make it more easy to maintain (hopefully) by avoiding duplication between javadoc comments and manual, and I hope also even nicer to read for the users. I am personally very interested by this project (because I think documentation is a very important pillar of all software projects). As a Forrest developer, I am also interested. We have just migrated code from Alexandria to Forrest, in a dir called forrestdoc, that is meant to produce code documentation for a project. Here is a sample of what it generates ATM: http://cvs.apache.org/~nicolaken/whiteboard/forrestdoc/ I am working on support for outputting it to M$ Help and JavaHelp format, and I'm almost finished. Now, for the ant xdoc proposal... I personally think that the Ant manual is the best manual I've seen so far, especially from a reference POV. When I need to remember some params, the Ant manual makes it very easy for me. Cocoon has very similar needs: we have many components that are used *not* in a Java program but in an xml descriptor (sitemap), and we too have investigated the possibility of using javadoc tags to generate it automatically. Needless to say, we have a pattern emerging... I'd better start looking in the Ant xdocs proposal :-) -- 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: 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. -caching of downloads, global or per-user -go through proxies -allow antlib providers to move their files (handle redirects) -allow antlib providers to mirror, by having a mirror file that lists possible sources -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 Anything else? 2. What things implement this? What do Maven and Ruper do? Ruper does some of the above and has the goal to also do the remaining items. Just some extra insight on Ruper2 from the old site: Multiple Repos: http://www.krysalis.org/ruper/config/index.html Eclipse Plugin: http://www.krysalis.org/ruper/eclipse/index.html CLI: http://www.krysalis.org/ruper/tool/quickstart.html 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... You have just described Ruper that is now in the Apache Incubator Depot. In addition, I'll add that there is also a need to import more than antlibs, that is also buildfiles that can be imported with related resources. It has been proposed some time ago to bring to Ant things that Centipede provided. Most has already been integrated or is in the Incubator (Apache Depot), while what remains is in the Centipede2 proposal, AKA antlets. Antlets already work like this: importantlet name=init href=http://ant.apache.org/antlets; / The above automatically downloads it if necessary. http://nagoya.apache.org/wiki/apachewiki.cgi?AntProjectPages/Antlet Take the above simply as a possible proposal. If instead Ant would decide to just include the code in the codebase, it would be fine too. -- 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: [VOTE] Bug Tracking System
Jeff Turner wrote: Hi, Disclaimer: I work for Atlassian, the company responsible for Jira. I've had my Apache hat a good deal longer though. I have always said that Bugzilla was fine for me, no need to change. Then I tried JIRA, and find it generally nicer, but for the use I make of it, no real big change (heavy users have found it much metter though). Then Pier said that he will not upgrade Bugzilla as it sucks and he is damn fed up with it, so now I champion Jira. :-) (At work I use Scarab because it's free, and it's a pilot program. I'm sure it will be come a great piece of software, but IMHO ATM it's more complicated to use, so I still prefer to see Jira here for now) -- 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: comment task
Dominique Devienne wrote:
From: Peter Reilly [mailto:[EMAIL PROTECTED]
Whoa, for a second there I though you could call methods off a reference,
before the property name=my-foo.toString() refid=my-foo/ registered
in my brain ;-) That would be way cool actually!!!
Hey Peter, can't you code that? ;-) --DD
I think that this is coded already using the jexl property support
in proposal/embed.
I thought you might say that... Like Dion, I still haven't grasped the
new PropertyHelper stuff. Anybody knowledgeable who could write up
something about it on the Wiki? We haven't heard from Costin in ages
on this list. --DD
It's actually quite easy.
A PropertyHelper, is a something that is asked to resolve a property.
So if I register a Jexl PropertyHelper, each time a property is asked ot
be resolved by ant, it asks first this PropertyHelper.
Inside the Jexl PropertyHelper, it checks if the property starts with
'jexl:'. If yes, it resolves it using jexl, if not, it passes it on the
the next helper. If no helper resolves it, usual resolving is done.
For example, there is one that uses velocity.
From the code:
the task VelocityProperties [1], when called, does this:
public void execute() {
try {
// Prepare the engine
helper.engine=new VelocityEngine();
//initialize it
helper.engine.init();
//create a context
helper.context=new VelocityContext();
//add the ant *Project* to it
helper.context.put( ant, project );
// Register this class instance with Ant
PropertyHelper phelper=PropertyHelper.getPropertyHelper(
project );
helper.setNext( phelper.getNext() );
helper.setProject( project );
phelper.setNext( helper );
} catch( Exception ex ) {
ex.printStackTrace();
}
}
In practice it adds itself as a property helper, IOW a class that gets a
chance in evaluating a property.
Then, each time a property is asked to be resolved, this method is called:
public static final String PREFIX=vm:;
public Object getPropertyHook( String ns, String name,
boolean user ) {
if( ! name.startsWith(PREFIX) ) {
// pass on to next, as the property
//is not to be resolved here
return super.getPropertyHook(ns, name, user);
}
try {
//the actual content
name=name.substring( PREFIX.length() );
StringWriter sw=new StringWriter();
engine.evaluate( context, sw, antVM, name );
System.out.println(VM: getProperty + ns + +
name + = + sw.toString());
//return the resolved property
return sw.toString();
} catch( Exception ex ) {
ex.printStackTrace();
return null;
}
}
[1]
http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/VelocityProperties.java?view=markup
--
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: comment task
Dominique Devienne wrote:
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Hey Peter, can't you code that? ;-) --DD
It already exists, it is called velocity. ;-)
I always thought velocity was a templating tool,
so I don't see it's relation to calling arbitrary methods
on objects referred to from Ant references... --DD
It's just the velocity property stuff that's really used here.
Here is the example of all this stuff.
From:
http://cvs.apache.org/viewcvs.cgi/ant/proposal/embed/test.xml?view=markup
target name=dynamicProperties depends=init
taskdef classname=org.apache.tools.ant.taskdefs.optional.JXPath
name=jxpath /
taskdef classname=org.apache.tools.ant.taskdefs.optional.JXPathSet
name=jxpathSet /
taskdef
classname=org.apache.tools.ant.taskdefs.optional.VelocityProperties
name=velocityProperties /
taskdef
classname=org.apache.tools.ant.taskdefs.optional.JexlProperties
name=jexlProperties /
!-- Init JxPath. '/' is the project --
jxpath/
velocityProperties/
jexlProperties/
echo id=foo message=Starting dynamic props tests /
echo message=Value: ${vm:$ant.references.jxpathTask.foo} /
jxpathSet path=/[EMAIL PROTECTED]'jxpathTask']/foo value=Test/
echo message=Value: ${vm:$ant.references.jxpathTask.foo} /
echo message=${jexl:ant.references.jxpathTask.foo=bar} /
echo message=Value: ${vm:$ant.references.jxpathTask.foo} /
echo
message=jexl /references/myJars: ${jexl:ant.references.myJars} /
echo message=jxPath /targets[1]: ${jxpath:/targets[1]} /
echo message=jxPath /references: ${jxpath:/references} /
echo message=jxPath /[EMAIL PROTECTED]'myJars']:
${jxpath:/[EMAIL PROTECTED]'myJars']} /
echo message=jxPath /references/myJars:
${jxpath:/references/myJars} /
!-- This is XMLDOM.java - a datatype that holds an xml DOM --
typedef name=xmldom
classname=org.apache.tools.ant.taskdefs.XMLDOM/
!-- Init XMLDOM. The DOM of file test.xml will be referenced via
the id--
xmldom id=test.xml file=test.xml/
echo
message=XMLDOM: ${jxpath:/references/test.xml/root/project/@name} /
/target
--
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]
import usage notes
I had written some time ago a description of rules and pitfalls in using import. It's some time since I used it now, so I don't know if it still applies as-is. IMHO it could be a nice addition to the Ant manual. In any case, here it is. -o- Each import will insert the imported file in the importing file. If there are name clashes, the importing file targets take precedence, and those imported targets is available as importedfilename.targetname. If there are multiple copies from the same target, the last definition takes precedence. Note that the target that takes precedence will be used in all dependencies, regardless to which buildfile they came from. Warning: The import task is not made to reuse current builfiles as building blocks, as it does not provide a way of shielding the files between themselves from side-effects of name clashes. Be sure to check the buildfile you import so that it does not have unintended sideeffects or needs special resources. Note: Multiple Inheritance Issues If you import two files that have a same target, and that target is not in your base file, the target used by both will be the last one to be declared. In other words, the last target definition with the same name is the one that will be used by *all* files. Suggestion: To prevent this, use fully qualified target names, or remember to redefine the target in your base buildfile in the manner you see fit. Example: File a.xml project name=first target name=a depends=init echo value=inita /target target name=init echo value=initb /target /project File b.xml project name=second target name=b depends=init echo value=b /target target name=init echo value=inita /target /project file build.xml project name=main default=run import file=a.xml / import file=b.xml / target name=run depends=a,b/ /project Running build.xml will yield this sequence during import: import a.xml added target a added target first.a added target init added target first.init [targets: run, a, first.a, init(==first.init), first.init ] import b.xml added target b added target second.b -- redefine target init with second.init -- added target second.init [targets: run, a, first.a, first.init b, second.a, init(==second.init), second.init ] Since dependencies are not redefined, the init target that the global buildfile will use is second.init. To prevent this: Filw a.xml project name=first target name=a depends=init echo value=inita/target target name=my.organization.namespace.a.init echo value=inita/target /project File b.xml project name=second target name=b depends=init echo value=b/target target name=my.organization.namespace.b.init echo value=initb/target /project file build.xml project name=main default=run import file=a.xml / import file=b.xml / target name=run depends=a,b/ /project Running build.xml will yield this sequence: import a.xml added target a added target first.a added target my.organization.namespace.a.init added target first.my.organization.namespace.a.init [targets: run, a, first.a, my.organization.namespace.a.init, first.my.organization.namespace.a.init ] import b.xml added target b added target second.b added target my.organization.namespace.a.init added target first.my.organization.namespace.a.init [targets: run, a, first.a, my.organization.namespace.a.init, first.my.organization.namespace.a.init b, second.b, my.organization.namespace.b.init, second.my.organization.namespace.b.init ] -- 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: [ANTidote] possibly needs to be renamed!
Adam R. B. Jack wrote: You may be right, because antidote is a commonly used word, but I am with Stefan here and I feel playing save can't be bad :-). What are the chances that the new name isn't a clash with somebody else somewhere? How far/wide do you search? Do you change again in a while when somebody surfaces? When does it end? I think typically folks w/ name clashes, who don't truly clash in product/concept/marketing typically just learn to ignore it and coexist. The Internet is too big for no clashes. Maybe call it org.apache.ant.idote or something. ;-) Surely Apache has run into this before, no? Yup. For example Microsoft has Avalon, and Sony has Cocoon. But our projects are Apache Avalon and Apache Cocoon. So it's not *strictly* necessary to change the name, but why risk when you don't have a brand to protect anyhow. -- 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: [ANTidote] possibly needs to be renamed!
[EMAIL PROTECTED] wrote: Surely Apache has run into this before, no? Yup. For example Microsoft has Avalon, and Sony has Cocoon. But our projects are Apache Avalon and Apache Cocoon. So it's not *strictly* necessary to change the name, but why risk when you don't have a brand to protect anyhow. Is it possible for a company to register a name which is used by others in the same domain earlier? E.g. if Apache uses Ant for years; can Microsoft register that name for another neat tool now? IANAL, but AFAIK no. -- 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: [ANTidote] possibly needs to be renamed!
[EMAIL PROTECTED] wrote: IANAL, but AFAIK no. -- Nicola Ken Barozzi [EMAIL PROTECTED] I know AFAIK (as far as i know), but what is IANAL? I Am Not A Layer :-) -- 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: [ANTidote] possibly needs to be renamed!
Stefan Bodewig wrote: On Thu, 16 Oct 2003, Christoph Wilhelms [EMAIL PROTECTED] wrote: I just want to tell you, that the President of the company Druide http://www.druide.com Eric Brunelle infomed me, that his company own the (not shure if just French or international) trademarks for the name Antidote in relation to computer software products. The name is Apache Ant Antidote, so it's not exactly the same thing. But the fact that it's both about software, and that it's not the most widespread part of Ant, it might as well be renamed to play safe. If nobody is sticking to the name, let's play save and rename it. Exactly :-) -- 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: *USEFUL* Stylesheet to generate a task-dependency graph for ant.
alec wrote: Dear Ant users, Here's an XSLT script which will give you a graphical view of the task dependencies in your ant build file. There is a project on SF called vizant that also outputs a java applet with the dependencies (see the CVS version, it's more recent). http://sourceforge.net/projects/vizant/ It has been inactive for a bit now, but I'd be happy to restart to code. If you or anyone wants to help... :-) -- 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: Excel 2 Xml task ?
[EMAIL PROTECTED] wrote: Does anybody know of an ant task that is able to read excel sheets and convert it into xml (or some other format) ? I don´t know any. Maybe the POI project has something. The POI project does not (yet) have a task, although it does have code in Cocoon CVS to handle the conversion between xls and xml. For more info, you can contact the jakarta.apache.org/poi/ developer list. -- 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: Should import cause an error when used inside a target?
Stefan Bodewig wrote: On Thu, 18 Sep 2003, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: First, import/ makes absolute no sense to me inside a target. The whole point of import was allowing for target-overriding. I could understand having an include/ in there, because is textually expanding the file in place, which may make sense. There is no include, only import which does both. I've already voiced my preference for a pure include task. Stefan, IIRC there was consensus that we should add an extra include task to only substitute entity includes. This to make it possible for use cases like yours to work without worrying about the import overriding capabilities. I don't have the time now, but I really think that if you or someone else adds an include task to the list, nobody would object. Personally I favor it, as adding a task does not take away from import. -- 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: circular imports
Stefan Bodewig wrote: Currently a build.xml with project import file=build.xml/ /project will print a warning Skipped already imported file build.xml and end as a successful build after executing the import once. Correct. I feel this is wrong for two reasons: (1) The current build file (the one intially loaded) should be added to the list of already imported files implicitly so it doesn't get loaded twice at all. (2) circular imports look like a bug to me - the build should fail. This is the only possible issue. The decision on this point will automatically define number 1. I understand that unrelated imports should be handled gracefully, i.e. if A imports B and C and B and C both import D, this is OK. But a circular import is different from that to me. As it stands now, there is no such concept as circular imports. You have circularity when things gets nested, but in this case there is no nesting. What happens is that if at least one of the buildfiles asks to import a file, that file is added to the list, and other requests are ignored. So the current behaviour is correct given the actual -flat- import rules. -- 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: circular imports
Stefan Bodewig wrote: On Wed, 17 Sep 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: I feel this is wrong for two reasons: (1) The current build file (the one intially loaded) should be added to the list of already imported files implicitly so it doesn't get loaded twice at all. (2) circular imports look like a bug to me - the build should fail. This is the only possible issue. The decision on this point will automatically define number 1. I'm not sure. Even if you think the current flat import rules are correct, (1) should be addressed IMHO. Wait, you said that it prints out: Skipped already imported file build.xml This means that the current file is *not* imported twice... how do you gather that it executes the import once? So the current behaviour is correct given the actual -flat- import rules. I see and understand that - I just question that rule. If A imports B and B imports A, I do consider it a bug in the build file. It is not. It means that both need each other, not call each other, there is no recursion. If I import class A from B, and B from A, Java will correctly compile the code, it already takes care of it too. -- 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: circular imports
peter reilly wrote: On Wednesday 17 September 2003 14:00, Nicola Ken Barozzi wrote: Stefan Bodewig wrote: ... I'm not sure. Even if you think the current flat import rules are correct, (1) should be addressed IMHO. Wait, you said that it prints out: Skipped already imported file build.xml This means that the current file is *not* imported twice... how do you gather that it executes the import once? It executes the build.xml as a normal ant file and then build.xml as an imported ant file. The effect is that top-level tasks in the build.xml are executed twice. Ah, ok, so this means that the skip is done on the second iteration. Right, then the current buildfile should be added to the list of already imported files, Stefan is right. The output will still read the same in this case, but the import will only be done once. -- 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: Getting 1.6 out the door
peter reilly wrote, On 01/09/2003 20.10: On Monday 01 September 2003 16:43, Dominique Devienne wrote: ... It's not all about power, or one would use a real programming language like Perl or Python. macrodef, although powerful, complexifies the rules of Ant, namely the property expansion one, making it context dependent! Never underestimate the power and simplicity of context/scope free rules. Although Ant already has scopes with ant/antcall/subant, the property expansion rules works the same everywhere, and I'd like this to stay the same. macrodef follows (I think) the same rules of properties as antcall with inheritall=yes. +1 ... macrodef should make ant a little simpler by removing the need for a lot of antcalls. People sometimes use them at the moment to emulate macros/templates. Normally (I think), macrodef would be used in the same project that defined it, so the rules for property expansion would not be an issue. I agree. I also think that macrodef is quite important, as it does most of what I have been doing with importing targets, but without the need of using targets. Imports should be reusable bits of builds. But instead they carry the baggage of targets. With macrodef I can finally *create tasks using Ant*. To me, the current macrodef behaviour seems pretty easy to grok. -- 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]
Import in Antlibs (Re: [new tasks] presetdef and macrodef)
Gus Heck wrote, On 25/08/2003 18.02: Nicola Ken Barozzi wrote: Jose Alberto Fernandez wrote, On 22/08/2003 14.58: From: Gus Heck [mailto:[EMAIL PROTECTED] ... If macro definitions are available to sub builds, then your 3rd case might occur, but I don't think it would be good to allow macros to be called across build file boundaries. builds would be almost unintelligible without tracking down the macros from other files. This is all regular kosher ANT stuff, up to this day, taskdef/s get inherited, they do not need to be redeclared for the task to be available during the antcall/. ... We already have a solution for the case of taskdef I would just like the behavior on both cases to be the same, so to reduce the leaarning curve. What about making them part of antlibs too? How does a macro defined in the build become an antlib? The easiest way is to make it possible for antlibs to contain buildfiles that are imported. Antlibs would thus be jars that contain tasks, typedefs, and buildfiles. When loaded, the taskdefs are called, the typedefs too, and the buildfile is imported. This is what we do in Centipede, and it works ATM quite well, as we are able to thus to create antlibs easily even without any java code, only by including a buildfile. The alternative would be to allow only special buildfile snippets that contain macrodefs, that is to check that there are only macrodefs and import that file. What do others think? -- 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: ant task submission....compilewithwalls
Dean Hiller wrote, On 26/08/2003 13.59: ... Currently at work we prevent this same thing by having separate source trees and people are complaining up a storm. ... This helps with that problem of allowing one to keep one source tree and put up walls that prevent other packages to be used from certain packages that are supposed to be independent. I like it. :-) I have never liked keeping separate directories for things, even if I do it for the benefit it has in build separation. -- 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: [new tasks] presetdef and macrodef
[returned from holiday, happy to read the list again :-) ] Jose Alberto Fernandez wrote, On 22/08/2003 14.58: From: Gus Heck [mailto:[EMAIL PROTECTED] ... If macro definitions are available to sub builds, then your 3rd case might occur, but I don't think it would be good to allow macros to be called across build file boundaries. builds would be almost unintelligible without tracking down the macros from other files. This is all regular kosher ANT stuff, up to this day, taskdef/s get inherited, they do not need to be redeclared for the task to be available during the antcall/. ... We already have a solution for the case of taskdef I would just like the behavior on both cases to be the same, so to reduce the leaarning curve. What about making them part of antlibs too? -- 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: Running ant in loop mode
Felipe Leme wrote, On 16/08/2003 5.01: Hello all, ... The initial idea would be to add a command line parameter (-loop) to ant, so it can run in loop mode. ... With this patch, the new tasks are executed really fast ... I improved the patch a little bit: now the Main class has 2 new attributes, loopMode and loopHandler, which could be set by the IDEs. LoopHandler is a new interface, whose default implementation uses System.in.read(). ... So, what do you guys think of the patch? I think it would be really useful, and easy to implement (of course, if I didn't think so I wouldn't suggest it :-). If it is accepted, I could offer more help documenting and testing it (personally and with the participation of folks at my company and JUG). I'm not an Ant committer, but a heavy Ant user, and I can say that I really like it :-) It's months that I wanted this but really never got round doing it, and I'm happy that someone else has done it. I would add a couple of suggestions if you don't mind, as I would basically keep -loop as now but would be thrilled to se other features very similar to it: 1 - it would really be nifty if there was also an -interactive mode, where a special LoopHandler is able to read also a new target invocation 2 - also having a LoopHandler to accept the tasks to run via socket (it can be easily implemented when 1 is done) So when 1 is done, it would be: ant -loop targetname Buildfile: build.xml targetname: [...] ... BUILD SUCCESSFUL Total time: 2 seconds // first evocation, took 2 seconds Press Enter to continue q + Enter to quit targetnames + Enter to change invocation target3 target4 (Enter) Buildfile: build.xml target3 : [...] ... target4 : [...] ... BUILD SUCCESSFUL Total time: 3 seconds // first evocation, took 3 seconds Press Enter to continue q + Enter to quit targetnames + Enter to change invocation (Enter) Buildfile: build.xml target3 : [...] ... target4 : [...] ... BUILD SUCCESSFUL Total time: 1 seconds // first evocation, took 3 seconds Press Enter to continue q + Enter to quit targetnames + Enter to change invocation q(Enter) $_ PS: here is the enhancement's URL: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22428 -- 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: [OT] Build Time
[] listeners = this.listeners;
+for (int i = 0; i listeners.length; i++) {
+listeners[i].messageLogged(event);
}
+loggingMessage = false;
}
/**
@@ -2089,6 +2112,4 @@
public Task getThreadTask(Thread thread) {
return (Task) threadTasks.get(thread);
}
-
-
}
--
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]
PropertyHelper (was: Re: beating the dead Ant 1.6 horse)
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: [new tasks] presetdef and macrodef
The following tasks will be an excellent addition for the use Centipede
does of Ant, so it's a big thumbs up!
Presetdef can be used to redefine the most used Ant tasks adding the
defaults taken from the descriptor we use.
macrodef can make us finally create real macros that are not only
targets, as instead has been done till now, so we can really make
libraries of tasks defined through Ant buildfiles and not have them
necessarily as targets.
:-D
peter reilly wrote, On 14/08/2003 11.20:
Hi,
I have written a couple of tasks to enable definition of new tasks
in ant.
presetdef (formally known as extendtype)
this defines a new task or type based on a current ant task or type, with
attributes or elements preset.
example useage:
presetdef name=my.javac
javac debug=${debug} deprecation=${deprecation}/
/presetdef
my.javac may now be used as a task in the same way as javac
but the attribute debug and deprecation will be preset.
macrodef
this defines a new task in the same way as scriptdef except it
uses a sequential as a defintion of the task. The macrodef
task has nested elements - param and element to allow the
user to specify attributes and elements of the new task. These
get substituted into the sequential when the new task is
run.
example: (from a current project)
macrodef name=call-cc
param name=target/
param name=link/
param name=target.dir/
element name=cc-elements/
sequential
mkdir dir=${obj.dir}/${target}/
mkdir dir=${target.dir}/
cc link=${link} objdir=${obj.dir}/${target}
outfile=${target.dir}/${target}
compiler refid=compiler.options/
cc-elements/
/cc
/sequential
/macrodef
macrodef name=compile-exec
param name=program/
element name=cc-files/
sequential
call-cc target=${program} link=executable
target.dir=${build.bin.dir}
cc-elements
includepath location=${gen.dir}/
includepath location=test/
cc-files/
linker refid=linker-libs/
/cc-elements
/call-cc
/sequential
/macrodef
compile-exec program=unittests
cc-files
fileset dir=test/unittest includes = **/*.cpp/
fileset dir=${gen.dir} includes = *.cpp/
/cc-files
/compile-exec
Will I place these tasks in ant or ant-contrib ?
Peter
--
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: [new tasks] presetdef and macrodef
Dominique Devienne wrote, On 14/08/2003 20.16:
Jose Alberto answered that one indirectly. I know understand that the
macrodef I had does not declare a 'name' or 'classname' attribute, and
thus could not be used as I wrote it, whereas presetdef keeps access to
all attributes of the preset'd type. Sorry for being so slow ;-) --DD
While the tasks themselves are wonderful, it's possible that the current
naming can confuse users, and DD is quite a knowledgebale (how the heck
do you write it!?) one.
I'm not a naming wizard (usually quite the opposite), but how about:
presetdef name=my.javac
javac debug=${debug} deprecation=${deprecation}/
/presetdef
becomes
taskdef name=javac
classname=whatever
attribute name=debug value=${debug}/
attribute name=deprecation value=${deprecation}/
/taskdef
or
taskdef name=javac
classname=whatever
template
javac debug=${debug} deprecation=${deprecation}/
/template
/taskdef
or
taskdef name=javac
classname=whatever
defaults
javac debug=${debug} deprecation=${deprecation}/
/defaults
/taskdef
And
macrodef - scriptdef language=ant
scriptdef language=javascript
scriptdef language=ant
or
macrodef - taskdef language=ant
taskdef language=javascript
taskdef language=ant
BTW, any name is fine for me as long as it's put in Ant 1.6 ;-)
--
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
Paul King wrote, On 09/08/2003 15.45: ... For include the conceptual model is one of textual inclusion (or XML entity inclusion if you are that way inclined). The ant way states (at least for properties) that whoever sets things first wins. I would argue that would be the simplest model for everything else too (but there has been some talk of failing the build if nameclashes occur). The trick in understanding is to put all these files in one file and run ant. Ant now indeed works as you suggest, as multiple targets do not collide, but the first one wins. I would suggest that whoever is first wins could apply to path references, targets etc. Depending on my settings I will get a warning and arguably ant could be run in a strict mode which could fail if a property, path, target was adjusted later. The implication of this is that even within the one file you could (though never recommended) have two targets with the same name - the second would be ignored. Exactly what happens with the latest Ant CVS. But this, as Conor has shown, creates problems that are not easily understandable by users. The example was about all imported files having a target with the same name, and other targets depending on it. All imported files would then use the first decalred one in the first file, which may not be what was intended. I have seen some of the import, super, override discussions but can't see an easy conceptual model following ant's similar but not exactly equivalent notion of inheritance. So, what I want to achieve is the equivalent of Java's delegation trick/pattern used to mimic multiple inheritance. In Java I wouldn't use inheritance at all but would instead have two instance variables (the delegates) and I would pass any method calls on to the appropriate delegate. This is where things aren't clear to me. In the example I have used two antref tags. I am trying to avoid the nameclash issue altogether - conceptually I either have some new targets but only full qualified and perhaps not visible or I may need target references to some targets. Now I can declare my own targets and refer to the original targets in some fashion either by their fully-qualified names or using the target reference. I have used a pseudo task called targetref - kind of like super which has been discussed before but perhaps I could use (an extended) antcall with a refid? Any suggestions? Does this help anyone? I don't think I follow you. It seems that you are describing how import works now, with first-target wins, and access to all the targets with fully qualified names. Look in CVS manual for the import task... is that what you mean? -- 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
Trying to summarize. Costin Manolache wrote, On 08/08/2003 16.21: Nicola Ken Barozzi wrote: ... As has been pointed out in these threads, Ant is a different beast, and should be treated differenty. +1 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. ACK 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 ? I have to reread the mails to get to that point? No way ;-P I'll just explain brieflt OTOMH, Conor can be more precise. In essence it's about having ant buildfiles instanciated in parallel, and have make it possible for them to share dependencies. So a target in project A can depend on a target in project B, and the two builds are completely isolated in their own basedir-properties-targetnames. IIRC there is some docs in Conor's Ant2 proposal. 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. 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. That's the idea behind the current import stuff, so it fits perfectly. Second question: how do we deal with the fact that targets that are not even used have crosstalk between themselves? I don't think you can have crosstalk if you follow the rule that everything is qualified if it has the same name. Two points here: - Crosstalk can happen in form of properties - Of course you won't have crosstalk if you use qualified names, this is what Conor says Again, I agree with Conoer :-) That may mean he is right ? I haven't tought about qualified names for properties, but it makes sense too. Noted. Let's see: include No problem here, any collision is an error I don't quite see a need for include ( given my view on import :-), but if other people need it - fine with me. Well, some +1ed it, so since it's a subset of the import functionality, I'd say why not too. Basically it should be simply a 1-1 replacement with entity includes. override-target I am overriding the previous defined target, and can refer only to the immediately previous one as original.targetname. Overriding can be done multiple times, nesting the calls. import Like include, but gives me the possibility of referring to the imported tasks with a fully qualified name in any case. If there is only one version of a target, it's also available with the original name. Still conused about this [] part [The namespace name has to be specified as a prefix by the one that imports the file, else the project name is used. Projects that are imported must have a name.] If a project imports clashing target names, and thus namespacing is needed, I can still use override-target or target to define a target with the original name. +1 snip usecases I'm starting to like override-target :-) :-) BTW, we have renamed cents to antlibs, Centipede is just a task, and we are splitting functionality in various tasks, as you have suggested. It's looking good :-) Thanks for taking time to discuss this guys, I appreciate :-) Sorry for repeating what has been discussed, I was very concerned about mixing import with OO and complex name resolution rules ( like in XSLT import :-) You have maybe repeated some (small) parts of the discussion, but you have been very good at making your point, which in fact was exactly the last point of contention. :-) What remains is Jose Alberto's POV
Re: override
Jose Alberto Fernandez wrote, On 08/08/2003 20.02: ... 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/. Yes. And as I see, Costin agrees to this. I'm not sure I understand what you are aiming your comments at :-? 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. Unfortunately I don't have that book... please help me. I think that with my last mail proposal, the solution addresses all concerns expressed here, except yours. I still don't understand though what you want to do exactly, because it seems to me that you are talking about how to do it rather than what you need. Please write some usecases as I have done, so that we all can look at them and see if/how they can be written with the current proposal, and eventually update it. ... to me the important thing is the goal of writing effective reusable code. Same here. The project you cited, Centipede, effectively is able to do it with the current import (which I initially wrote BTW). My opinion is that the current proposal does all that Centipede needs and does now, and even more. Why do you think that this is not the case? Remember, real code examples are important. Conor convinced me with code. I convinced and discussed with Costin with code. Code, code code! - verba volant, scripta manent - :-) -- 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
to redefine the compile target. Reusing it in a differently-renamed target is not ok, as when I call test, it will not have a dependency to the new version of the target. So target compile target newcompile (call:prestuff, compile, poststuff) target test depends=compile If I call newcompile, it works but calling test will not call the new one, thus making it impossible for me to *decorate* the compile target, thus specializing the template. So I should have: target compile - original compile override-target compile (call:prestuff, original.compile, poststuff) target test depends=compile Till I import *one* compile target instance, all is well. As soon as I have more of them, I start having problems. The question is: after a multiple import, which compile target becomes the default one, ie the one without renaming? Second question: how do we deal with the fact that targets that are not even used have crosstalk between themselves? And most of all: how to solve the last two points while keeping it possible for me to retain the use-cases? As you see, for this usecase, include is not strong enough, as I cannot override, and complete namespacing prevents me from overriding the dependency chain. -- 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
Sorry if the mail becomes long, I have difficulty in deciding what to snip ;-) Costin Manolache wrote, On 07/08/2003 15.56: 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. Well, I pointed out xslt, what about that? ;-) As has been pointed out in these threads, Ant is a different beast, and should be treated differenty. 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. not : , as it mixes with namespaces not :: , too cluttery not - , used in many xml langiages in compound names . could be ok 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 ). OOTOMH could be a nice thing. - 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 ). It is, I agree. 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. 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 ? 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. Well, we are not. We are referencing those concepts, but it's not the same thing. 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. 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. Because Java does not have multiple inheritance, and even more does not have automatic multiple inheritance. I agree
Re: override
Jose Alberto Fernandez wrote, On 07/08/2003 16.15: Some comments on the issues inside: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] ... 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. 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) Yes, this is the incriminated use-case. 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: target precompile depends=b.precompile or override-target compile depends=b.precompile, super.compile the question is how convinient is to have to thread all this interconnections by hand on the importing buildfile. What about this: a @importable=only target compile depends=precompile !-- target precompile (do-nothing) -- b target precopile (very complex precompile lib) build: import (a,b) It should work. And manual intervention would kick in only in the case of multiple clashing precompile targets. (hey, I said the same thing as in the reply to Costin but with a lot less words! Amusing...) -- 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
Knut Wannheden wrote, On 07/08/2003 16.13: ... Maybe it would be better to think in the term of mixin as some languages (e.g. some Lisp flavours and Ruby) use. The following two exerpts are from the Modules chapter of the free book Programming Ruby: The Pragmatic Programmer's Guide (http://www.rubycentral.com/book/tut_modules.html): ... Maybe it would be possible to borrow some ideas and concepts from Ruby... Thanks Kunt for the pointer, seems very interesting! :-) -- 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
Costin Manolache wrote, On 06/08/2003 6.44: ... 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. 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. A brief recap of decisions taken IIUC: - add an attribute to project: @importable=true, false, only - add possibility of prefix in import declaration import file=xxx prefix=xxy/ - all paths are resolved resolved to the importing file basedir - keep projectname.ant.file property for relative path resolutions - add include/ task, like entity includes - add override-target/ task to override targets 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! -- 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, On 01/08/2003 11.40: ... OK, lets get on the nitty gritty of the matter. :-) What do you mean by unrelated imports? If they are unrelated why do you need to import them toghether? Why don't you use ant/ to call between the unrelated targets? In other words, the now famous example of bad crosstalk, I could argue is due to bad usage of the import/ feature. The build should not have imported files A and B, but just ant/ them. You whould have gotten the desired effect. Conor already explained this to me IIUC, and I think he has projectref in mind. Basically it's like having parrallel buildfiles that can have dependencies between them, a sort of super metabuilder. From last night's sleep, this is the latest news from my fried brain ;-) Probably we should have different levels of multi-build systems. 1 - include - exactly like entity includes USE CASE: Simple snippets that are in common between files, like init targets 2 - override - can be used alone or in the buildfile to override targets - no rewriting is done whatsoever USE CASE: With the above to customize imported targets 3 - import - like the above two; still need th see if they are a subset or equal to import USE CASE: Simple include+override? Used for build libraries like in xslt 4 - antref - makes it possible to *reference* an external buildfile in the dependencies, and access its targets, properties, references. USE CASE: building multiple projects, like for example doing an aggreagetd website of all the referenced projects (hmmm, can use ant for this, need a better use-case) This looks clearer now I think :-) We all have different visions of include-override functionality, and putting it all in a single target is confusing. Maybe the above division makes sense and can help. -- 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
Conor MacNeill wrote, On 01/08/2003 12.27: On Fri, 1 Aug 2003 07:40 pm, Jose Alberto Fernandez wrote: ... On the other hand, if you have to import them, then it is because they have to share something or one defines some target for the other, or something. I disagree. Importing them into a common build does not imply they have something in common other than they are both fragments I wish to use in my build process. If you want them to interact you should achieve that *explicitly* by operations in the importing build file not by some implicit coincidence of names. Ok, let me try and comment on this multiple inheritance issue. Multiple Inheritance -- We have showed how avoiding interactions between import lines is something that prevents unwanted interactions between targets. But some have expressed that these interactions are instead *wanted* at times, and thus should be possible to be done. AFAIK this is the only reason for wanting these interactions, please add if there are more. As you say above, these interactions should be explicit. Nick Chalko wrote: I used this feature in centipede. The release antlib has a target called tag-and-release, but it depends on a target called tag However tagis expected to be defined in a different antlib. Currently it is defined in cvsbuild, but it is open for someone to make a vssbuild antlib. So I do think cross talk is a feature but a feature that can be hard to grok. How can this thing be done while shielding interactions? With this feature, the only import declaration states that we want to use cvs or vss build to override. I write: project default=release import file=release.xml/ import file=cvsbuild.xml/ /project In here there are contracts that are very difficult to see, as the two antlibs have to be made basically by the same person, and know each other. How can I do this more declaratively? Dunno, some musings: project default=release import file=release.xml/ import file=cvsbuild.xml/ target name=release depends=setcvsbuild, release/ /project project default=release import file=cvsbuild.xml/ import file=release.xml property name=release.buildtarget value=cvsbuild.release/ /project project default=release import file=release.xml param name=use-import value=cvsbuild.xml/ /import /project -- 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
Dominique Devienne wrote, On 01/08/2003 17.14: -Original Message- From: Conor MacNeill [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 9:24 AM To: Ant Developers List Subject: Re: override On Fri, 1 Aug 2003 10:47 pm, Nicola Ken Barozzi wrote: How can this thing be done while shielding interactions? You make the renaming optional. So you mean it's an ||, I cannot have both :,-( ;-) import file=a.xml/ import file=b.xml/ All of a's and b's targets go unprefixed. If those builds use targets which are provided by the main build, or by the other, unprefixed, import then there is no problem. This situation thus allows the cross-interactions. IIUC you mean that it's exactly like using include, right? We need to decide a few issues. Is mutliple definitions of a target considered an error or does one definition win. If one wins, which one - the first or the last. I prefer to have this as an error. Me too. Should be an error, forcing the user of the imported files to explicitly resolve the conflicts, thanks to renaming. Might be a little more work, but tons more predictable, and will not surprise anyone. Seems it won't change the way it works now, as I would still be able to redefine the target, only that I have to override it with the override task. import file=a.xml prefix=a/ import file=b.xml prefix=b/ In this case each import's targets are prefixed and thus will not collide. Specific overriding in the build could make desired connections. override target=a.init antcall target=b.init/ /override Thoughts? I agree with Nicola Ken that using antcall is wasteful resource-wise, and that what it should really be is: override target=init depends target=a.init / depends target=b.init / /override Can't it be instead: override target=init depends=a.init, b.init/ It's more similar to how target works. I'm ok with either though. I'm also starting to think that targets from a and b that do not conflict should *not* be renamed, IIUC that's how it should work now, with the only difference that the single, non colliding, target has two names (init and a.init). and that renamed targets from a and b should not be call-able directly from the command line, but only from within the build file itself, to compose them as shown above. Why? I see no reason for it. I already wrote about this, but I'll say again that nobody should be aware of the renaming taking place but the build file that does the importing/renaming. Sorry, I don't understand this sentence in it's practical implications. Could you please expand a bit? -- 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
Dominique Devienne wrote, On 01/08/2003 17.38: -Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] Sent: Friday, August 01, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: override and that renamed targets from a and b should not be call-able directly from the command line, but only from within the build file itself, to compose them as shown above. Why? I see no reason for it. It's consistent with my next point! If nobody's aware of the renaming, then a fortiori, these renamed targets should not be call-able. I already wrote about this, but I'll say again that nobody should be aware of the renaming taking place but the build file that does the importing/renaming. Sorry, I don't understand this sentence in it's practical implications. Could you please expand a bit? For the same reasons you cannot call an overridden method from a base class when you are a client of the derived method. Only the derived class itself (in this case the build file doing the import) can is the method from its parent it overrides. I don't have a need to have it, as I never used it from commandline, but I don't see dangers in it. Either way id fine for me. I understand your point now, thanks. :-) override target=init depends target=a.init / depends target=b.init / /override Can't it be instead: override target=init depends=a.init, b.init/ It's more similar to how target works. I'm ok with either though. It could be, but it's less flexible. What is the importing build file needs to do something before and after a and b's init? Or in between? Much easier to do it before/after/between the depends tags, than being forced to create a specific target for before/between... (What I often refer to spaghetti Ant code) Agreed, and that's why I also posted a depends tag in bugzilla (that had some issues it seemed and remained there). What I tried to say is that it should be possible to /also/ have them in the depends attribute, as the normal target has them (for consistency). In essence we could have (full example): override target=init depends=pre.init dostuff/ depends target=post.init / /override I'd like to have it in normal targets too BTW :-) -- 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
Dominique Devienne wrote, On 01/08/2003 17.58: On second though, instead of renaming, why don't we use IDs, which are common and well understood: Well, they have a special meaning in XML and I would not use them for this feature. It also spoils consistency with other ant namings, as usually we use name= and not id= And finally, they cannot be put in the depends attribute. (see other mail). import file=a.xml id=a / import file=b.xml id=b / import file=a.xml prefix=a / import file=b.xml prefix=b / override-target target=init depends refid=a target=init / depends refid=a target=init / /override-target override-target name=init depends target=b.init / depends target=a.init / /override-target or better yet IMHO: override-target target=init super refid=a / super refid=b / /override-target The super notation feels very natural, and I don't see why one would need to called a conflicting target (from an imported build file) from anywhere but the same-name target that resolves the conflict... There is the need. If the two libraries have same names but different functionality, the redefining target does not resolve the conflict for both, but simply resolves it relative to the common name. For example, if I have import file=java.xml prefix=java/ import file=c.xml prefix=c/ override target name=compile depends target=java.compile / depends target=c.compile / /override-target override target name=test-java depends=pre.test depends target=java.compile / depends target=java.test / /override-target ... PS: I would still like to be able to use depends target=... in build file that do not do any imports, to avoid wrapping long attributes like the 'depends' one often is. +1 -- 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: gmane access to ant mailing lists
Antoine Levy-Lambert wrote, On 30/07/2003 20.51: Hi, I have noticed that it is not possible any more to access the ant mailing lists from the news.gmane.org server. They used to be accessible as gmane.comp.jakarta.ant.devel and gmane.comp.jakarta.ant.user. Since today the user list is not available any more via this confortable interface. The development list had also vanished silently a week ago or so. Is this a decision of gmane or of the ASF or specifically of the ant PMC ? Any specific reasons ? I liked the gmane access, because sometimes posting through gmane is faster for me than emailing the list, and the nice thing is that you see the threads well in it. I am sending this through gmane, and haven't had any problems. The only thing is that I cannot post to the user list via gmane, but it has always been like this... -- 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: ImportTask ant 1.6
Dominique Devienne wrote, On 30/07/2003 20.09: Why don't you put the import *after* the style task??? Now any task can be at the top level, or put them in two targets, the importing one depending on the xsl one. Or am I missing something? --DD There was a time during import refactoring when this was not possible anymore because imports were resolved before... but IMHO as you say should be the default behaviour, as it was at the beginning, because it is really helpful in hacking complex buildfiles in matter of minutes. -- 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: ant 1.5.4 : Import
Jose Alberto Fernandez wrote, On 31/07/2003 13.24: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] ... Wait a second, does this mean that there is crosstalk between the lines 1, 2, 3? Yes, there is crosstalk and at least in XSLT this is a good thing. It means that you can write a bunch of files with groups of templates on each, and then by just importing them into one buildfile all the pieces can interact with each other. In that way if I want to replace one group of templates in a diferent project I can just change the import line for that particular group and the behaviour changes. We use this technique extensively in our system at work and it makes life extremely easy and modular. So in may opinion this is a good thing. That's what I do too, just that I don't never had the need or ever thought of doing it with targets that are not redefined in the base one. If you say that you use it and benefit from it, I believe you, and makes me feel better :-) So what I thought was a bug is instead a feature; the important thing is that this feature is correctly documented. If X calls call-import/ then it will call the X in e, since it is the highest definition lower than the X in f. Notice that there is no need for renaming anything, just adding a precedence attribute to each target. And precedences are assigned in a depth-first-search manner. But this is a step back it seems. With naming it's much easier to call the selected target without checking import orders. I can say: call the f.X target, because I know that I want what f's X does, without having to check the hierarchy. Tell me about on succesful OO language in which you are alowed to call the super of 10 levels above without visisting the inmediate super definition. This idea of jumping around as one pleases is just as bad as programming with unstructured GOTOs. GOTOs allow you to do whatever you want, and that is why they have been doommed. I really do not think it is a good idea. I am not aware of all the implications, so I tend to believe you. In fact, my original version had an apply-import tag. But then it became impossible to use them in the @depends attribute, so I did the renaming of the target name to super.targetname. Then, I don't remember the details, super.targetname was not liked so we switched to the buildname.targetname. Should look in the archives. As per the example you mention, I think it can be rewritten using the XSLT model. But I am not sure about the details. XSLT forces imports to be at the top of the file, which simplifies precedence computation. We could enforce the same (what it really means, is no imports inside targets). Well, AFAIK if we put imports at the top, what you show is what happens, as each import is executes recursively. Yes, as long as you assigned the precedence for the imported targets before you assign preferences for any target in the importing file, it will just work. As I said, the only thing forbidden is having the import/ inside a target (and not at top level). Well, hope you consider this, as an alternative. I think it is much more easy to handle and if XSLTs do not need more that this, I do not see why ANT will need much more. From this mail it still seems to me that renaming is easier to use and les ambiguous. What remains is the possible issue of intra-buildfile crosstalk. This makes it even more important to have an importable=true attribute in the project file, as this has to be taken into account. It still seems that shielding buildfiles between import lines is the most intuitive way of working for the users... let's see. It can be summarized as: Each import will insert the imported file in the importing file. If there are name clashes, the importing file targets take precedence, and those imported targets is available as importedfilename.targetname. --Which makes me think BTW that properties should be renamed in the same fashion.-- Aha!, now you need to rename properties. Not that I need, it was just a musing, that stems from the assumption that buildname.targetname is to use... How about properties comming from propertyfiles? How do you know which ones should not be renamed because they are from files and which ones should because they come from the import? I can show you many examples in which you cannot determine one way or the other. ... which, give the above, could simply mean that buildname.targetname is not to prefer... hmmm... The above description is seems clear, concise and intuitive. The problem is: what if I want to use one of the common imported targets that I did no redefine? Let's say that I want to use the init target in the below example. Which one is called? Ha. So using the xslt-like method, it becomes: Each import will insert the imported file in the importing file. If there are name clashes, the importing file targets take precedence, and those imported targets is available as importedfilename.targetname
Re: override
Conor MacNeill wrote, On 31/07/2003 14.07: ... I think with a renaming import task this would let you override any part of the build easily. Very cool indeed :-) [I'd like to thank all the ones that are discussing on import. Very nice posts and constructive stuff, I love you guys :-)] It seems that we can then make these tasks: include :like entity includes override :like your example import:both of the above (do we want it at all?) (would i tdo other things?) Separating converns makes both more simple both to understand and reuse. Not though about the implications much, but I really like it. The only thing that comes to mind is that I cannot use super ion dependencies, which is a nifty feature :-( BTW, note that simple renaming of targets is not enough. Any use of a target name needs to be updated too (e.g. antcall). Can be done (at time of use) but may require tasks knowing their import prefix. The import task will need this to do cascade renaming. Aha! Wait a sec, is this about the multiple inheritance-no-crosstalk thing I outlined? Could you please expand on this, I'm interested. Anyway, just thought I'd throw it out there. Override might even be useful in an entity includes approach. Very interesting. -- 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
Conor MacNeill wrote, On 31/07/2003 15.44:
On Thu, 31 Jul 2003 10:23 pm, Nicola Ken Barozzi wrote:
The only thing that comes to mind is that I cannot use super ion
dependencies, which is a nifty feature :-(
Not sure why this would be needed. Just add super/ as the first contained
task. All of the other dependencies will have been run by then (i.e. the
dependent targets of the original target, represented by super/).
I mean, if I need to run super before *other target dependencies*, I
should do:
target name=test
super/
antcall target=anotherone
/target
While it's more resource efficient to have:
target name=test depends=super,anotherone/
Of course, unless we introduce this (which is nice too):
target name=test
super/
depends target=anotherone
/target
BTW, note that simple renaming of targets is not enough. Any use of a
target name needs to be updated too (e.g. antcall). Can be done (at
time of use) but may require tasks knowing their import prefix. The
import task will need this to do cascade renaming.
Aha! Wait a sec, is this about the multiple inheritance-no-crosstalk
thing I outlined?
Could you please expand on this, I'm interested.
Sure. Consider this change to my previous example. It represents rather poor
practice but can happen
target name=test
property name=tricky value=critical/
antcall target=${tricky}/
echo message=b.test/
/target
So the target that antcall has to really call is not known until the antcall
is actually executed. Antcall has to evaluate the property, get the value
critical, look at its own import prefix b and decide to therefore call
b.critical. Some smarts may be possible there if, for example, b.critical
does not exist.
Now I get it.
But this is about scoping calls, not only renaming tasks. IIUC the
xslt-like scenario described in the other thread does not need this
renaming.
Again IIUC, this renaming would effectively make the
multiple-inheritance without import-line crosstalk that I talked about,
but that in the other thread seemed to bring problems.
Aaarg @-|
I'm still confused...
Similarly when imports are processed. Consider if a.xml imports b.xml with
prefix b and b.xml imports c.xml with prefix c then c's targets actually
need to be renamed to b.c.test in the final project To do tjhis the imprt
task needs to concatenate its own import prefix with given prefix. Of course
prefixes would be optional and then target name collisions would cause an
error, I think.
So this is what happens when we try to rename also the dependencies...
--
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
peter reilly wrote, On 31/07/2003 16.41: +1 for override[-target] +1 for include as import without target override sematics +1 for both here too. Maybe getting those working and combining them can make us see what/if extra functionality is needed for an import. Since in Centipede I do not use import directly, but instead extend it and add download functionality, I would be interested in switching it to extending include instead and seeing what happens, and then trying some examples with override-target. :-D -- 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: ant 1.5.4 : Import
Conor MacNeill wrote, On 30/07/2003 0.10: On Tue, 29 Jul 2003 05:52 pm, Nicola Ken Barozzi wrote: Personally, I don't see the real need for it, as the same can be done with correctly-written @importable files. In the specific, init values should be included rather than imported. Can you point me to some relevant use-cases? Ok, attached is a small test case which shows the failings of import when there are target name collisions. In this case the dependency of test to critical in b.xml is incorrectly replaced with a depenency on the critical target in a.xml. Woah, this is a really nice test! I strongly encourage all that are interested in import to unzip it and run it, it's very insightful. Target renaming doesn't help here. Having everything in a single project namespace remains a problem. I'd say the number of target name collisions between imported build files is going to be high because of the tendency to choose target names from a small pool of common names. Houston, I think we have a potential problem here. You are right. I have never encountered this because I always write small imported files with not many targets, and each library has unique-name targets. The issue stems from the fact that overriding works also *between* imported files. So what happens is that an imported file silently is able to override a target in another imported file without me knowing it, and I agree that it's nasty. Let's see what the behaviour should be here. 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! OTOMH this could be solved by rewriting all dependencies that are not in the import line. (1)---a multi-import (2)---b (3)---c---d So rewriting should block collisions between (1), (2), (3), but enable them inside those lines. What had been proposed is using fully qualified names in targets that I do not want to be redefined, which could be ok conceptually, but the issue is that the implications of sideways crosstalk between import lines are not transparent to the user, and thus should be avoided. What I need is to be able to import build dependencies along with the targets. Probably the above solution should fix this error and make it work, no? Other suggestions on how to do it while keeping the functionality that import now gives? -- 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: AntRun or modification to antcall
peter reilly wrote, On 30/07/2003 13.41: ... I think it should go into ant-contrib. I will put it there soon ... I have asked ant-contrib, but I was suggested to ask here is this behaviour could be inserted in antcall and if it was something that could go in Ant. Ping... pong... ;-) Thanks for taking this up, appreciated :-) -- 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: ant 1.5.4 : Import
Conor MacNeill wrote, On 29/07/2003 1.23:
On Tue, 29 Jul 2003 04:18 am, Jose Alberto Fernandez wrote:
I agree that ${basedir} should be the value of basedir for the main
buildfile being executed. But what I think is necessary is to have
access to the basedirs of the imported file in a systematic, deterministic
and conflict free way. I do not think we need some special importdir
what we need is ${basedir.importedprojectname} and so on. This properties
will point to the where the local basedir for that local file is suppose to
be.
I think this is all getting too complex for import. What you are describing
is project composition where each project maintains its own context, its own
basedir, etc.
AFAIK this is done with ant
This can be done separately from import. We have discussed
this in the past as projectref.
Hmmm, I'll look in the archives.
In fact I would like to rename import as include to reinforce the fact
that this is its primary function. In fact the problems we are seeing with
import all come because it tries to do two things beyond a simple #include
operation - target renaming and allowing imports to access resources
according to their import file location.
That was thought about, but then I looked in the XSLT spec, and import
seems to look more like it. And it's similar to Java imports.
The problem with import is that it flattens a hierarchy of project files
into a single project but tries to preserve some of the hierarchy based on
project names. Having multiple basedirs, ${basedir.X}, [EMAIL PROTECTED], partially
visible targets, etc is just a whole load of complexity for very little
benefit, IMHO.
Are you talking about the current version or the proposals? IMHO the
current version simple includes with a bit of target name rewriting.
If you want a hierarchy of projects, do that separately. If you maintain the
hierarchy in separate project instances, you eliminate all the name clashes,
etc.
Import is not made to make hierarchies of projects. It's made to include
buildfile snippets and utility finctions, not hierarchical buildfiles.
So based on discussions so far, my proposal would be:
1. import with optional name. The name is to be used in the renaming of
targets.
+1 Similar to current bahaviour.
2. Define a single property ant.import.file which is resolved at import time
to the import location. All other properties are nt resolved.
+1 as now
3. All containers are projects for IDE compatibility. Note, however, that
there will be some build files, designed to be imported, which will not be
valid standal;ong build files - e.g. their targets may depend on non-existent
targets which the importer is to provide.
+1 as now
4. All normal Ant operations (i.e. not imports) are resolved to the basedir of
the outer project. There is no access to other basedirs.
+1 as now
5. Import specs are relative to importing file location. Don't use href as it
creates expectations of a URL which opens up issues.
+1 as now
6. An attribute may be added to the project element to mark a build file as
not importable.
+1 Similar to current behaviour.
So basically add:
import file= prefix=/
^
and
project importable=true||false||[undefined]/
^
Keep is Simple.
The current version is in fact made to minimize changes and keep it very
simple, and it seems that you are coming too to my conclusions.
The problem, as you correctly note, is not about import per se, but
about false expectations that people try to realize with it.
My question is: what are users trying to do with it that is not in his
scope and cannot be done with ant?
--
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: ant 1.5.4 : Import
Conor MacNeill wrote, On 29/07/2003 9.15:
On Tue, 29 Jul 2003 04:56 pm, Nicola Ken Barozzi wrote:
I think this is all getting too complex for import. What you are
describing is project composition where each project maintains its own
context, its own basedir, etc.
AFAIK this is done with ant
Not quite the same. projectref allowed the projects to be running in
tandem and for dependencies to exist beteween the projects. e.g.
projectref file=blah.xml ref=blah/
target name=test depends=blah:init
javac srcdir=${blah:src.dir}/
/target
Syntax et al up for grabs but still very different from ant
Ah, ok, now I get it, thanks :-)
Basically it's an ant file that exposes targets and properties.
Given this, I understand the proposal of making:
import - include
projectref - import
although I'm personally +-0 on either denomination.
But is the above not overlapping with Gump?
Personally, I don't see the real need for it, as the same can be done
with correctly-written @importable files. In the specific, init values
should be included rather than imported.
Can you point me to some relevant use-cases?
TIA
--
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: ant 1.5.4 : Import
Stefan Bodewig wrote, On 29/07/2003 12.59: If you want to simplify things, why not go even further? On Tue, 29 Jul 2003, Conor MacNeill [EMAIL PROTECTED] wrote: 1. import with optional name. The name is to be used in the renaming of targets. I'd like to think about removing target renaming completely. What exactly is the use-case for this? I've come up with a vague idea, but it would help tremendously what people do want this feature for. I thought I had already answered this? Anyway, the need is that I have to be able to override a target I import. For example, let's say I have a compile target I want to import, and I want to make it additionally call the pre target before and the post target after. This is a very common usecase that can make me reuse targets with minor adjustments case per case. So, let's say that there is no renaming. To use the imported compile target I will have to make my mycompile target. project import file=commontargets.xml/ target name=mycompile depends=pre, compile, post/ target name=pre /target target name=post /target /project Now all seems ok, just a minor issue that I cannot use compile but have to change name... Then I want to run the test target that is in the imported buildfile. Wait a sec, the test target in the imported buildfile is: target name=test depends=compile /target But it won't work, as I need to call pre to be able to launch a compile! There is no way out, I'm not able anymore to use an imported target. In case of renaming, I can do: project import file=commontargets.xml/ target name=compile depends=pre, original.compile, post/ target name=pre /target target name=post /target /project and test will work. What renaming does is give me the possibility of decorating the imported targets, and effectively importing the dependency graph, not only the single targets. This is a major feature of import. 2. Define a single property ant.import.file which is resolved at import time to the import location. All other properties are nt resolved. Why does the imported/included file need to know its name, after we've limited it to not access resources relative to its own basedir as in It *has* to be able to access resources relative to it's position, else for most purposes it's useless. The problem comes with the concept of basedir, as in normal buildfiles it references the path WRT which all paths are resolved. Here they are *not* resolved automatically, but the author can use to do it in a similar way by using the and file position. It's the automaticity of this resolving that is the problem, and basedir is normally associated with it. 4. All normal Ant operations (i.e. not imports) are resolved to the basedir of the outer project. There is no access to other basedirs. If the above two features were missing, it would be almost of no use. And yes, in that case it would have to be called imclude. -- 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: CVS.exe for Ant
Anderson, Robert H - MWT wrote, On 25/07/2003 0.35: It would be nice if the cvs tasks were rewritten to use a java cvs implementation rather than the native cvs binary for the os. Is there a java cvs implementation that is prefered? Thoughts? Well, AFAIK there is JCvs and the NetBeans CVS module. JCVS did not have an Apache-compatible license, but I've heard that the author thought of changing it, but I still don't know. What I would suggest is the NetBeans CVS library, as: - it's license compatible - it has a good user base (Netbeans users) - it has a community around it If you look on the Netbeans site you will find the project page of this library with instructions on how to use it standalone. It would be great if Ant used it :-D -- 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: ant 1.5.4 : Import
Conor MacNeill wrote, On 25/07/2003 17.19:
On Sat, 26 Jul 2003 12:52 am, Stefan Bodewig wrote:
On Sat, 26 Jul 2003, Conor MacNeill [EMAIL PROTECTED]
wrote:
Clear as mud?
Errm, yes.
How would you do
taskdef resource=...
classpath
fileset dir=lib/ includes=*.jar/
/classpath
/taskdef
??
By not using relative paths (but something like ${this.basedir}/lib),
I guess.
Good question. Currently you get a property telling you the location of your
build file - not your basedir.
Correct, bacause the basedir has no meaning as the file is imported.
What about ant.projectdir and ant.projectdir.projectname properties?
BTW, the property is based on the project's name which might be an issue if
the name is controllable by the importing build file. Is a name mandatory for
an importable project or just one that want to know its location?
IMHO the latter.
Explaining a bit more my cases:
1) I have a project that is made only to be imported:
fragment name=.../fragment
- Ant will deny the use of it standalone -
I would need this when I use the ant.file.currentproject
property that is not available when I run it standalone.
(although we could as well put it, and so this use-case
looses meaning it seems)
2) I have a project that is not made to be imported:
project importable=false.../project
- Ant will deny the use of it as imported -
This project does not check that the resources and paths
are resolved using the ant.file.projectname property, and
thus would not work properly if imported.
In this case the name attribute is mandatory.
3) I have a project that can be imported or used as-is:
project importable=true.../project
- Ant will never deny it's use -
This project does not use external resources, or
checks for them in a manner that works in both scenarios.
4) I have a project that does not say if it can be imported:
project importable=true.../project
- Ant will never deny it's use but warn if it's imported -
The author does not tell you how it's meant to use.
Most probably it's not made to be imported, so if you want
to import it, good luck!
--
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: ant 1.5.4 : Import
Conor MacNeill wrote, On 24/07/2003 13.36: On Thu, 24 Jul 2003 07:19 pm, peter reilly wrote: What are the issues with import. I think we should write them down and deal with them - it cannot be that difficult.. The difficult ones (manipulation of basebir etc) we should explicitly defer to ant 1.6. Not difficult but the issues are there. The renaming of overridden targets depends on project names but lots of projects don't have names. I believe the name can be provided in the import task to access overridden targets in unnamed projects and also to handle name collisions. What about: import file=blah.xml name=blah/ Probably would require creation of the parsing context in the import task. ? The basedir issue :-). I'd rather get it right in 1.6 than create a backward compatibility issue down the track. Got enough of those to deal with already. Import file resolution must be done relative to the basedir of the project doing the import, regardless of whether that is the outermost project. For example, project basedir=.. import file=base2/build.xml/ echo message=base1/build.xml/ /project This will not work: Cannot find base2/build.xml imported from base1/build.xml I've attached a small zip (will it make it through email?). I believe all 3 builds should work as you would expect. Currently only the one without imports does. In base1/build.xml I changed the import to: import file=../base2/build.xml/ And it works. So IIUC it's really only about making the import task resolve files relative to the basedir of the project that imports, as you say above. Telling people only to use absolute imports is not acceptable, IMHO. IMHO what you propose is the correct behaviour, and the one that users (me too) would think should happen (least surprise rule). import is a real cool feature. Sure enough and also important enough to get right. +1 -- 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: ant 1.5.4 : Import
Conor MacNeill wrote, On 24/07/2003 14.49:
On Thu, 24 Jul 2003 10:26 pm, Nicola Ken Barozzi wrote:
What about:
import file=blah.xml name=blah/
Sure - pretty much what I thought, maybe a more descriptive attribute name
(overrideprefix). It would default to the imported project name.
A bit long...
What about this, it seems descriptive enough IMHO.
import file=blah.xml prefix=blah/
or
import file=blah.xml use-prefix=blah/
So IIUC it's really only about making the import task resolve files
relative to the basedir of the project that imports, as you say above.
Yes. This is how Ant works for other tasks so it should work that way for
import too. The resolution does have to be done in Import itself using a
String argument since the default File argument would be resolved by Ant to
the outermost project's basedir which would be wrong.
Well, import already uses a String argument but does the following:
// Paths are relative to the build file they're imported from,
// *not* the current directory (same as entity includes).
File importedFile = new File(file);
if (!importedFile.isAbsolute()) {
importedFile = new File(buildFileParent, file);
}
I reckon that this change would resolve to the initial basedir, right?
File importedFile = new File(getProject().resolveFile(file));
if (!importedFile.isAbsolute()) {
importedFile = new File(buildFileParent, file);
}
Don't have time to try it ATM :-(
--
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: ant 1.5.4 : Import
Dominique Devienne wrote, On 24/07/2003 16.55:
...
In other words, the context of execution of any imported file should be the
top level build file. I foresee no end in the confusion that would result
otherwise.
Some might argue that an imported file should be able to know where if was
imported from, but I see this as dangerous. It's a limitation that would
make imports in Ant very straightforward.
Can you please expand on this point?
The dir argumentation is what follows:
- imported buildfile targets are like macros, thus are usually intended
to be used as if inserted in the main buildfile itself
- some of the imported targets may need resources relative to *them*,
and not the importing file, hence the importedfile.ant.file property
Thus all things in the imported file are done relative to the *base*
file, and hence the current way would be correct.
Thus, in the sake of consistency, I now start to think that something
like the following would be needed to make what Conor thinks should happen:
import file=${thisprojectname.ant.file}/../base2/build.xml/
or better
import file=${thisprojectname.basedir}/base2/build.xml/
--
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: ant 1.5.4 : Import
Dominique Devienne wrote, On 24/07/2003 17.23: Did my other messages answer your questions??? --DD IIUC we agree. -- 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: ant 1.5.4 : Import
Dominique Devienne wrote, On 24/07/2003 17.18: This is indeed a valid use of knowledge of where an imported file was imported from. I still think (strongly) that the basedir of any imported file should be ignored (with a warning if it's something else than ., the default), and always use the one of the top-level build. To allow the use-case presented by Stefan, and disambiguate unequivocally what is being used, a new magic attribute should used to locate resources/files relative to the currently imported file. During import, this magic attribute would be resolved/replaced at parse time, so each imported file is fully resolved against is own directory. Finding names is always difficult, but an 'importdir' attribute doesn't sound too bad. --DD There is already an ant.file.importedfilename that can be used by immported files, and we have asked to make it since a long time ago, because we found out in Centiepde that it was needed. Is it this what you are saying? http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/docs/manual/CoreTasks/import.html?rev=HEADcontent-type=text/html Stefan Bodewig wrote, On 24/07/2003 17.09: ... The usecase for the later is something like Centipede's cents (as I understand them) where a taskdef in the imported snippet needs to specify jars for the classpath - and would do so using relative paths. For easier installment of the full package, that should be relative to the imported file IMHO. But since we package cents and get the resources for the cents, and install the cents in their own dirs, for us it makes sense to keep the references relative. -- 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]
[GUMP] Build Failure - ant-embed-optional
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-07-15/ant-embed-optional.html
Buildfile: build.xml
init:
[mkdir] Created dir: /home/rubys/jakarta/ant/proposal/embed/build/classes
embed-optional:
[javac] Compiling 11 source files to
/home/rubys/jakarta/ant/proposal/embed/build/classes
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/JXPathSet.java:73:
duplicate class: org.apache.tools.ant.taskdefs.optional.JXPathSet
[javac] public class JXPathSet extends Task {
[javac]^
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/JXPath.java:74:
duplicate class: org.apache.tools.ant.taskdefs.optional.JXPath
[javac] public class JXPath extends Task {
[javac]^
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/VelocityProperties.java:73:
duplicate class: org.apache.tools.ant.taskdefs.optional.VelocityProperties
[javac] public class VelocityProperties extends Task {
[javac]^
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/JexlProperties.java:71:
duplicate class: org.apache.tools.ant.taskdefs.optional.JexlProperties
[javac] public class JexlProperties extends Task {
[javac]^
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/TaskDiscovery.java:77:
duplicate class: org.apache.tools.ant.taskdefs.optional.TaskDiscovery
[javac] public class TaskDiscovery extends Task implements
ProjectComponentFactory
[javac]^
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/JXPath.java:76:
modifier public static not allowed here
[javac] public static String PREFIX=jxpath:;
[javac] ^
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/VelocityProperties.java:74:
modifier public static not allowed here
[javac] public static final String PREFIX=vm:;
[javac]^
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/optional/JexlProperties.java:72:
modifier public static not allowed here
[javac] public static String PREFIX=jexl:;
[javac] ^
[javac] 8 errors
BUILD FAILED
/home/rubys/jakarta/ant/proposal/embed/build.xml:55: Compile failed; see the
compiler error output for details.
Total time: 4 seconds
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant 1.6 import task
Steve Collins wrote, On 14/07/2003 23.47: I would like to see an option to the import task of whether the file must exist. Ant exits now if the imported file is not there. It would be useful to me since my build file uses XSLT to generate files to be imported and those files are not there on the first run of the build script. Can't you import after the transformation? Have you tried using the condition task? -- 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: [GUMP] Build Failure - ant-embed
Stefan Bodewig wrote, On 27/06/2003 16.00: ... Keep in mind that ant-embed is supposed to be used with Ant 1.5 - if it doesn't compile against Ant 1.6, that's fine IMHO. We just would need to remove it from Gump and ensure that the Krysalis stuff doesn't depend on it. We have moved fully to the 1.6 branch, so Krysalis projects are no longer dependent on ant-embed core. We are also switching from plain jxpath to our own interceptor, so we are almost completely off ant-embed. Thanks for caring :-) -- 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]
[GUMP] Build Failure - ant-embed
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-27/ant-embed.html
Buildfile: build.xml
init:
main-ant15:
[echo] Embed is no longer supported with ant1.6. It is only used with
ant1.5 ! The dynamic properties work with both, use embed-optional target
[javac] Compiling 9 source files to
/home/rubys/jakarta/ant/proposal/embed/build/classes
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/Taskdef2.java:222:
addDefinition(java.lang.ClassLoader,java.lang.String,java.lang.String) in
org.apache.tools.ant.taskdefs.Taskdef2 cannot override
addDefinition(java.lang.ClassLoader,java.lang.String,java.lang.String) in
org.apache.tools.ant.taskdefs.Definer; attempting to assign weaker access
privileges; was protected
[javac] private void addDefinition(ClassLoader al, String name, String
value)
[javac] ^
[javac]
/home/rubys/jakarta/ant/proposal/embed/src/java/org/apache/tools/ant/taskdefs/Taskdef2.java:242:
createLoader() in org.apache.tools.ant.taskdefs.Taskdef2 cannot override
createLoader() in org.apache.tools.ant.taskdefs.Definer; attempting to assign
weaker access privileges; was protected
[javac] private AntClassLoader createLoader() {
[javac]^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 2 errors
BUILD FAILED
/home/rubys/jakarta/ant/proposal/embed/build.xml:37: Compile failed; see the
compiler error output for details.
Total time: 3 seconds
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overridable targets?
Steve Cohen wrote, On 06/06/2003 16.54: Here is a radical idea that I'd like to kick around a little. The prohibition against more than one target of the same name in the same build script seems logical, but it impedes a form of reuse that I think would be very handy to use. It is already done in the import task that is in CVS for Ant 1.6. So no more entity includes but a task to include other buildfiles, also with target override, and super target calling, so you can basically extend the imported target. -- 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: Namespaces in Ant
Costin Manolache wrote, On 03/05/2003 16.14: Nicola Ken Barozzi wrote: ... I think that XML namespaces really make things much more difficult to write and understand. One thing I don't like in Jelly is just this use of namespaces, where all scripts seem cluttered and simply difficult to read. I agree - in most small build files, with few libraries and no conflicting names it is simpler to not use ns. I don't think anyone is sugesting to make ns required for 1.6 ( we need to keep backward compat ). Even for antlibs, I think the ns should be an option. Ok, but namespaces are a heavy way of doing separation. ATM I don't think that that it's good if they are not always used (and I don't like much to see them used). This is why I favor that Antlibs work similarly to java imports, where there are no prefixes *except* when specified, and then I would *not* make prefixes free, but use the standars full name for that Antlib. Can you give an example ? Sure. Every antlib descriptor should contain not only the names of the tasks but also the namespace of the antlib. When Ant loads the tasks, it does it with two names, so that the task can be called with short or the fully qualified name. Example: antlib location=antcontrib.jar/ !-- I can call it on both ways -- if/ antcontrib.if/ In the case that a library declares a task with the same name of one already loaded, Ant should load the fully qualified name version and change the short-name version to output an error about clashing names. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: NameSpace antlib was (Re: polymorphism)
Jose Alberto Fernandez wrote, On 29/04/2003 12.03: ... The proposal antlib provides a task antlib which can be used to load libraries manually. Al the same time there are hooks on the code for an autoloading mechanism to be supported. In escence, it would allow ANT's main() to do something like: - 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. 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. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: NameSpace antlib was (Re: polymorphism)
peter reilly wrote, On 28/04/2003 19.37:
On Sunday 27 April 2003 22:14, Wannheden, Knut wrote:
...
but maybe the buildfile author wants/needs to specify the namespace URI
(anything really), in which case an additional ns attribute could be
used:
antlib resource=${foo.jar} ns=urn:antlib:foo/
foo:bar xmlns:foo=urn:antlib:foo/
This is fine.
antlib file=${ant-contrib.jar} ns=antlib:antcontrib/
antcontrib:if xmlns:antcontrib =antlib:antcontrib
target xmlns:antcontrib=antlib:antcontrib name=compile
antcontrib:propertycopy .../
/target
This is *very* ugly. I like that Ant buildfiles are reasonably
readable, and would like to have it maintained if possible.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: NameSpace antlib was (Re: polymorphism)
peter reilly wrote, On 28/04/2003 19.53:
On Monday 28 April 2003 18:41, Nicola Ken Barozzi wrote:
peter reilly wrote, On 28/04/2003 19.37:
On Sunday 27 April 2003 22:14, Wannheden, Knut wrote:
...
but maybe the buildfile author wants/needs to specify the namespace URI
(anything really), in which case an additional ns attribute could be
used:
antlib resource=${foo.jar} ns=urn:antlib:foo/
foo:bar xmlns:foo=urn:antlib:foo/
This is fine.
antlib file=${ant-contrib.jar} ns=antlib:antcontrib/
antcontrib:if xmlns:antcontrib =antlib:antcontrib
target xmlns:antcontrib=antlib:antcontrib name=compile
antcontrib:propertycopy .../
/target
This is *very* ugly. I like that Ant buildfiles are reasonably
readable, and would like to have it maintained if possible.
True. It seems quite difficult to use namespaces in a nice way.
The niceest I can thing of is to place all the jars in
${ant.home}/lib and set the namespace up in the project declation:
project xmlns:antcontrib=antlib:${ant.home}/lib/ant-contrib.jar
xmlns:antcontrib=antlib:${ant.home}/lib/antleope.jar
Well, defining a namespace does not assume that it's attached to a
meaning, so I could define it in the project declaration but only load
the task it's attached to later.
project xmlns:antcontrib=net/sf/antcontrib
!-- ant-contrib.jar knows that it binds to net/sf/antcontrib --
antlib file=${ant-contrib.jar}/
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
[Fwd: Re: antlib]
Jose Alberto Fernandez wrote, On 22/04/2003 19.20: Hi guys, I would propose to that instead of antlib calling ruper, the rupper people can provide a ruperautoload task (or whatever other name you want) that will do all the finding and downloading and then will invoque antlib. If we do this, then we can concentrate here on the local antlib while someone else can take care of the external work. Ok, agreed. In reality, we already have it ;-) In Centipede antlibs are called cents, and to get them it's called importcent. Cents are versioned, can automatically import snippets, can be autodownloaded, installed and shared, contain resources, and can add tasks and types. I'll keep it that way, and maybe it's better for all; architecturaly speaking it also makes better layering and separation of concerns. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
