Hi Denis, Good job on the skin - I added an m2 build to Validator using it and looks great to me - I've published the m2 generated site for Validator here:
http://people.apache.org/~niallp/validator-m2/ I can't see any problems with the skin - but noticed the following site issues which look like maven plugin features/bugs: 1) Maven changes absolute URLs specified in site.xml to relative URLs. This isn't a problem for the web sites - but components (like validator) that include them as docs in the distro it means that the breadcrumbs (Jakarta and Commons) and links to previous versions JavaDocs that are only on the site no longer work. 2) The "changes" report doesn't seem to like content that contains markup - it seems to split out the markup into a separate report - m1 and m2(x2) changes reports are here for comparison: http://jakarta.apache.org/commons/validator/changes-report.html http://people.apache.org/~niallp/validator-m2/changes-report.html (markup removed) http://people.apache.org/~niallp/validator-m2/changes.html (removed markup) 3) Validator has a custom issue-tracking page - which seems to cause the site plugin to omit it from the "project information" menu and page: http://people.apache.org/~niallp/validator-m2/project-info.html If I delete the custom version - then m2 generates one and includes it on both the above. more comments inline below... On 1/7/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Here's a status report on how far I have gotten. The sandbox parent is finished. I have added a bunch of reports to it that seems logical, at least to me, for all components. These are: - Cobertura (test coverage) - Javadoc - JXR (cross reference for sources) - PMD - Surefire (test results) - JDepend (metrics) - Taglist (list things left to do)
One thing I noticed recently with Cobertura is that it includes some JavaScript files with various (GPL+ other) licenses - maybe we should switch to JCoverage instead: http://tinyurl.com/ynbjge
The individual components have at least the reports they have in their M1 sites, with these exceptions:
Sounds like a good plan - how will this be handled for "proper" components - is commons-parent the right place to put them or do we need a proper-parent pom?
- i18n is missing JCoverage, but Cobertura does the same thing - Id and Proxy are missing Clover, but Cobertura does the same thing - All are missing JavaDoc Report, JavaDoc Warnings Report and Link check, which does not exist in M2 - All are missing Project License which is available in another place in M2 Some components have their own reports as well. These didn't seem like something suitable for all components. These reports are: - Checkstyle (5 component) (requires a configuration file) - Changelog (3 component) - Changes (1 component) (requires a changes.xml file) - FindBugs (1 component) Still to do: - I haven't been able to get the logo in the upper right corner to work simultaneously for M1 and M2. This affects I18n, Id and Proxy.
I fixed this in Validator by copying the logo to site/resources/images and including a <bannerRight> element in site.xml
- Id has test failures in M2, which I haven't been able to solve. I temporarily added a configuration so that the build succeeds even if there are test failures. - Id has a downloads page that refers to an M1 report. Need to decide how to deal with that. Can't have M1 and M2 working at the same time for this one.
I assume you mean cvs-usage.html? While id is in the sandbox we could copy the cvs-usage.html to source-repository.html in the maven.xml and refer to source-repository.html on the downloads page. Once its out of the sandbox I would remove the downloads page altogether and replace it with the standard downloads_commons-id.cgi Alternatively just delete the downloads page now. Thanks again for doing all this Niall
- Publish staged sites so that you can all see what it looks like. Dennis Lundberg wrote: > Hi > > Before I dive head-first into this I thought I'd ask first. I'd like to > unify the M2 generated sites for all sandbox components, by making use > of commons-skin. This would mean: > > 1. Make various changes to the sandbox-parent, which is currently > located in sandbox-trunk: > - Remove local style rules > - Remove stuff that is inherited from commons-parent, most notably > maven-classic-skin > > 2. Change pom.xml and site.xml for many sandbox components > - Make sure inheritance is correct > - Align navigation structure > - Remove stuff that is inherited from sandbox-parent > > 3. Re-publish the sites for all sandbox components > - Do "mvn site:deploy" for all sandbox components > - Would like to move sandbox-parent to its own directory in SVN > - If we feel that it's necessary at this time: release commons-skin, > commons-parent and sandbox-parent > > > Does this sound OK to you? > -- Dennis Lundberg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
