On 05/11/2012 11:16 AM, Stefano Bagnara wrote:
2012/5/11 Ioan Eugen Stan<[email protected]>:
My concerns:
- Have uniform skin between cms and mvn generated pages.
- Have on all pages the left menu which has 3 parts: the suproject links,
the reports links and the top james links (about, download, asf).
- Have on all pages the same top menu with the list of projects.
We currently don't have any of these. The layout changes when you move
from project to project because each project has it's own site that it
inherits. There is no common parent for all projects.
I don't get this. All of james website and products use the same
layout and the same top-menu.
Sometimes you will get "older" versions because we never updated some
product (so maybe latest changes to the skin have not yet inherited by
older projects).
But, overall, the skin is the same across the whole website (excluding
javadocs and xrefs).
The top menu is also different from project to project: different
ordering and different sizes in CSS and even missing elements. For
example http://james.apache.org/jspf/index.html is missing home,
mailbox, project. Just click on all top menu entries and you will see
for yourself.
A solution for this is to move the mvn site templates to svn:externals
(to skin project maybe) and import them in every project. This way we
might solve the uniformity issue.
A solution is to update the maven generated websites.
Either way you are replying to the objection that the whole shouldn't
be different saying that currently we have minor differences like one
menu voice or different css padding: doesn't sound fair.
To fix the difference we would just need to update the parent pom to
every product "trunk" and deploy the website for each of them: I did
that a couple of years ago, but I had no time since then to update (to
be fair this should have been done/scheduled by the people that
updated the skin).
So the FIX to this issue is to update each product and not to put one
more skin in the mix ;-)
As I told previously I predict CMS will not replace all of our website
docs and we will still generate some of them using maven, so you will
have to regenerate maven projects anyway, whatever you do with CMS.
One way to improve this would be to create a meta-skin for maven that
will output pages without the common parts and then have CMS use the
maven output as input and add the common parts before publishing: this
will create a double commit on each page changes (and maybe more
complex workflow), not sure it worth it, but I'm not against a similar
solution.
The difference regarding top menus, font size... comes indeed from site
which were not regenerated since long.
For example, hupa was missing many entries, and since Manolo regenerated
it last week, it's compliant with the latest skin.
It's true that a few of our subproject sites (mpt...) would benefit from
a new site generation.
Indeed, very confusing and my opinion is that having the sidebar
change that much with every project is creating even more confusion.
We should strive for uniform pages but I don't know what support
maven site has for template inheritance, so it might not be possible.
I will look into it.
Here is the maven skin:
https://svn.apache.org/repos/asf/james/skin/trunk/src/main/resources/META-INF/maven/site.vm
and here the common resources used by the skin:
https://svn.apache.org/repos/asf/james/skin/trunk/src/main/resources/
Here is the structure defined by our "parent project":
https://svn.apache.org/repos/asf/james/project/trunk/src/site/site.xml
And here is a definition for a single project:
https://svn.apache.org/repos/asf/james/mime4j/trunk/src/site/site.xml
The different outputs are a consequence of products referencing an
older parent project (that have a different layout).
@Stefano: We might not loose browser editing. I'm not sure but I think
the bookmarklet will resolve the source that generated the page even
if it's not markdown formatted, by looking at which reg-exp from
path.pm it matches.
OK, good.
How is permission to the editing handled? Does it ask for svn
credentials or what else?
My question is about who can edit the pages: if we plan to move the
wiki content then we should have a way to let non-james-committers to
write changes. We don't want anonymous, but will we be able to let
every asf member to submit doc changes?
As discussed on IRC, it would be good to migrate the wiki to ASF CMS, if
it supports non-committer authenticated users. I guess the CMS workflow
will be useful to avoid spam editing such as the ones I had to revert
last week and today.
Thx, Eric
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
