Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of phil.steitz@gmail.com designates
 64.233.162.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references;
        b=Se6HOSjp3gPGdtlX6yp98ahhwPQcnLLHjZCvIAB00qrYI8MRkKBW1lbF6rj52rzkijNLGxIoVSVQTzNZpe/1YGixRrfo2mPsJnA9+6z1MfiI6CeeC516uszTUFB7KBAw1RbjVP0M9bg5WFxr1/JI4Hkh0tg2cEfUqgCaDMfHka8=
Message-ID: <8a81b4af05091222456b4a1871@mail.gmail.com>
Date: Mon, 12 Sep 2005 22:45:57 -0700
From: Phil Steitz <phil.steitz@gmail.com>
Reply-To: phil.steitz@gmail.com
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [commons-build] Site build problem
In-Reply-To: <005b01c5b7b6$d7c044c0$0200a8c0@DELL1800>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_15647_10137367.1126590357912"
References: <1c661f2f05090118553501ffbe@mail.gmail.com>
	 <8a81b4af050911133060619f40@mail.gmail.com>
	 <4324A4E6.1040007@apache.org>
	 <00c601c5b728$9e0304e0$0200a8c0@DELL1800>
	 <8a81b4af0509111634576ff555@mail.gmail.com>
	 <16d6c6200509111754d8c3f17@mail.gmail.com>
	 <4324DBB0.2090003@apache.org>
	 <018801c5b750$6314c760$0200a8c0@DELL1800>
	 <8a81b4af050912062126cf364@mail.gmail.com>
	 <005b01c5b7b6$d7c044c0$0200a8c0@DELL1800>

------=_Part_15647_10137367.1126590357912
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 9/12/05, Niall Pemberton <niall.pemberton@blueyonder.co.uk> wrote:
>=20
> From: "Phil Steitz" <phil.steitz@gmail.com>
>=20
> They do, but including the commons "about us" menu before the component's
> menu is in the commons-site.jsl
>=20
> commons-site.jsl has the following line:
>=20
> <jsl:applyTemplates select=3D"$nav/body/menu[@type=3D'header']"/>
>=20
> but site.jsl (from 1.9.2) has the following
>=20
> <x:if select=3D"$nav">
> <jsl:applyTemplates select=3D"$nav/body/menu[not(@type) | @type=3D'header=
']
> | $nav/body/search"/>
> </x:if>


That is a mystery to me. The 1.9.2 version looks like it should work to me,=
=20
and it does if you remove the if test. Could be a bug in the site.jsl. Mayb=
e=20
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=20
> 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=20
> commons
> components use this - the others that have links to their own local copie=
s
> 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=
=20
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.=
=20


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=20
> 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=
=20
> 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=20
expectation that the "classic" style would not change much from version to=
=20
version. IIRC, commons-site.jsl was created during the pre-1.0 release days=
=20
when the style sheets were changing a lot. I suggested using 1.8-1.9 as a=
=20
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=
=20
a simple automated way to ensure this. It might not be a bad idea to=20
maintain a set of commons-wide plugin version dependencies and even add=20
these to commons-build.xml so that running the main site build would update=
=20
them all.=20

One of the problems with keeping the custom commons-site.jsl is maintaining=
=20
it as maven and the plugins change. I tried to update if for 1.9+ and ended=
=20
up breaking pre-1.9 builds. Having a iong mess of jsl to pore through each=
=20
time xdoc does a release is not a happy state. I am happy to do what I can=
=20
to try to keep things going and to get us through the current mess, but I a=
m=20
by no means a jelly, jsl, or css expert and unless others with more=20
expertise are willing to take on maintaining this stuff, I think that we=20
need to rethink how the jsl, stylesheets and and menus work.=20

Phil

Niall
>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>=20
>

------=_Part_15647_10137367.1126590357912--