Re: svn commit: r1476822 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Execute.java
Hi Antoine,
Sometime back I had worked on an issue related to CommandLaunchers and I
noticed that there is a VMSCommandLauncher class for launching processes on
OpenVMS. Is it possible that this code can be moved there? I think this is not
going to be straightforward but won't moving OS specific code to their
corresponding CommandLaunchers help in insulating Ant Core from the specifics
of the underlying OS.
Thanks
Vimil
From: Antoine Levy Lambert anto...@gmx.de
To: dev@ant.apache.org
Sent: Sunday, April 28, 2013 1:37 PM
Subject: Re: svn commit: r1476822 - in /ant/core/trunk: WHATSNEW
src/main/org/apache/tools/ant/taskdefs/Execute.java
Hi,
I did this change while investigating a bug report 45530 which was saying that
Ant incorrectly copies env variables with non-latin text.
It seems that there is now a lot of code which is remaining only for openvms
and I wonder whether this is necessary. If JVMs on openvms are now able to deal
properly with the environment variables,
the complete getProcEnvCommand method in Execute.java can go away, and
getEnvironmentVariables will be much shorter. in private String[]
patchEnvironment there is also some special handling of OpenVMS.
Regards,
Antoine
On Apr 28, 2013, at 3:53 PM, anto...@apache.org wrote:
Author: antoine
Date: Sun Apr 28 19:53:25 2013
New Revision: 1476822
URL: http://svn.apache.org/r1476822
Log:
simplifying Execute.getEnvironmentVariables since we are now always at least
on Java 1.5
Modified:
ant/core/trunk/WHATSNEW
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java
Modified: ant/core/trunk/WHATSNEW
URL:
http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?rev=1476822r1=1476821r2=1476822view=diff
==
--- ant/core/trunk/WHATSNEW (original)
+++ ant/core/trunk/WHATSNEW Sun Apr 28 19:53:25 2013
@@ -27,6 +27,8 @@ Other changes:
* strict attribute added to signjar.
Bugzilla Report 54889.
+ * simplifying Execute.getEnvironmentVariables since we are only running on
Java 1.5 or higher now
+
Changes from Ant 1.8.4 TO Ant 1.9.0
===
Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java?rev=1476822r1=1476821r2=1476822view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java
(original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Execute.java Sun
Apr 28 19:53:25 2013
@@ -38,7 +38,6 @@ import org.apache.tools.ant.taskdefs.con
import org.apache.tools.ant.taskdefs.launcher.CommandLauncher;
import org.apache.tools.ant.types.Commandline;
import org.apache.tools.ant.util.FileUtils;
-import org.apache.tools.ant.util.JavaEnvUtils;
import org.apache.tools.ant.util.StringUtils;
/**
@@ -109,14 +108,9 @@ public class Execute {
if (procEnvironment != null) {
return procEnvironment;
}
- if (JavaEnvUtils.isAtLeastJavaVersion(JavaEnvUtils.JAVA_1_5)
- !Os.isFamily(openvms)) {
+ if (!Os.isFamily(openvms)) {
try {
- @SuppressWarnings(unchecked)
- final MapString, String cast = (MapString, String)
System.class
- .getMethod(getenv, new Class[0])
- .invoke(null, new Object[0]);
- procEnvironment = cast;
+ procEnvironment = System.getenv();
return procEnvironment;
} catch (Exception x) {
x.printStackTrace();
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Request - Native Java Script Support
Hi Anders, Have you tried groovy script? I think groovy is completely compatible with java. That is any valid java code is valid groovy code too. From: Anders Rundgren anders.rundg...@telia.com To: dev@ant.apache.org Sent: Thursday, September 20, 2012 3:11 AM Subject: Request - Native Java Script Support Dear Ant-Team, I am an avid Ant user since more than 10 years back and I'm happy to see how it has progressed! Recently I have begun writing very complex build scripts and found myself craving for a more programmatic solution which using Ant in standard configurations means using JavaScript or writing extensions. In addition, I have also been using .NET tools like NAnt. In NAnt there is no JavaScript support but there is support for native C#. I find C# and Java much better for this purpose than JavaScript so my question is really: Would it be completely unthinkable to add Java as a scripting language? Since Ant already presumes JDK it doesn't sound completely undoable either. Beanshell isn't an active project and I don't see any advantage with Beanshell compared to native Java. Sincerely, Anders Rundgren - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task
I like this feature. I have been using the local task multiple times in my targets to name properties, this enhancement will make my build scripts much more cleaner. From: Ralf rks-...@gmx.de To: dev@ant.apache.org Sent: Sunday, September 16, 2012 1:59 AM Subject: Promotion: Bugzilla 53723 - [Patch] Local task: local by prefix, all local, New: global task Hello, about a month ago I added an enhancement request with patch to ant bugzilla. As there were no feedback on bugzilla, I thought I start a little promotion. The patch adds some functionality to the local task: !-- foo is a local property - like today -- local name=foo / !-- All properties with the prefix local. are local -- local prefix=local / !-- all properties are local -- local/ Additionally the new task global was added to be able to export a property from a scope if all other properties are defined local. !-- all properties are local ... -- local/ !-- ... except the property gFoo -- global name=gFoo / Most important for me (and hopfully others) are the addition to the local task (local-by-prefiy and all-local). The global tasks seems like a logical implication to me. Please have a look at the description for Bugzilla 53723 and the patch. It would be great if this enhancement would be included into ant. Regards, Ralf PS: https://issues.apache.org/bugzilla/show_bug.cgi?id=53723 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Self-referencing Antlib limitation
Isn't it possible to use the ant:current uri to solve this issue, as
described in the link below?
http://ant.apache.org/manual/Types/antlib.html
From: Nicolas Lalevée nicolas.lale...@hibnet.org
To: Ant Developers List dev@ant.apache.org
Sent: Sunday, September 16, 2012 7:21 AM
Subject: Self-referencing Antlib limitation
I was still playing with classloaders and namespaces and antlib import with the
AntDSL, and I encountered an unexpected limitation.
What I found: an antlib which is referencing itself in its definition cannot be
loaded dynamically via an uri other than its antlib one.
This is the case for antunit:
antlib xmlns:au=antlib:org.apache.ant.antunit
[...]
taskdef name=fail
classname=org.apache.ant.antunit.AssertTask/
[...]
macrodef name=assertTrue backtrace=false
attribute name=message default=Assertion failed/
element name=assertion implicit=true/
sequential
au:fail message=@{message}
assertion/
/au:fail
/sequential
/macrodef
And the following doesn't work:
taskdef classpath=antunit.jar uri=urn:antunit
resource=org/apache/ant/antunit/antlib.xml /
(actually, this precise line works, but trying to use any antunit macro will
fail)
I think that the issue is how Ant interpret the namespace declaration in the
antlib definition. In Antunit:
antlib xmlns:au=antlib:org.apache.ant.antunit
When Ant is parsing it, it considers it as an antlib to be resolved later,
whereas it should detect that this is the canonical uri of the antlib it is
parsing, or sort of this, and should use the uri actual used rather than the
antlib one.
The behavior only affect cases where somebody is trying to load two different
versions of the same antlib. This is some quite edge case, but do we agree this
is an issue ?
I have committed a test case to see it in action. See r1385269. To run it,
rename first broken_testURI to testURI in
src/tests/antunit/taskdefs/taskdef-antlib-test.xml.
I had a quick look to how to fix it. As far I can tell, the best way to do it
is to:
* in Definer.loadAntlib(ClassLoader, URL), make the createAntlib aware of the
resource it was loaded from, and try to build an antlib uri from that.
* in Antlib.createAntlib(), let the projecthelper parse the file to an unknown
element with the 'incorrect' uri. But then make a deep lookup in the tree of
UnknownElements and change everything that needs to be changed.
It seems not trivial.
Let me know what you think.
Nicolas
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: controlling ClassLoader when programmatically invoking Ant
So this time I actually did this. I created this parentless ClassLoader and created a Project object from it. And what happened? The moment I tried to assign this object to a Project variable, I got a ClassCastException: org.apache.tools.ant.Project cannot be cast to org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. I think to prevent class-cast issue, you should first create a class with just a static main method, then use the parentless class loader to create an instance of this class and invoke its main method through reflection. All the ant related code should be then written in then main method of the class that you created. The reason you are getting the class-cast exception is because you are creating the Project object using say classloaderA and then trying to access that object from a class that was loaded from another classloader. From: Mitch Gitman mgit...@gmail.com To: Ant Developers List dev@ant.apache.org Sent: Saturday, July 21, 2012 6:16 PM Subject: Re: controlling ClassLoader when programmatically invoking Ant Quick update for anyone who's curious. I'd forgotten that I'd asked much the same question on the ant-user list back on May 31. This was back when the contamination of the child classpath with the parent classpath was literally causing the tests to fail. And same as with this thread, Nicolas L. was kind enough to respond. See thread, example of correctly consuming an Ant project programmatically. What's funny (and sad in a way) is that today I went down much the same path I had laid in the earlier thread without even recollecting that thread. Here's what I wrote earlier: *** The one way I may have to tweak this ... is to do: new URLClassLoader(jars, null); Passing null for the extra ClassLoader argument obviates the possibility of the parent classloader creeping in. *** So this time I actually did this. I created this parentless ClassLoader and created a Project object from it. And what happened? The moment I tried to assign this object to a Project variable, I got a ClassCastException: org.apache.tools.ant.Project cannot be cast to org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. I also tried just calling Project.setCoreLoader() with this URLClassLoader, but that didn't change the way the Ivy JAR and such were being loaded. At this point, I can think of a few ways to address this problem: 1. Create a parent ClassLoader just for all the Ant libraries and put JUnit itself and the entire test classpath in a child classloader. 2. Run the Launcher class with the sandboxed ClassLoader and have a build listener and build logger write the messages and out/err to the filesystem. Then to do the assertions, read the files after the fact. 3. Obtain an Object instance rather than a Project instance and use reflection to call the few methods I have to call on it. #1 scares me! #2 is defeating much of the purpose of doing all this programmatically. #3 ain't pretty, but so far it seems doable. On Sat, Jul 21, 2012 at 9:33 AM, Mitch Gitman mgit...@gmail.com wrote: Nicolas, thanks. I was one class off. I was looking at Main and AntMain when I should have been looking at Launcher. Seeing the type names and the main method threw me off. And this corroborates my brief follow-up that I could be doing something with URLClassLoader. Better for me to try to leverage Launcher though than reinvent that wheel. Let me see how far I get with that. I do have to take issue with the one point you make: But If I were you, I wouldn't bother trying to mimic Ant classloading in a unit test. The important thing is to be sure that you run against the expected version of Ant and Ivy. First, this is not a unit test. It's an integration test or a functional test, and if it doesn't emulate the real-life behavior in the wild, then what use is it? Even if we are treating this as a unit test, you can't really say that inadvertently picking up everything in the parent ClassLoader is the equivalent of mocking or stubbing services and components as one normally does when creating pure unit tests. Consider that there could be a ton of classes in the IDE's ClassLoader that have nothing whatsoever to do with the Ant Project being executed. And this brings me to my last concern. I have already encountered a problem where some static functionality in some superfluous classes in the IDE-inherited ClassLoader was causing the JUnit-invoked Project build to fail. Even so, to my mind, the uncontrolled success I'm seeing now is no less troubling than the uncontrolled failure I was seeing then. If you're a biologist conducting an experiment, you don't want to find out your cultures were growing only because the Petri dish got contaminated. On Sat, Jul 21, 2012 at 6:10 AM, Nicolas Lalevée nicolas.lale...@hibnet.org wrote: Hi Mitch, Le 21 juil. 2012 à 07:37, Mitch Gitman a écrit : Technically, this
Re: controlling ClassLoader when programmatically invoking Ant
I'll probably have to see some code to understand what's going on, but reflection will prevent classcast exceptions when accessing methods of a class loaded from a different class loader. From: Mitch Gitman mgit...@gmail.com To: Ant Developers List dev@ant.apache.org Sent: Sunday, July 22, 2012 8:52 AM Subject: Re: controlling ClassLoader when programmatically invoking Ant Right, what you describe falls under the #1 option I'd mentioned: 1. Create a parent ClassLoader just for all the Ant libraries and put JUnit itself and the entire test classpath in a child classloader. Considering that the code in question consists of JUnit tests that I WANT to run from within an IDE and that I NEED to run from Ant, together with producing the customary reports, this could get complicated pretty fast. Right now, I'm pursuing my option #3, the complications for which are: * Creating a URLClassLoader that uses a scaled-down analog to the Launcher URLClassLoader. * Deploying a JAR containing nothing but the custom BuildListener and BuildLogger to Ant lib. * Accessing the Project and custom BuildListener and BuildLogger using strictly reflection in the Ant test runner code. On Sun, Jul 22, 2012 at 5:27 AM, Vimil Saju vimils...@yahoo.com wrote: So this time I actually did this. I created this parentless ClassLoader and created a Project object from it. And what happened? The moment I tried to assign this object to a Project variable, I got a ClassCastException: org.apache.tools.ant.Project cannot be cast to org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. I think to prevent class-cast issue, you should first create a class with just a static main method, then use the parentless class loader to create an instance of this class and invoke its main method through reflection. All the ant related code should be then written in then main method of the class that you created. The reason you are getting the class-cast exception is because you are creating the Project object using say classloaderA and then trying to access that object from a class that was loaded from another classloader. From: Mitch Gitman mgit...@gmail.com To: Ant Developers List dev@ant.apache.org Sent: Saturday, July 21, 2012 6:16 PM Subject: Re: controlling ClassLoader when programmatically invoking Ant Quick update for anyone who's curious. I'd forgotten that I'd asked much the same question on the ant-user list back on May 31. This was back when the contamination of the child classpath with the parent classpath was literally causing the tests to fail. And same as with this thread, Nicolas L. was kind enough to respond. See thread, example of correctly consuming an Ant project programmatically. What's funny (and sad in a way) is that today I went down much the same path I had laid in the earlier thread without even recollecting that thread. Here's what I wrote earlier: *** The one way I may have to tweak this ... is to do: new URLClassLoader(jars, null); Passing null for the extra ClassLoader argument obviates the possibility of the parent classloader creeping in. *** So this time I actually did this. I created this parentless ClassLoader and created a Project object from it. And what happened? The moment I tried to assign this object to a Project variable, I got a ClassCastException: org.apache.tools.ant.Project cannot be cast to org.apache.tools.ant.Project. So it's sort of a chicken-and-egg problem. I also tried just calling Project.setCoreLoader() with this URLClassLoader, but that didn't change the way the Ivy JAR and such were being loaded. At this point, I can think of a few ways to address this problem: 1. Create a parent ClassLoader just for all the Ant libraries and put JUnit itself and the entire test classpath in a child classloader. 2. Run the Launcher class with the sandboxed ClassLoader and have a build listener and build logger write the messages and out/err to the filesystem. Then to do the assertions, read the files after the fact. 3. Obtain an Object instance rather than a Project instance and use reflection to call the few methods I have to call on it. #1 scares me! #2 is defeating much of the purpose of doing all this programmatically. #3 ain't pretty, but so far it seems doable.
Re: Creation of a new ivy resolver
Reply to Ant Developers List From: Nicolas Lalevée nicolas.lale...@hibnet.org To: Ant Developers List dev@ant.apache.org Sent: Friday, May 25, 2012 10:33 AM Subject: Re: Creation of a new ivy resolver Hi Adrien, I just saw your patch in IVY-1352. So you found out that jira is the way to go, cool :) About the submission, given the size of the patch, when uploading your patch, you should check the button Grant license to ASF for inclusion in ASF works. You should also remove the copyright notices in the header of the files. So it would clear the legal work. About the technical details, we'll discuss it in the jira issue. cheers, Nicolas Le 24 mai 2012 à 10:19, Adrien Lecharpentier a écrit : Hello, I create a new resolver in Ivy and would like to integrate it into the official source code repository. This new resolver is using a CUDF format to describe the dependencies of a module. This description file is generated by a server. The aim is to have a server side dependency resolution, the client site is onyl about to download the description file, parse it and use information it contains. I used a fork of the github repository, work on a separate branch but I integrate the changes you've done on trunk. How can I proceed to give you the source code ? Thanks, -- Adrien Lecharpentier - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ant 1.8.4
Hi Stefan, Could you please include 52706 to this release. I have already attached a patch for 52706. We had a discussion about this a while back and couldn't put it into 1.8.3 because it was too late for the release. Thanks Vimil From: Stefan Bodewig bode...@apache.org To: dev@ant.apache.org Sent: Tuesday, May 22, 2012 12:12 AM Subject: Re: [VOTE] Release Ant 1.8.4 On 2012-05-22, Stefan Bodewig wrote: I would like to release Ant 1.8.4. Ant 1.8.4 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/ant/ The tag is here: http://svn.apache.org/repos/asf/ant/core/tags/ANT_184/ +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Regarding exec task
No problem, In the mean time I will use a locally modified version of ant for the build. Thanks Vimil From: Stefan Bodewig bode...@apache.org To: dev@ant.apache.org Sent: Wednesday, February 22, 2012 8:35 AM Subject: Re: Regarding exec task On 2012-02-21, Vimil Saju wrote: When you get a chance could you look at the patch for the below issue? That's Bugzilla issue 52706, right? Unfortunately I didn't have the time to review it, yet. I really would like to see this make into ant 1.8.3 release. If it hadn't been for the regression 1.8.3 would be out there already. I really only want to address the single issue, cut the release and then go on after that. I understand this may be unsatisfying and can only promise to look into it soon after preparing the release so it'll end up in whatever comes after 1.8.3. Sorry Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Regarding exec task
Thanks Stefan, Your help is very much appreciated. Would using a custom CommandLauncher make it possible for all the built-in ant tasks that support fork attribute to use it. I was thinking of an approach similar to how ant allows property expansion to be customized. By just adding our own custom PropertyHelper we can change how properties are expanded globally. If we have something like that for processes too, it would be great. I'd like to write a patch for this if possible, but I'd like to know the best way to implement it, without breaking anything else. My idea was to provide something like ProcessHelper class that can be stored as a reference in the project. The Execute class then calls this class to get an appropriate Process implementation. This ProcessHelper class should then have the ability to provide a default Process implementation as well as a mechanism to delegate process creation to a user-defined class. Thanks again. Vimil From: Stefan Bodewig bode...@apache.org To: dev@ant.apache.org Sent: Tuesday, February 14, 2012 4:46 AM Subject: Re: Regarding exec task On 2012-02-12, Vimil Saju wrote: So I thought of somehow extending the 'Execute' class of ant to use the functionality of this 3rd party library, but I find that its difficult if not impossible to extend this class. It has certainly not been designed for this, no. Is it possible to make the Execute class in ant extensible so that it becomes possible to plugin our own implementation of Process class. If you had a way to provide your own CommandLauncher then you could wrap Execute's default choice with your own implementation and return a Process class of your liking. This is not possible today, but I'm testing whether this would be enough for you. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Regarding exec task
Hi, I noticed that on windows, if I use the exec task to run a batch script which in turn starts other processes then if kill ant then the sub-processes created by the batch script still continues to run. I did some research on google and found that the default java implementation of Process.destroy does not kill the child processes created by a process on windows. I also found that there are some third party libraries like jvnet that provide the capability of killing all processes created by a process on windows. So I thought of somehow extending the 'Execute' class of ant to use the functionality of this 3rd party library, but I find that its difficult if not impossible to extend this class. I can't find a way to provide my implementation of Process class that does something different when its destroy method is called. Other core tasks such as java task directly create an instance of the 'Execute' class which makes it difficult to globally change how a forked process is destroyed within ant. Is it possible to make the Execute class in ant extensible so that it becomes possible to plugin our own implementation of Process class. Thanks Vimil
