Re: SubAnt performance
On 2009-09-25, Raja Nagendra Kumar nagendra.r...@tejasoft.com wrote: isolation between the calling and thecalled project. stefan, it is true of inherit* properties, however here are some scenarios Then I'd think subant is the wrong task in that context. I don't understand why you'd be calling subant on yourself anyway. The depends attribute on target or a macrodef sound like better solutions. 2. the inherit properties are set to true only and isolation is not a concern in such scenario. How would subant know that isolation is not a concern? Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: SubAnt performance
Then I'd think subant is the wrong task in that context. I don't understand why you'd be calling subant on yourself anyway. we have a target like 'clean' which deletes current directories 'build' folder and calls all the sub directories clean target. The sub directories build build file calls the same clean target.. the clean targets is impl. some thing very similar to recursions with different directory roots sets by subant. Regards, Nagendra -- View this message in context: http://www.nabble.com/SubAnt-performance-tp25605193p25622292.html Sent from the Ant - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: SubAnt performance
On 2009-09-25, Raja Nagendra Kumar nagendra.r...@tejasoft.com wrote: Currently I see subant is launching new ant even if the build file is same as the current one being executed. A new Project instance, but not a new process. Would it not be more fast to excute the target in the current ant process it self, provided build file and directory are same. It would be faster but it would be something different at the same time since you'd no longer have any isolation between the calling and the called project. Right now the called project doesn't see the references defined in the calling project (inheritRefs), may not see the properties (inheritAll) may see temporarily redefined values for properties (nested param tags) - and nothing the called project does to references or properties has any effect on the calling project. All of that wouldn't be possible if subant was using the same project instance as the calling one. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: SubAnt output
On Thu, 01 Jul 2004, Christian Knorr [EMAIL PROTECTED] wrote: I am new to this list. By browsing the archives I could not find anything related to my problem but forgive me if it has already been mentioned: It hasn't. Thanks for the patch! Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SubAnt output
I'm not one of the gurus but as far as I understood the mechanism the logger has to deal with output on standard out and standard error in addition to the builtin methods which might be called by task implementations. In my case we had such a tool (javac) output to standard error. To identify the correct target the project has a hashtable to recognize its last active task/target. The responsibility to catch standard out and standard error is with the top-level project, so the last active task to be found is the SubAnt task. The fix delegates this to its Ant sub-project if it is currently active and this project can now find the according (now correct!) task. I don't know if timing/synchronization has to be considered when accessing the Ant sub-project at least it works in our scenario. ;) Hope this helps, Christian Dominique Devienne wrote: Cool. Thanks for fixing this. Even though it's a bit late, I would like this patch to make it to 1.6.2. Does anyone object? But on a different note, even though I looked at the patch, I'm not sure I understand why adding these methods fixes the problem (as was involved in writing SubAnt.java initially). I would have thought that executing the nested Ant would have been enough to properly nest the messages. Could someone savvy with the Ant logging mechanism explain/describe this mechanism and why this patch fixes the issue here!? Christian? Conor? Stefan? Antoine? Peter? Anyone? Thanks, --DD -Original Message- From: Christian Knorr To: [EMAIL PROTECTED] Sent: 7/1/2004 7:00 AM Subject: SubAnt output Hi, I am new to this list. By browsing the archives I could not find anything related to my problem but forgive me if it has already been mentioned: In our hierarchical build structure we use the SubAnt task to delegate all tasks to our components specific build-scripts. In combination with CruiseControl we realized that the XML output generated by the XMLLogger does not represent a correct correlation of messages to tasks when using SubAnt: Buildfile: build.xml ?xml version=1.0 encoding=UTF-8 ? ?xml-stylesheet type=text/xsl href=log.xsl? build error=D:\prj\test\ant\build.xml:6: Following error occured while executing this line D:\prj\test\ant\sub\build.xml:6: Compile failed; see the compiler error output for details. time=1 second target name=build time=1 second task location=D:\prj\test\ant\build.xml:6: name=subant time=1 second message priority=warn![CDATA[D:\prj\test\ant\sub\src\Test.java:4: cannot resolve symbol]]/message message priority=warn![CDATA[symbol : method printer ()]]/message message priority=warn![CDATA[location: class java.io.PrintStream]]/message message priority=warn![CDATA[ System.out.printer();]]/message message priority=warn![CDATA[ ^]]/message message priority=warn![CDATA[1 error]]/message target name=build time=0 seconds task location=D:\prj\test\ant\sub\build.xml:6: name=javac time=0 seconds message priority=info![CDATA[Compiling 1 source file]]/message /task /target /task /target stacktrace![CDATA[D:\prj\test\ant\build.xml:6: Following error occured while executing this line D:\prj\test\ant\sub\build.xml:6: Compile failed; see the compiler error output for details. at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHe lper.java:574) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:422) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:219) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:149) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:306) at org.apache.tools.ant.Task.perform(Task.java:401) at org.apache.tools.ant.Target.execute(Target.java:338) at org.apache.tools.ant.Target.performTasks(Target.java:365) at org.apache.tools.ant.Project.executeTarget(Project.java:1237) at org.apache.tools.ant.Project.executeTargets(Project.java:1094) at org.apache.tools.ant.Main.runBuild(Main.java:669) at org.apache.tools.ant.Main.startAnt(Main.java:220) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:215) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:90) ]]/stacktrace /build Obviously all the 'message' elements should be children of the 'javac task' element. It seems to me that the SubAnt task does not take care of the new project which is being created by its child Ant tasks. As a quick fix for us I patched the SubAnt task to work similar as the Ant task does. But instead of the 'project' variable I made the 'ant' variable a field which is only valid during execution of the associated project. Please let
Re: SubAnt output
On Thu, 1 Jul 2004, Dominique Devienne [EMAIL PROTECTED] wrote: Even though it's a bit late, I would like this patch to make it to 1.6.2. Does anyone object? It's in, even if it doesn't go into 1.6.2 RC (no idea whether antoine has started to work on it already). I would have thought that executing the nested Ant would have been enough to properly nest the messages. No. The output is dispatched to the task associated with the thread(group) - and the association happens when the taskStarted event is fired. When you delegate to another task's execute, this task will not fire taskStarted. So even if you delegate execute to Ant, the delegating task's I/O handling methods will get called. Take a look at Conor's great article http://codefeed.com/blog/archives/68.html#more. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SubAnt output
Stefan Bodewig wrote: On Thu, 1 Jul 2004, Dominique Devienne [EMAIL PROTECTED] wrote: Even though it's a bit late, I would like this patch to make it to 1.6.2. Does anyone object? It's in, even if it doesn't go into 1.6.2 RC (no idea whether antoine has started to work on it already). I plan to get started in half an hour with this 1.6.2 RC. Cheers, Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SubAnt output
From: Stefan Bodewig I would have thought that executing the nested Ant would have been enough to properly nest the messages. No. The output is dispatched to the task associated with the thread(group) - and the association happens when the taskStarted event is fired. When you delegate to another task's execute, this task will not fire taskStarted. So even if you delegate execute to Ant, the delegating task's I/O handling methods will get called. [DD] What if instead of adding all these methods, we called [DD] ant.perform() instead of ant.execute()!? [DD] perform() fires the the taskStarted event, so would that be [DD] enough? Would be a lot less code, no? Take a look at Conor's great article http://codefeed.com/blog/archives/68.html#more. [DD] Thanks for the pointer Stefan. I'll study this. [DD] I wish we could centralize more the info though, or [DD] at least reference such articles from the main Ant side. [DD] Thanks, --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SubAnt output
On Fri, 2 Jul 2004, Dominique Devienne [EMAIL PROTECTED] wrote: [DD] What if instead of adding all these methods, we called [DD] ant.perform() instead of ant.execute()!? [DD] perform() fires the the taskStarted event, so would that be [DD] enough? Would be a lot less code, no? It would help with the I/O problem but at the same time cause a task started event for ant which would lead to some visible output. This would make the design choice of delegating to Ant use visible and even be confusing to users (which ant task? I never started an ant task). Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SubAnt output
-Original Message- From: Stefan Bodewig On Fri, 2 Jul 2004, Dominique Devienne [EMAIL PROTECTED] wrote: [DD] What if instead of adding all these methods, we called [DD] ant.perform() instead of ant.execute()!? [DD] perform() fires the the taskStarted event, so would that be [DD] enough? Would be a lot less code, no? It would help with the I/O problem but at the same time cause a task started event for ant which would lead to some visible output. This would make the design choice of delegating to Ant use visible and even be confusing to users (which ant task? I never started an ant task). [DD] Hmmm, I see your point. I personnally don't mind exposing this [DD] aspect of the implementation of SubAnt, especially when in fact [DD] a lot of tools look for the execution of Ant to find out about [DD] subbuilds. This point is kind of moot with your addition of [DD] SubBuildListener though. [DD] I still think that the fact that SubAnt must be aware of these [DD] I/O issues is not very clean, since not fully encapsulated in [DD] Ant itself. It would be better if Ant explicitly pushed its [DD] new Project on Ant's I/O subsystem to associate it to the current [DD] thread, popping it in a finally, and not have to make SubAnt [DD] or any task that internally uses an Ant instance (I have several!) [DD] explicitly deal with it. [DD] I hope I'm making sense. Thanks, --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SubAnt output
On Fri, 2 Jul 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: Maybe Ant should provide its own delegation entry point since this is a very common pattern of use. But maybe not something you want to expose. Do you want to see [ant] show up in the log instead of [subant]? If so, a simple invocation of getProject().registerThreadTask(Thread.currentThread(), ant) before ant.execute() would have done the trick. Hmm, ant.setTaskName(getTaskName()) would solve the [ant] vs. [subant] issue. So, a task that wants to delegate its work to Ant, will call something like: Ant ant = new Ant(...); //Configure it ... ant.delegate(this); // was ant.execute(); The name looks the wrong way around since delegate is active and really this is delegating to ant. For some time we've been kicking around the idea of a utility class for the delegation cases // uses project.createTask, transfers task name and target ... DelegatedTask ant = new DelegatedTask(this, ant); // uses IntrospectionHelper, also supports nested elements in // some way ant.setAttribute(buildfile, buildFile); // registers itself as task responsible for output, calls // execute and deregisters itself at the end ant.execute(); Maybe is is something for 1.7. At least not for 1.6.2 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SubAnt output
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Fri, 2 Jul 2004, Jose Alberto Fernandez [EMAIL PROTECTED]
wrote:
Maybe Ant should provide its own delegation entry point
since this is
a very common pattern of use.
But maybe not something you want to expose. Do you want to
see [ant] show up in the log instead of [subant]?
Not at all, the point is that when within a task that I write
I programatically use the functionality of other tasks, that
should not be visible to the user of my task which does not
need to know about how I implemented my task.
The user should only be aware about the tasks he expresses
in the buildfile and not about my implementation details.
If so, a simple invocation of
getProject().registerThreadTask(Thread.currentThread(), ant) before
ant.execute() would have done the trick. Hmm,
ant.setTaskName(getTaskName()) would solve the [ant] vs.
[subant] issue.
Why force every code writer to do all this stuff.
I guess my point is how to facilitate 3rd parties to write better
behaved tasks and to encourage reuse.
So, a task that wants to delegate its work to Ant, will
call something
like:
Ant ant = new Ant(...);
//Configure it ...
ant.delegate(this); // was ant.execute();
The name looks the wrong way around since delegate is active
and really this is delegating to ant.
True, so maybe having in Ant.java:
public void delegatedFrom(Task caller) {
getProject().registerThreadTask(Thread.currentThread(), this);
setTaskName(caller.getTaskName());
try {
execute();
}
finally {
// Is there any need to unregister here?
}
}
Could something like this solve the issue with SubAnt in effectively
much less code?
Or is SubAnt's case more complicated.
For some time we've been kicking around the idea of a utility
class for the delegation cases
// uses project.createTask, transfers task name and target ...
DelegatedTask ant = new DelegatedTask(this, ant);
// uses IntrospectionHelper, also supports nested elements in
// some way
ant.setAttribute(buildfile, buildFile);
// registers itself as task responsible for output, calls
// execute and deregisters itself at the end
ant.execute();
This is fine, but you still need to support the case where one wants
to execute a specific Java class (i.e., not whatever was registered)
and achive the same thing. So one at least needs another constructor.
for DelegatedTask. How does one configures elements on this model?
In principle I am all for something that helps external people
write better code.
Maybe is is something for 1.7.
At least not for 1.6.2 8-)
Definetly :-)
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: SubAnt output
-Original Message- From: Stefan Bodewig If so, a simple invocation of getProject().registerThreadTask(Thread.currentThread(), ant) before ant.execute() would have done the trick. Hmm, ant.setTaskName(getTaskName()) would solve the [ant] vs. [subant] issue. [DD] This is what I was trying to say earlier, except that if [DD] Ant.java itself was pushing (and popping if needed) [DD] itself as the current threadTask in its execute() method [DD] then SubAnt.java would not need to do any of that. [DD] At least in my original impl of SubAnt.java, I was already [DD] call ant.setTaskName(getTaskName()), so the name was not [DD] really the issue (for me). [DD] All I'm trying to say, and I think Jose Alberto as well, is [DD] poor sobs like me who do not understand (or are even aware) [DD] of Ant's I/O system should be able to reuse Ant.java without [DD] knowing the details, 'cause Ant.java would do the right thing. For some time we've been kicking around the idea of a utility class for the delegation cases // uses project.createTask, transfers task name and target ... DelegatedTask ant = new DelegatedTask(this, ant); // uses IntrospectionHelper, also supports nested elements in // some way ant.setAttribute(buildfile, buildFile); // registers itself as task responsible for output, calls // execute and deregisters itself at the end ant.execute(); [DD] This looks useful in its own right, especially for prototyping [DD] purposes when writing a script or scriptytypef. But I believe [DD] this is a bit different than the pb at hand. OK, it's not really [DD] a pb as a patch is already in, it's just that I don't really like [DD] what the patch means, i.e. that you need detailed and intimate [DD] knowledge of Ant.java to use it correctly. Any API should strive [DD] to make difficult to write bad code, and ease writing good code, [DD] and I just learned about Ant.java contradicts this principle. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SubAnt output
Cool. Thanks for fixing this. Even though it's a bit late, I would like this patch to make it to 1.6.2. Does anyone object? But on a different note, even though I looked at the patch, I'm not sure I understand why adding these methods fixes the problem (as was involved in writing SubAnt.java initially). I would have thought that executing the nested Ant would have been enough to properly nest the messages. Could someone savvy with the Ant logging mechanism explain/describe this mechanism and why this patch fixes the issue here!? Christian? Conor? Stefan? Antoine? Peter? Anyone? Thanks, --DD -Original Message- From: Christian Knorr To: [EMAIL PROTECTED] Sent: 7/1/2004 7:00 AM Subject: SubAnt output Hi, I am new to this list. By browsing the archives I could not find anything related to my problem but forgive me if it has already been mentioned: In our hierarchical build structure we use the SubAnt task to delegate all tasks to our components specific build-scripts. In combination with CruiseControl we realized that the XML output generated by the XMLLogger does not represent a correct correlation of messages to tasks when using SubAnt: Buildfile: build.xml ?xml version=1.0 encoding=UTF-8 ? ?xml-stylesheet type=text/xsl href=log.xsl? build error=D:\prj\test\ant\build.xml:6: Following error occured while executing this line D:\prj\test\ant\sub\build.xml:6: Compile failed; see the compiler error output for details. time=1 second target name=build time=1 second task location=D:\prj\test\ant\build.xml:6: name=subant time=1 second message priority=warn![CDATA[D:\prj\test\ant\sub\src\Test.java:4: cannot resolve symbol]]/message message priority=warn![CDATA[symbol : method printer ()]]/message message priority=warn![CDATA[location: class java.io.PrintStream]]/message message priority=warn![CDATA[ System.out.printer();]]/message message priority=warn![CDATA[ ^]]/message message priority=warn![CDATA[1 error]]/message target name=build time=0 seconds task location=D:\prj\test\ant\sub\build.xml:6: name=javac time=0 seconds message priority=info![CDATA[Compiling 1 source file]]/message /task /target /task /target stacktrace![CDATA[D:\prj\test\ant\build.xml:6: Following error occured while executing this line D:\prj\test\ant\sub\build.xml:6: Compile failed; see the compiler error output for details. at org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHe lper.java:574) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:422) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:219) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:149) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:306) at org.apache.tools.ant.Task.perform(Task.java:401) at org.apache.tools.ant.Target.execute(Target.java:338) at org.apache.tools.ant.Target.performTasks(Target.java:365) at org.apache.tools.ant.Project.executeTarget(Project.java:1237) at org.apache.tools.ant.Project.executeTargets(Project.java:1094) at org.apache.tools.ant.Main.runBuild(Main.java:669) at org.apache.tools.ant.Main.startAnt(Main.java:220) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:215) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:90) ]]/stacktrace /build Obviously all the 'message' elements should be children of the 'javac task' element. It seems to me that the SubAnt task does not take care of the new project which is being created by its child Ant tasks. As a quick fix for us I patched the SubAnt task to work similar as the Ant task does. But instead of the 'project' variable I made the 'ant' variable a field which is only valid during execution of the associated project. Please let me know if there is anything else I might have missed or if this is the way to go. Feel free to apply the patch (which has been performed on Ant 1.6.1) to the Ant sources (although I guess there is a much cleaner way to accomplish this). Cheers, Christian P.S.: In addition to the patch file I also added the build files to reproduce the erroneous behaviour. ___ EADS SPACE Transportation - TE 55 - Phone: +49-421-539-5673 subAntOutputStructure.patch ATT37308.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: subant
I actually signed off lsync, not subant, technically, but in practice I give both. Anything I submit to BugZilla is good for the taking, and I'll refrain to include my usual/automatic copyright notice in the future. Sorry to hear you suppressed passing down the current target name... That one of the feature of that task I won't live without. But that's OK, I'll keep using my own task then (actually I would anyhow for the dependency ordering I have). Thanks for including it. --DD -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 6:48 PM To: ant-dev Subject: subant subant is in as a core task; DD says he's signed the handoff form already. I made two changes to his submission, both related to targeting. 1. target= implies we want to invoke the default target. This lets you control target in a property and have map to something meaningful 2. commented out the lines where the default target was actually the name of the current target. I felt that was a bit too much implicit magic; sorry. -Steve
Re: subant
Dominique Devienne wrote, On 14/03/2003 15.50: I actually signed off lsync, not subant, technically, but in practice I give both. Anything I submit to BugZilla is good for the taking, and I'll refrain to include my usual/automatic copyright notice in the future. Yees! lsync is kol :-) Sorry to hear you suppressed passing down the current target name... That one of the feature of that task I won't live without. But that's OK, I'll keep using my own task then (actually I would anyhow for the dependency ordering I have). Centipede does it using the Gump project descriptor. Could it be a wise thing to stick to one version of the two only, or does it make sense to have this anyway? (just asking) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: subant
The dependency ordering addition is pluggeable... you just provide a
resolver implementation. I created only one such implementation for my own
custom format, but a GUMP resolver format would be easy to write. It's just
the matter of parsing the GUMP descriptor, and creating instances that
implements DependencyNode (or provide a DependencyNodeAdapter if it doesn't)
that my DependencyResolver class knows how to sort. Probably Jenny could be
used to load the GUMP project instances, and a dependency adapter
implemented for it.
Note how buildpath returns a double array. This is to allow building in
parallel projects when possible: Consider the usual diamond A, B C depends
on A, D depends on B C, my resolver gives you:
{ {A}, {B,C}, {D} } which tells you can run B and C in parallel. Any project
within an inner array can be build in parallel provided their dependencies
(earlier stuff in the outer array) have been build before.
I already submitted SubAnt.java (the older version).
I now have these other classes I'd submit provided enough interest (the last
two are not of interest to anyone but me):
BuildPath.java
BuildPathResolver.java
DependencyCycleException.java
DependencyNode.java
DependencyNodeAdapter.java
DependencyNodeImpl.java
DependencyResolver.java
DependencyResolverTest.java
TahoeBuildPathResolver.java (private impl of BuildPathResolver)
TahoeProject.java (private impl of DependencyNode)
The build path resolver is specified and configured in a usual Ant way:
buildpath ident=buildpath
resolverClassname=com.lgc.buildmagic.TahoeBuildPathResolver
param name=destdir value=${destdir} /
param name=dependencies value=${dependencies} /
/buildpath
And the class loaded must implement the BuildPathResolver interface defined
below:
package com.lgc.buildmagic;
import java.io.File;
import org.apache.tools.ant.types.Parameterizable;
/**
* Helper class allowing a codeBuildPath/code to be dynamically
* inferred instead of being statically defined.
* p
* Provides the famous emextra level of indirection/em which is the
* solution to all computing problems ;-)
*
* @author a href=mailto:[EMAIL PROTECTED]Dominique Devienne/a
* @version Nov 2002 - Copyright (c) 2002, Landmark Graphics Corp.
*
* @see BuildPath
* @see SubAnt
*/
public interface BuildPathResolver
extends Parameterizable {
/**
* Gets the sorted array of all the build directories or build files
* that need to be build.
*
* @return a non-codenull/code but possibly empty array of build
* files and/or build directories. All returned files being
* directories instead of file will be appended with the anfile
* name defined by the lt;subantgt; task
* (which defaults to build.xml)
*/
File[][] getBuildPath();
} // END class BuildPathResolver
-Original Message-
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2003 8:56 AM
To: Ant Developers List
Subject: Re: subant
Dominique Devienne wrote, On 14/03/2003 15.50:
I actually signed off lsync, not subant, technically, but in practice
I
give both. Anything I submit to BugZilla is good for the taking, and I'll
refrain to include my usual/automatic copyright notice in the future.
Yees! lsync is kol :-)
Sorry to hear you suppressed passing down the current target name... That
one of the feature of that task I won't live without. But that's OK, I'll
keep using my own task then (actually I would anyhow for the dependency
ordering I have).
Centipede does it using the Gump project descriptor. Could it be a wise
thing to stick to one version of the two only, or does it make sense to
have this anyway? (just asking)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
