On 4 March 2011 18:45, Gary Gregory <garydgregory@gmail.com> wrote:
> On Fri, Mar 4, 2011 at 10:29 AM, sebb <sebbaz@gmail.com> wrote:
>>
>> On 4 March 2011 06:45, Simone Tripodi <simonetripodi@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 <garydgregory@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 <sebbaz@gmail.com> wrote:
>> >>
>> >>> On 4 March 2011 00:49, Niall Pemberton <niall.pemberton@gmail.com>
>> >>> wrote:
>> >>> > On Fri, Mar 4, 2011 at 12:35 AM, sebb <sebbaz@gmail.com> wrote:
>> >>> >> On 3 March 2011 23:42, Niall Pemberton <niall.pemberton@gmail.com>
>> >>> wrote:
>> >>> >>> On Thu, Mar 3, 2011 at 6:13 PM, sebb <sebbaz@gmail.com> wrote:
>> >>> >>>> On 26 February 2011 22:39, sebb <sebbaz@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-unsubscribe@commons.apache.org
>> >>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >> ---------------------------------------------------------------------
>> >>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> > ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >>> >
>> >>> >
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org