[Gump Wiki] New: FrequentlyAskedQuestions

[ge...@gump.apache.org]

   Date: 2004-03-15T01:49:35
   Editor: 130.89.169.128 <>
   Wiki: Gump Wiki
   Page: FrequentlyAskedQuestions
   URL: http://wiki.apache.org/gump/FrequentlyAskedQuestions

   no comment

New Page:

= Gump descriptor maintainance questions =

 '''Q: what should I do if a project its build output changes (for example from one to multiple jars or one to multiple maven projects)?'''
  '''A:''' you should update the gump descriptors for the project to reflect the new situation. If this change somehow impacts your project dependees, which are listed for you on

   {{{http://lsd.student.utwente.nl/gump/${module}/${project}.html#Project+Dependees}}}

  then you should probably send them an e-mail explaining the change. Chances are, the project will not only need to update its gump descriptor, but it will also want to change some other aspects of its own build system (for example, update the dependency list in maven's project.xml, or change the jars they keep in CVS).

 '''Q: how do I split a single gump project definition into multiple projects definitions?'''
  '''A:''' create the descriptors for the new projects, and remove the descriptor for the old project. You can keep the old project around as a sort of "delegate" for a while, if you want. For example, if you've split the project {{{commons-foo}}} into two, {{{commons-foo-api}}} and {{{commons-foo-impl}}}, you could change the {{{commons-foo}}} descriptor to something like

  {{{
  <!-- don't use this one!!!
     Migrate to depending on project-api and project-impl instead... -->
  <project name="commons-foo">
    <depend project="commons-foo-api" inherit="jars"/>
    <depend project="commons-foo-impl" inherit="jars"/>
  </project>
}}}

 '''Q: what if my question is not answered here?'''
  '''A:''' write an e-mail to general _at_ gump dot apache dot org. When you receive an answer (which might take a few days), '''''please''''' add the question and the answer to this page (there's an "edit this page" link at the bottom).

 '''Q: can we get access to the build outputs of the gump run?'''
  '''A:''' sorry, but no. We can't simply publish the full gump build tree, because that would be "distribution" of a whole lot of jars and tarballs. That, we cannot do without having humans check the quality and validity of those files, and, in the case of ASF projects, without proper authorities (ie, a PMC) decide the distributable is fit for distribution. What we ''can'' do sometimes is give people shell access to one or more of the machines that run gump. But you'll understand we can't give everyone shell access.

 '''Q: why didn't gump run last night?'''
  '''A:''' probably because someone killed it halfway through. Gump currently has no dedicated hardware on which to run (but a machine is underway), so it runs shared with other tasks on people's home computers and servers. It could also be because one of the gump developers broke gump badly, and introduced an error into a vital part of the system. If you want to be sure, just send an e-mail and ask.

 '''Q: my project hasn't built for months because of prerequisite failures!!! What should I do?'''
  '''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.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org