On Mar 20, 2006, at 8:07 AM, Fabrizio Giustina wrote:
On 3/20/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
I'm seeing at least the following problems:
[...]
2) The line numbers in the source cross reference reports cause
almost
the entire cross reference file to be modified whenever lines are
added or removed from the source files.
well, that's perfectly normal, if you want to have xref updated with
the latest version of the source code... I don't think this should be
a problem
3) The included execution times in the JUnit test report cause the
entire file to be modified whenever the site is generated.
since execution time can't be perfectly stable across different runs
that's another expected thing...
4) My setup seems to generate the class="a" and class="b" attributes
of generated table rows in a different order than Roy's setup.
That is the random change I was talking about -- it will change the
order even if nothing in the content has changed.
If I remember well, that's probably simply because the total row
number during the site generation is a global variable, so it's enough
to have a single added row in a table that other css classes could
shift....
Then the generator should be fixed to not add class names based on
the number of entries. There are many other ways to code CSS.
All those reports are simply not meant to be checked into a scm
repository... I know that the Apache guidelines tells to "not to
modify files directly in the site directory, but check them into
subversion instead" but I don't think that such recommendation could
apply to files that are totally generated from other sources.
It isn't a recommendation. It is mandatory to have a simple mechanism
that reproduces the exact content that was on the site, so that we can
quickly check for content that has been modified by a crack on www.
Maven site:deploy generates different content every time -- it does
not qualify at all.
One idea was to move these generated files to a staging area and
reproduce from there, but that failed to generate enough volunteers
on site-dev (mostly because people insist on defending forrest or
maven or whatever as the uber-tool instead of just doing the work).
In any case, it is incredibly brain dead to set up automated
instructions in maven so that anyone with a login on apache.org
can ssh the content to the live website. I don't think Maven
would appreciate it if I checked out an old version of their sources
and accidentally ran that command. Unlike most people, I do have the
permissions necessary to wipe out everyone's website on apache.org.
The reports that Maven produces are very useful for a developer to
generate on their own machine. I don't think anyone else should be
subjected to the reports generated on *my* machine, since OS X's
version of java is not what server-side developers care about when
they go looking for problems to fix.
My guess is that the best way to handle this is to use Maven's
version of anakia to generate the site (for developers) but only
deploy a small subset of that to jackrabbit.apache.org (without
the reports, xref, etc.).
....Roy
