Community
Participate
Working Groups
Please ensure that an inputhandler is being provided for external ANT tasks; currently, the ANT build will request the input from stdin, which is not possible on the current console, rather than popping up an appropriate dialog as it would when run from within the Eclipse VM.
Verified on Windows as well.
The inputhandler that is used when the Ant build occurs within Eclipse is build using the Eclipse JFace support and therefore cannot easily be used when run in a separate VM. Note that you can provide any inputhandler your wish by specifying - inputhandler. An example of one that would work is the org.apache.tools.ant.input.PropertyFileInputHandler provided with Apache Ant. It would be good for Eclipse to provide a UI component that worked by default.
Either that, or for the console to allow me to type the results in - I care not which, really. The leaks in some ANT tasks are still killer enough, at least in this version, that without running it external to the VM, that for some of the larger build/deploy construction, you pretty much have to close eclipse after doing a build/deploy and relaunch it. Pushing off to an external VM would be the easiest way for me to eliminate this problem. I can't quite find where I'm meant to use the -inputhandler flag at; VM options? Regardless, use of propertyfileinputhandler is inappropriate during deploy operations where the user is being asked to supply passwords for access to the live service.
-inputhandler would be passed on the Ant main tab in the arguments tab (as it is an Ant argument) I understand that the propertyfileinputhandler is not always appropriate but it is the only current easy workaround. You can use your own implementation of input handler as well. You would add the required JARs to the Ant runtime classpath and then use -inputhandler to point to your implementation.
*** Bug 48223 has been marked as a duplicate of this bug. ***
Would still be really, really nice to see 'external' build become the standard, supported build type for an ant build. Depending on ANT and various ant tasks to *not* leak just doesn't seem wise; not when so many do. :)
Gregory, I agree with you. In Eclipse builds newer and including M5 (see bug 45899) the default for a new Ant launch configuration is for the build to occur in a separate VM. We still have some issues that include this one that currently are planned to be addressed in 3.0 to make the support for external builds be equivalent to the level of support for builds in the same VM.
*** Bug 52722 has been marked as a duplicate of this bug. ***
I was hoping this would be resolved w/ Eclipse 3.x M8, but unfortunately it was not. Will this be addressed for the final release of version E3?
My current plan if time permits is to provide a SWT input handler that the user can specify using the -inputhandler option if they so desire.
*** Bug 62730 has been marked as a duplicate of this bug. ***
Consider this comment as additional support for supplying an inputhandler for builds run in an external JVM. Not having one is a reduction in functionality from 2.1*. I'm not going to be able to move projects from a 2.1 to 3.0 environment without changing their content as it is now.
Correction on my previous comment -- this is __not__ a reduction in functionality from 2.1. (I was mis-remembering what happens in our build scripts -- the junit tests are run in a new JVM, as controlled by the junit task). I can't find in my configuration notes anywhere that I changed a preference for Ant to run in a separate JVM, and I can't find a global preference to set for it. So I'm guessing that something caused it to default to running in a new JVM, which I didn't notice until a problem came up. Assuming I'm not missing something somewhere, defaulting to "Run in the same JRE as the workspace" would make migration from 2.1 to 3.0 more seamless. And I still think that providing a default inputhandler for builds in a separate JVM would be a great help.
Thanks for the clarification Dennis. There is no global setting for VM...this is a deferred feature request (bug 38263). As of M5, new launch configurations will default to run in a separate VM (this was requested by the community mostly to workaround the leakage in some Ant tasks etc.). I am still trying to get an input handler available that users could specify using -inputhandler. Of course this is a great opportunity for community help :-)
Due to running out of time this input handler will not ship with 3.0. But it should be a priority shortly after 3.0 and I see no reason that 3.0 users will not be able to grab the definining JAR file, add it to the Ant runtime classpath and specify the correct input handler to use the new functionality.
*** Bug 66243 has been marked as a duplicate of this bug. ***
*** Bug 68461 has been marked as a duplicate of this bug. ***
*** Bug 71104 has been marked as a duplicate of this bug. ***
*** Bug 73173 has been marked as a duplicate of this bug. ***
*** Bug 75848 has been marked as a duplicate of this bug. ***
reopening for 3.1
*** Bug 77319 has been marked as a duplicate of this bug. ***
Some initial work: changes to the remote ant JAR external tool builder SWTInputHandler created buildRemoteInputHandlerJAR.xml created altered buildRemoteExtraJAR.xml to exclude the input handler from this JAR
Changes to: IAntUIConstants to provide the attribute for whether to set the input handler. AntMainTab to provide the UI on whether to set the input handler (default to true) AntLaunchConfigurationMessages.properties: new NLS strings ContributedClasspathEntriesEntry: to added the SWT.jar to the classpath for separate VM based on the user configuration AntLaunchDelegate: to set the java.library.path to include the folder containing the swt dlls and to set the remote input handler name. Changes to the two InternalAntRunners to support the notion of not setting an input handler (and fixed a bug with not removing a system property when set to not allow input)
Please verify DarinW. Note that I plan to make a JAR of the inputhandler available via the Eclipse Ant pages. With some configuration by the user this inputhandler will work with 3.0.
Currenly a problem on GTK. Logged 77519
Verified.
I have made a patch available at: http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-ant- home/index.html This patch does not provide the level of support of 3.1M3 but the patch and the instructions will allow a user to use the supplied input handler on 3.0.1
*** Bug 89812 has been marked as a duplicate of this bug. ***
