On 2011-03-04 21:45, sebb wrote: > 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.
I agree too. As a Maven committer I'll take a look at Sebb's issues when I find the time. We (commons) should not wait for that to happen though. Go ahead with what is possible to do today in commons. > >> 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 > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
