On 4 March 2011 18:45, Gary Gregory <garydgreg...@gmail.com> wrote: > On Fri, Mar 4, 2011 at 10:29 AM, sebb <seb...@gmail.com> wrote: >> >> On 4 March 2011 06:45, Simone Tripodi <simonetrip...@apache.org> wrote: >> > Hi Gary/all >> > I don't know if you're interested, but I realized time ago a light >> > skin[1] that is already released under ASL2.0, here[2] you can find a >> > sample, if you are interested on it we could speak about moving it as >> > new commons-skin... >> >> We cannot use it as it stands. >> >> Its site.vm template does not support the trademark attributions we >> need to add to the footer, and AFAIK Maven only allows the template to >> be overridden as part of a skin. >> >> If the default Maven template is ever fixed to allow proper footer >> (and other) customisation, then it would be usable, but I doubt that >> will happen soon. > > How about submitting a patch to Maven?
It's easy enough to patch the template - because that is what I have been doing - but for a proper fix, really the site.xml format needs to be extended to add a <footer> element, and I have no idea where that is handled. Also, for flexibility, site.xml ought to support variables in the context of the current project; currently an inherited site.xml is processed in the context of the project that contains it. I've fixed that by a hack in the template, but it is not generic; that would need external support. I've raised various issues, but so far not even a comment on them. > Gary > >> >> > Just let me know, have a nice day! >> > Simo >> > >> > [1] http://code.google.com/p/fluido-skin/ >> > [2] http://developers.any23.org/ >> > >> > http://people.apache.org/~simonetripodi/ >> > http://www.99soft.org/ >> > >> > >> > >> > On Fri, Mar 4, 2011 at 3:08 AM, Gary Gregory <garydgreg...@gmail.com> >> > wrote: >> >> Speaking of skins... IMO, this looks beautiful: >> >> http://directory.apache.org/ >> >> >> >> What can't we do something like that? >> >> >> >> Gary >> >> >> >> On Thu, Mar 3, 2011 at 8:55 PM, sebb <seb...@gmail.com> wrote: >> >> >> >>> On 4 March 2011 00:49, Niall Pemberton <niall.pember...@gmail.com> >> >>> wrote: >> >>> > On Fri, Mar 4, 2011 at 12:35 AM, sebb <seb...@gmail.com> wrote: >> >>> >> On 3 March 2011 23:42, Niall Pemberton <niall.pember...@gmail.com> >> >>> wrote: >> >>> >>> On Thu, Mar 3, 2011 at 6:13 PM, sebb <seb...@gmail.com> wrote: >> >>> >>>> On 26 February 2011 22:39, sebb <seb...@gmail.com> wrote: >> >>> >>>>> Commons-build seems to be Maven1 code - is it still needed? >> >>> >>>>> >> >>> >>>>> It does seem to be the source for commons-maven.css and perhaps >> >>> >>>>> tigris.css, but otherwise does not seem to be useful. >> >>> >>>>> >> >>> >>>>> Perhaps the CSS files should be moved to commons-site? >> >>> >>>>> >> >>> >>>> >> >>> >>>> I propose to move the xdocs/style/*.css files to commons-site - >> >>> >>>> OK? >> >>> >>> >> >>> >>> Why move them? Commons Site is working without them isn't it? >> >>> >> >> >>> >> Commons site is working currently because people.apache.org is >> >>> >> acting >> >>> >> as the storage for the shared CSS files. >> >>> > >> >>> > Ah OK. >> >>> > >> >>> > I wonder why we just didn't put that in commons skin? >> >>> > >> >>> > I think originally we used to update the name of the ApacheCon logo >> >>> > in >> >>> > the CSS. But then we changed the logo to a generic name >> >>> > (current-event-125x125.png) and so we just have to replace the image >> >>> > and not change the CSS. >> >>> >> >>> ApacheCon is now in (parent) site.xml, but is fixed, and hopefully >> >>> won't need to change. >> >>> It can be overridden on a component basis if required. >> >>> >> >>> > If thats the case then it could go in commons-skin. However if we >> >>> > wanted to change the CSS, then if its in commons-skin it needs a >> >>> > skin >> >>> > & parent pom release - wheras commons-site its just a commit and >> >>> > re-deploy. >> >>> > >> >>> > Sorry for thinking out loud, I think I agree with you. >> >>> >> >>> No worries, it's useful to discuss this before finalising the >> >>> commons-skin updates. >> >>> >> >>> At present, site.css is included in commons-skin, and site.css >> >>> @includes http://commons.apache.org/style/commons-maven.css. >> >>> This means that sites don't work off-line properly when testing - and >> >>> may also affect release documentation used offline. >> >>> >> >>> So I now think your idea is best - let's put commons-maven.css in >> >>> commons-skin and change site.css accordingly. >> >>> [Or indeed one could rename commons-maven.css as site.css, but I think >> >>> that would be confusing.] >> >>> >> >>> > Niall >> >>> > >> >>> >> If the site ever had to be recreated, it would not be enough to >> >>> >> redeploy commons-site and all the components. >> >>> >> >> >>> >> It just seems wrong to have the source for some of the key CSS >> >>> >> files >> >>> >> stored in an component that cannot easily be deployed >> >>> >> (commons-build >> >>> >> uses Maven 1). >> >>> >> >> >>> >> And even if one did deploy it, AFAICT the only useful output is the >> >>> >> style directory - the rest seems to be old documentation that would >> >>> >> then have to be overwritten by deploying commons-site. >> >>> >> >> >>> >> The reason I need to do this now is that I need to create a new >> >>> >> version of commons-theme.css without the ApacheCon background logo. >> >>> >> This will be referenced in the new commons-skin via the site.css >> >>> >> file. >> >>> >> >> >>> >> I think it makes more sense to store the style files in >> >>> >> commons-site, >> >>> >> so they will be uploaded whenever the commons-site is redeployed. >> >>> >> This will make changes easier going forward. >> >>> >> >> >>> >>> Niall >> >>> >>> >> >>> >>> >> >>> >>> --------------------------------------------------------------------- >> >>> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>> >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>> >>> >> >>> >>> >> >>> >> >> >>> >> >> >>> >> --------------------------------------------------------------------- >> >>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>> >> >> >>> >> >> >>> > >> >>> > >> >>> > --------------------------------------------------------------------- >> >>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>> > For additional commands, e-mail: dev-h...@commons.apache.org >> >>> > >> >>> > >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>> >> >>> >> >> >> >> >> >> -- >> >> Thank you, >> >> Gary >> >> >> >> http://garygregory.wordpress.com/ >> >> http://garygregory.com/ >> >> http://people.apache.org/~ggregory/ >> >> http://twitter.com/GaryGregory >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > Thank you, > Gary > > http://garygregory.wordpress.com/ > http://garygregory.com/ > http://people.apache.org/~ggregory/ > http://twitter.com/GaryGregory > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
