thread at least once before the next rollover occurs

This is OK, since in production, the rollver period is much much
longer than the time it takes to do compression. In our tests however,
this reation does not hold.

The name of the log file nested within .zip archives was incorrectly
set to be that of the tmp file logback creates during
compression. Anders Wallgren reported and posted an appropriate patch
for this problem LBCORE-98.  The nested file is now named after the
zip archive file. Analysis showed that this was an appropriate
strategy in all the cases we considered.

suggested by DAvid Varnes in LBCORE-101

- Adapted TimeBasedRollingWithArchiveRemovalTest so that
dailySizeBasedRollover() no longer fails under certain circumstances,
e.g. when in the last period no size-based rollover occuers. Also
increased the number of ticks per period (more logging calls) and
increased the triggering size (less size-based rollovers for faster
test execution time)

reference/export slf4j by variable.

- editing of filters.html

   http://jira.qos.ch/browse/LBCLASSIC-165

- fixed http://jira.qos.ch/browse/LBCLASSIC-155

  site module useless. Reverting to jar packaging.

54534d77268ae8a00f0848ddb916879c8820ba18 dated October 07, 2009

dated October 22nd

02d29034bbd38dd2a89741f096b1a77372ee5c5d dated October 20, 2009.

http://github.com/cehjohnson/logback/commit/2194ab44141abed25479ec00e4a88b4fc27c4f68
from October 04, 2009

However, the ">" to ">" transformation has been ignored and will continue
to be so in the future.

  from October 02, 2009

- editing bugreport.html and license.html

options which now look less cramped.

- fixed TimeBasedRollingWithArchiveRemovalTest.java which would fail when the
  number of period+currentMonth - maxHistory is placed in the previous year.
- minor editing in license.html