On 4 March 2011 20:38, Simone Tripodi <simonetrip...@apache.org> wrote: > I don't see anything wrong on modifying directly the .vm template, > there's no need to apply any hack or waiting for a fix from the maven > team. > at the end of the day, we're implementing the *commons* skin and every > component site shall be conform to it according to our policy, or not? > So, I suggest proceeding with the modified .vm, then for future > release, if and when the maven team will make fixes available, we can > come back speaking about your proposals > WDYT?
Yes, that's my position too. > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Mar 4, 2011 at 8:42 PM, sebb <seb...@gmail.com> wrote: >> 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 >> >> > > --------------------------------------------------------------------- > 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
