src/site/fml/faq.fml

<?xml version="1.0"?>

<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
-->

<faqs title="Frequently Asked Questions">
  <part id="general">
    <title>General</title>
    <faq id="maturity">
      <question>How mature is it?</question>
      <answer>
        <p>The code was ported from <a href="http://ant.apache.org/">Apache Ant</a> and extensively
           tested on various platforms. So there is no reason not to use it and it is very likely
           better than any home-grown library.</p>
      </answer>
    </faq>
    <faq id="complex-quoting">
      <question>How do I create a complex command line using single and double quotes?</question>
      <answer>
        <p> It is recommended to use CommandLine.addArgument() instead of CommandLine.parse(). Using
          CommandLine.parse() the implementation tries to figure out the correct quoting using your
          arguments and file names containing spaces. With CommandLine.addArgument() you can
          enable/disable quoting depending on your requirements. Having said that this is the
          recommended approach using Ant anyway. </p>
      </answer>
    </faq>
    <faq id="killing-child-processes">
      <question>Are child processes automatically killed?</question>
      <answer>
        <p> This functionality is largely depend on the operating system - on Unix it works
        mostly and under Windows not at all (see <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4770092">
        Bug 4770092</a>). In terms of stability and cross-platform support try to start your applications directly and
        avoid various wrapper scripts.</p>
      </answer>
    </faq>
      <faq id="gcj-support">
        <question>Does commons-exec support java-gcj?</question>
        <answer>
          <p> Well - one out of 55 regression tests fails. The
            EnvironmentUtilTest.testGetProcEnvironment() test fails because it detects no environment
            variables for the current process but there must be one since we require JAVA_HOME to be
            set. Not sure if this is a plain bug in java-gcj-4.2.1 or requires a work around in
            commons-exec</p>
        </answer>
      </faq>

    <faq id="environment-testing">
      <question>How to test commons-exec on my environment?</question>
      <answer>
        <p> Assuming that you have an environment not listed on the <a href="./testmatrix.html">test
          matrix</a> and want to make sure that everything works fine you can run easily run the
          regression tests. Make a SVN checkout and run 'ant test-distribution' to create the test
          distribution in './target'. On a production box downloading the ready-to-run test 
          distribution might be even more handy (<a href="http://people.apache.org/~sgoeschl/download/commons-exec/">
          http://people.apache.org/~sgoeschl/download/commons-exec/</a>). Unpack the 'zip' or 
          'tar.gz' file and start the tests. Independent from the result we very much appreciate 
          your feedback ... :-)</p>
      </answer>
      <question>Why is the regression test broken on my Unix box</question>
      <answer>
        <p> Please check if the shell scripts under "./src/test/script" are executable - assuming 
          that they are not executable the "testExecute*" and "testExecuteAsync*" test will 
          fail. We try very hard to keep the executable bit but they have somehow the tendency 
          to be lost ... 
        </p>
      </answer>
    </faq>
  </part>
</faqs>