From: "Phil Steitz" <[EMAIL PROTECTED]>
>On 9/11/05, Niall Pemberton <[EMAIL PROTECTED]> wrote:
>>
>> ----- Original Message -----
>> From: "Brett Porter" <[EMAIL PROTECTED]>
>> Sent: Monday, September 12, 2005 2:36 AM
>>
>>
> > I think this option I raised earlier got missed, so I'll repeat here:
>> >
>> > The one option I'd consider is whether it is worth ditching
>> > commons-site.jsl altogether. I have no idea what it adds:
>> > setting maven.xdoc.theme=classic instead looks the same to me (except
>> for
>> the
>> > addition of the the external link icons which can be removed through
>> > CSS). If you'd like me to commit that for commons-math I can.
>> >
>> > Does anyone know what it was meant to do, other than insulate against
>> changes
>> > in the Maven generated site?
>>
>> One thing it does is add the standard commons "About Us" menu before the
>> project menu.
>
> The menus actually come from the xml entities that are (individually)
> referenced from the navigation.xml files.
They do, but including the commons "about us" menu before the component's
menu is in the commons-site.jsl
commons-site.jsl has the following line:
<jsl:applyTemplates select="$nav/body/[EMAIL PROTECTED]'header']"/>
but site.jsl (from 1.9.2) has the following
<x:if select="$nav">
<jsl:applyTemplates select="$nav/body/menu[not(@type) | @type='header']
| $nav/body/search"/>
</x:if>
>> I know that doesn't solve the fundamental problem in the plugin, but
>> > might be the best solution for commons.
>>
>> IMO we would still need have a dependency on a specific xdoc plugin
>> version - otherwise what different components' sites look like could vary
>> depending on what version plugin happened to be installed.
>
> This is the reason that commons-build was created in the first place.
>
> I will do as you suggest above, for the immediate term (create two
versions,
> with notes), this evening.
>
> FWIW, I now recall that the reason that main reason that most of us
decided
> to stop extending the commons-build POM was that it made distribution
> awkward.
>
> I will also have a look at how different things look bet 1.8, 1.9 with
> maven.xdoc.theme=classic. These should not be much different and, if so, I
> think I agree with Brett that the best solution would be to just toss
> commons-site.jsl together, replacing the funny out-links using css or
> something. IIRC, that was the only real complaint.
As I said above, I think Brett was wrong on this - it does include the
commons menu.
As well as the menu, commons-site.jsl also links to the three stylesheets
(tigris.css, maven.css and project.css) at jakarta.apache.org/commons/style,
if there are no local style sheets for the component - 21 out of 34 commons
components use this - the others that have links to their own local copies
appear to be just copying them in from commons-build anyway - including
commons Math (which also has copies of all three in SVN as well). Having
just three copies of the stylesheets for [at the moment, most of] commons
seems like a good idea to me.
I'm not sure if you're talking about tossing commons-site.jsl just for
commons-math or for the whole of commons. Assuming you mean the whole of
commons then at a minimum the menu issue would need resolving and 21
components would need their maven.xml updating to copy the stylesheets. Also
I think you're both missing the point on "insulating" changes to the
standard site.jsl. Just checking 1.8 and 1.9 work OK doesn't resolve the
issue of what happens if the next version of the maven-xdoc-plugin site.jsl
does something different. Potentially different components could have a
different L&F depending on the plugin version used and having got rid of the
mechanims to isolate commons from changes we don't want, we could find
ourselves having to put it back in.
The real issue IMO comes back to needing to ensure that we all use the same
plugin version whatever the decision on which jsl file we use.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
