On 9/12/05, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > From: "Phil Steitz" <[EMAIL PROTECTED]> > > 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>
That is a mystery to me. The 1.9.2 version looks like it should work to me, and it does if you remove the if test. Could be a bug in the site.jsl. Maybe someone "jellier than me" can explain this. 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 <http://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. That is a good point. The sample maven.xml.sample in commons-build does the copy as part of the build, but you are correct that commons-site.jslreferences them. 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. Many of them have the maven.xml snippet that does the copy now. > 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. Another good point, though I would think it a not too unreasonable expectation that the "classic" style would not change much from version to version. IIRC, commons-site.jsl was created during the pre-1.0 release days when the style sheets were changing a lot. I suggested using 1.8-1.9 as a measure of how "stable" the classic L & F is. 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. That is one way to solve the problem (at least part of it), but I don't see a simple automated way to ensure this. It might not be a bad idea to maintain a set of commons-wide plugin version dependencies and even add these to commons-build.xml so that running the main site build would update them all. One of the problems with keeping the custom commons-site.jsl is maintaining it as maven and the plugins change. I tried to update if for 1.9+ and ended up breaking pre-1.9 builds. Having a iong mess of jsl to pore through each time xdoc does a release is not a happy state. I am happy to do what I can to try to keep things going and to get us through the current mess, but I am by no means a jelly, jsl, or css expert and unless others with more expertise are willing to take on maintaining this stuff, I think that we need to rethink how the jsl, stylesheets and and menus work. Phil Niall > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
