Niall Pemberton wrote:
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.
Yep, the links will work once the site is published, but it should work
for a staged site as well. This is a known issue:
http://jira.codehaus.org/browse/MSITE-159
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)
I'll take a closer look at this. Unfortunately the M2 plugin is not yet
up to par with its M1 counterpart.
http://people.apache.org/~niallp/validator-m2/changes.html (removed
markup)
I noticed this file too. We need to exclude this file from the M2 site
build. I'll patch a parent pom shortly.
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.
Strange, I'll look into it.
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
I hadn't noticed that. I'll take it up over in Maven land.
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?
Once we settle on a standard set my plan is to move them to the parent
pom. I don't currently see the need for a "proper" 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
Yes, that's the easy way to go. I was hoping that I wouldn't need to
resort to copying stuff in SVN. Some components have the Gimp or
Photoshop source file in SVN as well. These need to go somewhere too.
- 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.
Yes, that's the file I meant. I think we'll just keep it like is for
now. When the M2 site build is finished, we change the page to refer to
the appropriate M2 page. We shouldn't need the M1 site build once we've
switched to M1.
Once its out of
the sandbox I would remove the downloads page altogether and replace
it with the standard downloads_commons-id.cgi
True.
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]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
