This is an RFE. A task should be able to place limits on the resources used that apply to all tasks invoked by that task. Intervening JVM and other process creation shouldn't rescind these limits. Here's the scenario that this addresses. Imagine a large number of projects. Each one is in a sibling directory. A top-level build.xml executes the build.xml of each project. The resource limits come into play, so that each project build can be confined to its own directory and limited to a fixed time period. Without the resource limits, the top-level build has to trust each project build to complete in a timely fashion and won't mess with its siblings stuff. While there are platform specific mechanisms to accomplish this, there doesn't seem to be a platform independent way of doing this in Ant.
Could you elaborate on which resources, in addition to time (see ant-contrib's limit task), you would expect to be controlled here?
"Could you elaborate on which resources, in addition to time (see ant-contrib's limit task), you would expect to be controlled here?" Basically everything that you might limit by a SecurityManager Permission or a security policy. http://java.sun.com/j2se/1.5.0/docs/guide/security/permissions.html http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html Security conscious companies and Ant service providers ("build farms" and "test farms") will want to restrict access to files, sockets, native code, external executables, AWT, audio, etc... There are basically two scenarios that this provides solutions to. One build on a shared build server could be "arbitrarily incompetent". Such a build could attempt to delete all of the files the server in an attempt to clean-up after itself, accidentally run against production machines with test data, and on and on. All of these things are also true for a build that is actually malicious. This is just a mechanism to ensure that a build "can't hurt anything else" outside of some set of permissions it has been given.
Have you played with the <permissions> element on the <java> task? It might be possible to apply these to <ant> and friends as a start here. Although they currently only function in-VM, I can't see why we couldn't apply them to a forked VM.
Matt, I haven't tried modifying Ant to implement the things you suggest. If a security manager allows the use of Runtime.exec(), then there is a mechanism to bypass it entirely. If it doesn't allow the use of Runtime.exec(), then it can't spawn new JVMs. This may not be realistically solvable without deferring to an implementation of the JSR-121 Isolate API. Presumably JSR-121 implementations will handle security managers transitively, so that their restrictions can't be trivially escaped. Would there be any resistance to adopting the JSR-121 API to launch JVMs? This would only be done after the JSR is final and implementations are available for all environments Ant supports. http://jcp.org/aboutJava/communityprocess/pr/jsr121/index.html
(In reply to comment #4) > Matt, I haven't tried modifying Ant to implement the things you suggest. > If a security manager allows the use of Runtime.exec(), then there is a > mechanism to bypass it entirely. If it doesn't allow the use of Runtime.exec (), > then it can't spawn new JVMs. Good points. > This may not be realistically solvable without > deferring to an implementation of the JSR-121 Isolate API. Presumably JSR-121 > implementations will handle security managers transitively, so that their > restrictions can't be trivially escaped. Would there be any resistance to > adopting the JSR-121 API to launch JVMs? This would only be done after the JSR > is final and implementations are available for all environments Ant supports. > http://jcp.org/aboutJava/communityprocess/pr/jsr121/index.html It looks as though this spec would, should it come to fruition, be a core piece of a future release of Java. At that time there should be no reason we cannot support it, although detection of availability would probably have to be accomplished via reflection (this is commonly the case with newer language features in Ant).