Date: 2004-03-15T02:03:18 Editor: 130.89.169.128 <> Wiki: Gump Wiki Page: FrequentlyAskedQuestions URL: http://wiki.apache.org/gump/FrequentlyAskedQuestions
no comment Change Log: ------------------------------------------------------------------------------ @@ -34,3 +34,52 @@ '''A:''' get in contact with the developers of your prerequisite that is failing to build and ask them to do something about it. If the problem is a mismatch between the project's build system and the gump descriptor, you'll often have access to the descriptor, and you can change that yourself (still get in contact with the developers and tell them that you changed things, and encourage them to try and do that themselves next time). Another, dirty, measure to consider is to check a jar into your project's cvs module, and depend on that. This is bad, because you are removing all the benefits of continuous integration: you won't be aware of the changes to other projects that will break your own. Only do this is a temporary measure, and only do it when there is no other way to "debug" your gump problems. + += Uncategorized = + + '''Q: Which version of Ant (or JUnit or log4j or...) does Gump use?''' + + '''A:''' The latest from cvs (as of the instant of the Gump run). + + '''Q: Gump is building the latest version of everything? That could never work, could it? How can you debug anything when you have so many variables to deal with?''' + '''A:''' 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. + + 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. + + '''Q: I've just got a "nag" e-mail about a failure...what should I do about it?''' + '''A:''' This question deserves it's own [http://gump.apache.org/nagged.html page]. + + '''Q: I've got a fix, how do I get Gump to pick it up?''' + '''A:''' Check it into cvs. + + '''Q: I checked in a fix, how do I know if Gump picked it up?''' + '''A:''' On the build log, click on the link marked cvs. It will tell you when the latest cvs update or checkout was performed and what source files were obtained in the process. + + '''Q: How do I get nagging to stop (or start)?''' + '''A:''' If there is consensus on your project, send an e-mail to [EMAIL PROTECTED] letting us know what the outcome was, and it will be respected. + + '''Q: My project depends on a specific version of a dependency, how can I get Gump to use that version?''' + '''A:''' you can check a jar into your project's cvs module, and depend on that. This is bad, because you are removing all the benefits of continuous integration: you won't be aware of the changes to other projects that will break your own. Only do this is a temporary measure, and only do it when there is no other way to "debug" your gump problems. If you do this, expect some raised eyebrows...the gump community will want you to make sure this really is a temporary measure. That said, here's how you do it. + + 1. Check a jar into your project's CVS module. Example: the jar is in the cvs module commons, for subproject foo, named commons/foo/lib/commons-bar-1.4-dev.jar + 1. Create a project descriptor for that jar. In this case, you need to probably need to add the descriptor to the descriptor for the commons module, commons.xml. It looks pretty much like a normal descriptor, except that there's no {{{<ant/>}}} or {{{<maven/>}}} tag: + + {{{ + <!-- !!!don't use this one!!! + This is a temporary measure until commons-bar's build system refactoring + is complete, on which John Doe and Mary Poppins are working... --> + <project name="commons-foo-commons-bar-1.4-dev"> + <package>org.apache.commons.bar</package> + <jar name="foo/lib/commons-bar-1.4-dev.jar"/> + </project> +}}} + + + '''Q: 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?''' + '''A:''' The gump cvs repository 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). + + '''Q: How do I get a project to be added to Gump? Must it be an Apache project?''' + '''A:''' Send an e-mail (preferably a patch) to [EMAIL PROTECTED] 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 cvs and that it be buildable in an OS independent manner. + + '''Q: Shouldn't the project definitions for a project be kept within the project itself?''' + '''A:''' That's supported too, as long as your project supports viewcvs or equivalent. Simply put the URL of the project definition in the gump profile. However, if you are an ASF committer, why not consider leaving it in the gump cvs repository, that way others can also help out too? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
