<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
 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.
-->
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
<document>
  <header>    
    <title>Apache Gump - Frequently Asked Questions</title>
  
  	<authors>
  		<person name="Sam Ruby" email="rubys AT us.ibm DOT com"/>
  		<person name="Adam Jack" email="ajack AT sybase DOT com"/>
  	</authors>
  </header>    
<body>

	<section><title>Question: Which version of Apache Ant (or JUnit or Apache log4j or...) does Apache Gump use?</title>
    <p><strong>Answer: </strong>The latest from SCM (as of the instant of the Gump run).</p>
    </section>
    
	<section><title>Question: Gump is building the latest version of everything?</title>
	<p>That could never work, could it?  How can you debug anything when
              you have so many variables to deal with?</p> 
              <p><strong>Answer: </strong>It isn't as hard as it seems.  Getting it to work initially
              was done by incrementally adding one project at a time.  Keeping
              it working is only requires a small amount of effort over a long
              period of time.</p>
              <p>When builds are "mostly" clean and frequent, isolating
              problems is fairly easy.  Rollback projects one by one until the
              problem disappears, and then reapply changes within that project
              one by one until the problem reappears.  I've used this technique
              numerous times to produce test cases and patches to projects
              that I know virtually nothing about their internal design.</p>
     </section>
                
    	<section><title>Question: I've just got a "nag" e-mail about a failure...what
              should I do about it?</title>
    		<p><strong>Answer: </strong>This question deserves it's own
              <link href="nagged.html">page</link>.</p>
    	</section>
    	
      <section><title>Question: I've got a fix, how do I get Gump to pick it up?</title>
    		<p><strong>Answer: </strong>Check it into your source control.</p>
    	</section>
    	
<section><title>Question: I checked in a fix, how do I know if Gump picked it up?</title>
    		<p><strong>Answer: </strong>On the build log, click on the link marked <code>update</code>.  It 
              will tell you when the latest scm update or checkout was 
              performed and what source files were obtained in the process.</p>
    	</section>
    	
<section><title>Question: How do I get nagging to stop (or start)?</title>
    		<p><strong>Answer: </strong>If there is consensus on your project, send an e-mail to
              <link href="mail.html">
              general@gump.apache.org</link> letting us know what
              the outcome was, and it will be respected.</p>
    	</section>
    	
<section><title>Question: My project depends on a specific version of a dependency,
              how can I get Gump to use that version?</title>
    		<p><strong>Answer: </strong>The combinatorics of building each project with distinct
              versions of its dependencies is a bit too much for me to track.
              If the dependent project is undergoing a major revision, and the
              prior version is still actively supported, exceptions may be made.
              Otherwise, feel free to set up your own builds, with or without
              using the codebase of Gump to track the set of dependencies that
              interest you.</p>
    	</section>
              
            <section><title>Question: I've got a change I would like to make to the project
              definition for a project I'm a committer on...how do I get
              the change to be made?</title>
    		<p><strong>Answer: </strong>The 
              <link href="https://svn.apache.org/viewvc/gump/metadata/">
              gump svn repository</link> is open to all ASF committers.
              Simply check it out and commit your changes.  It is highly
              recommended that you build the "gen" target first of the
              provided build.xml in order to verify that your changes
              are syntatically correct.  Don't be scared... this takes
              only a minute and only  requires that you have ant and JDK
              1.4.  (or ant + xerces + xalan + JDK 1.2 or later).</p>
    	</section>

              <section><title>Question: How do I get a project to be added to Gump?  Must it
              be an Apache project?</title>
    		<p><strong>Answer: </strong>Send an e-mail (preferably a patch) to
              <link href="mail.html">
              general@gump.apache.org</link>.  Being Apache related
              (i.e, used by or a consumer of other Apache projects) helps,
              but is not required.  What is important is that your code be
              publicly accessible via a supported SCM and that it be buildable in an
              OS independent manner.</p>
    	</section>
    	
            <section><title>Question: Shouldn't the project definitions for a project be kept
              within the project itself?</title>
    		<p><strong>Answer: </strong>That's supported too, as long as your project supports
              viewcvs or equivalent.  Simply put the URL of the project
              definition in the 
              <link href="https://svn.apache.org/viewvc/gump/metadata/profile/gump.xml?content-type=text/vnd.viewcvs-markup">
              gump profile</link>.  However, if you are an ASF committer, why
              not consider leaving it in the gump svn repository, that
              way others can also help out too?
             </p>
    	</section>
</body>
</document>
