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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
