You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Report a Bug

Wicket manages bug reports via the Apache Jira site: http://issues.apache.org/jira/browse/WICKET

It requires you to register with the site, to avoid spamming, and attribute credit where its due. It's relatively painless. Much harder is writing a clear and concise and bug report.

Etiquette for a bug report is:

  1. Always search for an existing bug report about the issue before adding your own. This can be tricky, but several duplicate bug reports just cause an administration headache for developers. If in doubt you can always post the details of the bug to the mailing list, and wait to be asked to submit a bug report by a dev. But the jira search functionality is pretty good, so do have go.
  2. Be clear and concise in your language. Wording a short but useful summary, with a description that contains all the steps leading up to the error plus any extra circumstantial evidence, is not always easy, but its vital to getting the issue resolved, and really valuable.
  3. Watch the bug. The developers may ask you for more information via the issue comments, so its good practices to check in on the issue whilst its still open.
  4. Don't be shy of maintaining the issue. If you find its a duplicate of some other issue that was reported before yours, then mark it as a duplicate, and watch the original. If you get more info on the bug, add it as a comment. If it doesnt get noticed by a dev, try submitting a quickstart or better still a patch. Ask for it to be reviewed via the mailing list.

You will be rewarded with subtle kudos and the bug is much more likely to be fixed promptly.

Build a Quickstart

See http://wicket.apache.org/quickstart.html

The maven command provided there is the quickest way to get a working Wicket project that you can use to clearly demonstrate a bug.

Once you have an example that shows the minimum conditions under which the issue occurs, then you can zip up the project and attach it to the relevant issue.

When a Wicket dev asks you to submit a quickstart, that is what they mean.

That is far more useful than posting reams of your application code and telling everyone it doesn't work. The former will help diagnose the problem, the latter will mainly get you abused on the mailing list.

Submit a patch

This is the most involved, but the most rewarding route (wink).
In a nutshell this involves:

  • Checking out the Wicket source code from the Subversion repository.
  • Building it via mvn or IDE plugin.
  • Proving the bug exists, either via a Quickstart, or writing a unit test.
  • Submitting your fix as a Subversion patch file.

Checking out Wicket from Subversion

see: http://wicket.apache.org/building-from-svn.html

Building Wicket

Proving a bug exists

Submitting a patch

  • No labels