commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [commons-build] Site build problem
Date Tue, 13 Sep 2005 05:45:57 GMT
On 9/12/05, Niall Pemberton <niall.pemberton@blueyonder.co.uk> wrote:
> 
> From: "Phil Steitz" <phil.steitz@gmail.com>
> 
> 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/menu[@type='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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message