You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2012/11/03 15:59:17 UTC
Re: Website CMS
Ok. I think I am done and we are ready to replace the site.
Last night I played with fancy way to include live feeds (ASF::Value::Blogs, ASF::Value::Twitter, etc.) Unfortunately this didn't work for me. I narrowed it down to third-party XML::Atom::Feed not returning any entries and left it at that for now.
This morning I ported 2 years worth of blog posts to markdown (and even preserved the article URLs!), and simply linked to them from the home page. The whole process was very simple, and for our low rate of news, I don't mind keeping it as is.
We may play with some RSS scanners in parallel without delaying the launch. For instance I would love to get a Twitter panel showing latest stuff from https://twitter.com/ApacheCayenne (a resource that is updated periodically), a commit feed, etc.
Feel free to review and tweak the site at http://cayenne.staging.apache.org/ At some point next week I'd like to flip the switch on the old site and publish the new one.
BTW, beside following this http://www.apache.org/dev/cmsref.html#publishing do we need any infra help to activate publishing?
Andrus
On Oct 31, 2012, at 11:50 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Tonight I fixed legacy docs wrappers and created small per-version menus for each piece of the docs. Also checked in a bunch of smaller things, like the Twitter button, doc titles with version in them, etc.
>
> News seems to be the only thing remaining before we can go live.
>
> Andrus
>
> On Oct 31, 2012, at 10:31 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
>> On 31/10/12 5:20pm, Andrus Adamchik wrote:
>>> I'll take a look at porting the news. Don't think we need to port many past news.
>>
>> Some would be nice to give the project history.
>>
>>>> Why can't the third template extend skeleton?
>>>
>>> My thinking was that we don't need left hand menu for the docs. For instance looking at Docbook produced HTML I like how clean and distraction free it is. Wanted to keep that across the board for docs. I would imagine we'll just need a Cayenne header with a backlink to the main site, and a copyright/privacy policy footer. Anyways, I'll refactor the templates to maybe have a single skeleton and optional menu include. Will need to play with it a bit.
>>
>> Sure, that makes sense. Let me know when you are done and I'll play with the css a bit. It is a bit ugly right now.
>>
>>
>> Ari
>>
>>
>>
>>> Andrus
>>>
>>>
>>> On Oct 31, 2012, at 1:27 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>>> On 31/10/12 7:24am, Andrus Adamchik wrote:
>>>>
>>>>> Note that second and third templates do not extend skeleton template, as they are essentially incompatible. I just committed the changes, and here are the rendered examples:
>>>>>
>>>>> http://cayenne.staging.apache.org/download.html
>>>>> http://cayenne.staging.apache.org/doc30/api/index.html
>>>>> http://cayenne.staging.apache.org/doc30/overview.html
>>>>
>>>> Why can't the third template extend skeleton? I tried to strip out the bits of the html from the Confluence export which were incompatible, leaving only (hopefully) compatible bits. Perhaps we can put back skeleton and tweak the css a little to cope?
>>>>
>>>> I think the next steps are just news and tying in the automated docbook/javadoc builds for trunk documentation.
>>>>
>>>> If we go down the Apache Blog approach for news, this is what we do:
>>>>
>>>> {% for e in blog.list %}
>>>> <h2><a href="{{ e.url }}">{{ e.title }}</a></h2>
>>>> <div class="section-content">{{ e.content|safe|truncatewords_html:355 }}</div>
>>>> <hr>
>>>> {% endfor %}
>>>>
>>>> in our path.pm file:
>>>>
>>>> [ qr!^/index\.mdtext$!, news_page => {
>>>> blog => ASF::Value::Blogs->new(blog => "cayenne", limit=> 4),
>>>> } ],
>>>>
>>>>
>>>> Pluses:
>>>>
>>>> * people can add comments to the posts
>>>> * we get broader publicity on the main apache site as well with no extra effort
>>>> * there is probably an rss feed
>>>>
>>>> Minuses:
>>>>
>>>> * I don't know if we can carry forward historical news, so we'd need to handle that separately
>>>>
>>>>
>>>> Andrus, would you like to give this a try since you now have a local environment? I can then style up the news items. Later on if we get really clever it seems we might be able to have a feed on the side of recent Jira comments and svn commits. That would be nice to show the activity that happens behind the scenes.
>>>>
>>>>
>>>> Ari
>>>>
>>>>
>>>> --
>>>> -------------------------->
>>>> Aristedes Maniatis
>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>>
>>>
>>
>> --
>> -------------------------->
>> Aristedes Maniatis
>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>
>
>
Re: Website CMS
Posted by Andrus Adamchik <an...@objectstyle.org>.
Thanks! we did it!
It feels good to be in control again :)
On Nov 8, 2012, at 12:33 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> On 8/11/12 8:26pm, Aristedes Maniatis wrote:
>> On 8/11/12 7:28pm, Andrus Adamchik wrote:
>>> BTW the site seems to be in process of publishing now:http://cayenne.apache.org/ hopefully will be up shortly.
>>
>> Daniel from infra is trying to solve this now.
>
> And now fixed. The site is publishing as we speak.
>
>
> Ari
>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Re: Website CMS
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 8/11/12 8:26pm, Aristedes Maniatis wrote:
> On 8/11/12 7:28pm, Andrus Adamchik wrote:
>> BTW the site seems to be in process of publishing now:http://cayenne.apache.org/ hopefully will be up shortly.
>
> Daniel from infra is trying to solve this now.
And now fixed. The site is publishing as we speak.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Website CMS
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 8/11/12 7:28pm, Andrus Adamchik wrote:
> BTW the site seems to be in process of publishing now:http://cayenne.apache.org/ hopefully will be up shortly.
Daniel from infra is trying to solve this now.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Website CMS
Posted by Andrus Adamchik <an...@objectstyle.org>.
Looks like we still need one more redirect though. 3.0 docs were served as /doc till now, so this has to go to /doc30… Hmm… I might change the new /doc/ to /docs/ then to avoid redirect confusion.
BTW the site seems to be in process of publishing now: http://cayenne.apache.org/ hopefully will be up shortly.
Andrus
On Nov 8, 2012, at 10:56 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> On Nov 8, 2012, at 3:14 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>> Today loaded 3.1 javadocs and docbook HTML to the cms site. We have a total of 4 independent books in 3.1 (will probably refactor the whole docbook structure soon to make them easier to manipulate). Manually copying the folders wasn't too bad. The worst part was "git svn dcommit" after a Javadocs dump. But never the less it worked.
>>>
>>> Notice the new docs structure. I wanted the subfolders to logically follow dropdown menus, so instead of calling it /doc31/, I went with /doc/3_1/ :
>>>
>>> http://cayenne.staging.apache.org/doc/3_1/index.html
>>
>> Not sure how changing the path syntax helps. If you really want to do that we'll need redirects from all the old simpler URLs to the new structure.
>> Remember that people will end up in doc pages from a google search and may just change the URL to go to a different version.
>
> I didn't touch 1.2, 2.0, 3.0 layout. So no need for redirects. I strongly support the notion that we shouldn't be changing the existing well-publicized URLs without a cause. And if we do, always provide a 301 redirect (see "content/.htaccess"). But this is not the case here.
>
> The new scheme starts with 3.1 release. Among other things the new CMS freed us from the directory and file naming imposed by Confluence Autoexport, so I figured the URLs might follow the menu hierarchy for the docs. Also "unflattening" the top directory structure seems like a good thing for our own sanity.
>
>> I also suggest a redirect
>>
>> /doc/latest/ --> /doc/3.1/
>>
>> That makes it easier to refer people to the docs and for the links in mailing list archives to remain pointing to the current docs.
>
> I've been thinking about this for some time. A "latest" symlink is both good and bad. The positive is that it creates a perception of a single set of docs. The negative is that we do have multiple versions of the docs after all and it is not always clear what "latest" means on any given day and associating "latest" with this moving target is not always such a clear cut. As Cayenne accumulates more major releases, I feel like using explicit versioning everywhere will save us and users from more trouble.
>
> Taking your example, links in mailing list archives would actually work better with no "latest" symlink. Consider that some docs go away occasionally (e.g. dataviews are no longer in Cayenne, jpa, etc.). So this example seems to validate the version-aware URL approach.
>
>>> Ari, any word on publishing our staging to the live site?
>>
>> Yes, spoke to infra and created a ticket a few days ago. It is on their list.
>
> Awesome.
>
> Andrus
>
Re: Website doc path renaming
Posted by Andrus Adamchik <an...@objectstyle.org>.
Sure. I'll rename 3_1 to 3.1. Makes sense.
Regarding older docs… Let me play with .htaccess. I think we can move those too.
Again, now that we have possibilities not available when we used Confluence, organizing everything the way it "should" be is certainly a good idea.
Andrus
On Nov 8, 2012, at 12:37 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> On 8/11/12 6:56pm, Andrus Adamchik wrote:
>> I didn't touch 1.2, 2.0, 3.0 layout. So no need for redirects. I strongly support the notion that we shouldn't be changing the existing well-publicized URLs without a cause. And if we do, always provide a 301 redirect (see "content/.htaccess"). But this is not the case here.
>>
>> The new scheme starts with 3.1 release. Among other things the new CMS freed us from the directory and file naming imposed by Confluence Autoexport, so I figured the URLs might follow the menu hierarchy for the docs. Also "unflattening" the top directory structure seems like a good thing for our own sanity.
>
> Personally I don't know it is more sane (although I hate underscores). But I think we *want* consistency. That is, if I'm looking at
>
> http://cayenne.apache.org/doc/3.0/something
>
> I'd like to be able to change the url to
>
> http://cayenne.apache.org/doc/2.0/something
>
> and have it work.
>
>
>
> Ari
>
>
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
Website doc path renaming
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 8/11/12 6:56pm, Andrus Adamchik wrote:
> I didn't touch 1.2, 2.0, 3.0 layout. So no need for redirects. I strongly support the notion that we shouldn't be changing the existing well-publicized URLs without a cause. And if we do, always provide a 301 redirect (see "content/.htaccess"). But this is not the case here.
>
> The new scheme starts with 3.1 release. Among other things the new CMS freed us from the directory and file naming imposed by Confluence Autoexport, so I figured the URLs might follow the menu hierarchy for the docs. Also "unflattening" the top directory structure seems like a good thing for our own sanity.
Personally I don't know it is more sane (although I hate underscores). But I think we *want* consistency. That is, if I'm looking at
http://cayenne.apache.org/doc/3.0/something
I'd like to be able to change the url to
http://cayenne.apache.org/doc/2.0/something
and have it work.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Website CMS
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 8, 2012, at 3:14 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>> Today loaded 3.1 javadocs and docbook HTML to the cms site. We have a total of 4 independent books in 3.1 (will probably refactor the whole docbook structure soon to make them easier to manipulate). Manually copying the folders wasn't too bad. The worst part was "git svn dcommit" after a Javadocs dump. But never the less it worked.
>>
>> Notice the new docs structure. I wanted the subfolders to logically follow dropdown menus, so instead of calling it /doc31/, I went with /doc/3_1/ :
>>
>> http://cayenne.staging.apache.org/doc/3_1/index.html
>
> Not sure how changing the path syntax helps. If you really want to do that we'll need redirects from all the old simpler URLs to the new structure.
> Remember that people will end up in doc pages from a google search and may just change the URL to go to a different version.
I didn't touch 1.2, 2.0, 3.0 layout. So no need for redirects. I strongly support the notion that we shouldn't be changing the existing well-publicized URLs without a cause. And if we do, always provide a 301 redirect (see "content/.htaccess"). But this is not the case here.
The new scheme starts with 3.1 release. Among other things the new CMS freed us from the directory and file naming imposed by Confluence Autoexport, so I figured the URLs might follow the menu hierarchy for the docs. Also "unflattening" the top directory structure seems like a good thing for our own sanity.
> I also suggest a redirect
>
> /doc/latest/ --> /doc/3.1/
>
> That makes it easier to refer people to the docs and for the links in mailing list archives to remain pointing to the current docs.
I've been thinking about this for some time. A "latest" symlink is both good and bad. The positive is that it creates a perception of a single set of docs. The negative is that we do have multiple versions of the docs after all and it is not always clear what "latest" means on any given day and associating "latest" with this moving target is not always such a clear cut. As Cayenne accumulates more major releases, I feel like using explicit versioning everywhere will save us and users from more trouble.
Taking your example, links in mailing list archives would actually work better with no "latest" symlink. Consider that some docs go away occasionally (e.g. dataviews are no longer in Cayenne, jpa, etc.). So this example seems to validate the version-aware URL approach.
>> Ari, any word on publishing our staging to the live site?
>
> Yes, spoke to infra and created a ticket a few days ago. It is on their list.
Awesome.
Andrus
Re: Website CMS
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 8/11/12 6:33am, Andrus Adamchik wrote:
> Today loaded 3.1 javadocs and docbook HTML to the cms site. We have a total of 4 independent books in 3.1 (will probably refactor the whole docbook structure soon to make them easier to manipulate). Manually copying the folders wasn't too bad. The worst part was "git svn dcommit" after a Javadocs dump. But never the less it worked.
>
> Notice the new docs structure. I wanted the subfolders to logically follow dropdown menus, so instead of calling it /doc31/, I went with /doc/3_1/ :
>
> http://cayenne.staging.apache.org/doc/3_1/index.html
Not sure how changing the path syntax helps. If you really want to do that we'll need redirects from all the old simpler URLs to the new structure. Remember that people will end up in doc pages from a google search and may just change the URL to go to a different version.
I also suggest a redirect
/doc/latest/ --> /doc/3.1/
That makes it easier to refer people to the docs and for the links in mailing list archives to remain pointing to the current docs.
> Kept the older folders unchanged though. Next I will go back to docbook HTML template work (and maybe the refactoring above).
>
> Ari, any word on publishing our staging to the live site?
Yes, spoke to infra and created a ticket a few days ago. It is on their list.
Ari
> Cheers,
> Andrus
>
>
> On Nov 5, 2012, at 11:44 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>> On Nov 5, 2012, at 11:25 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>
>>> 1. Hosting from the ci server isn't a good idea in the long term
>>> 2. The API and docbook are pointing to trunk and this is now for 3.1
>>>
>>> However, I don't think that the differences between trunk and 3.1 are important yet and certainly we are a long way before we need to branch docbook.
>>
>> Cool. I think we need to start publishing javadoc artifacts to Maven central with releases (which is prolly a good idea regardless, as it would improve IDE integration). Then Javadocs publish procedure will be like
>>
>> * get cayenne-server-XX-javadoc.jar from Maven
>> * unpack it into site/
>> * commit
>>
>> I may do that manually for the relevant releases.
>>
>>> I'm discussing some ideas with infra about how we might be publishing trunk realtime docbook builds. As you point out, we may never need nightly javadoc published on the website.
>>>
>>>
>>> I'll ask infra now to put our site live, unless anyone has any final words.
>>
>> Let's do it!
>>
>>> I've now disabled all my scripts which previously published javadocs and confluence. I have also now disabled public read access, and committer read-write access to the CAYSITE confluence space. It appears that the CAYDOC, CAYDOC12, CAYDOC20, etc space are already all gone.
>>
>> Also we need infra help to delete CAY/, CAYDOC/, CAYDOC12/, CAYDOC20/, CAYDOC30/, CAYDV/, CAYJPA/ CAYSITE/ folders from https://cwiki.apache.org/
>>
>> Or do they autoexport everything, regardless of the space purpose? In this case we still need their help to delete autoexports of the previously deleted spaces: CAYDOC/, CAYDOC12/, CAYDOC20/, CAYDOC30/ (and CAYSITE/ once we delete that one as well).
>>
>> Andrus
>>
>>
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Website CMS
Posted by Andrus Adamchik <an...@objectstyle.org>.
Today loaded 3.1 javadocs and docbook HTML to the cms site. We have a total of 4 independent books in 3.1 (will probably refactor the whole docbook structure soon to make them easier to manipulate). Manually copying the folders wasn't too bad. The worst part was "git svn dcommit" after a Javadocs dump. But never the less it worked.
Notice the new docs structure. I wanted the subfolders to logically follow dropdown menus, so instead of calling it /doc31/, I went with /doc/3_1/ :
http://cayenne.staging.apache.org/doc/3_1/index.html
Kept the older folders unchanged though. Next I will go back to docbook HTML template work (and maybe the refactoring above).
Ari, any word on publishing our staging to the live site?
Cheers,
Andrus
On Nov 5, 2012, at 11:44 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> On Nov 5, 2012, at 11:25 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
>> 1. Hosting from the ci server isn't a good idea in the long term
>> 2. The API and docbook are pointing to trunk and this is now for 3.1
>>
>> However, I don't think that the differences between trunk and 3.1 are important yet and certainly we are a long way before we need to branch docbook.
>
> Cool. I think we need to start publishing javadoc artifacts to Maven central with releases (which is prolly a good idea regardless, as it would improve IDE integration). Then Javadocs publish procedure will be like
>
> * get cayenne-server-XX-javadoc.jar from Maven
> * unpack it into site/
> * commit
>
> I may do that manually for the relevant releases.
>
>> I'm discussing some ideas with infra about how we might be publishing trunk realtime docbook builds. As you point out, we may never need nightly javadoc published on the website.
>>
>>
>> I'll ask infra now to put our site live, unless anyone has any final words.
>
> Let's do it!
>
>> I've now disabled all my scripts which previously published javadocs and confluence. I have also now disabled public read access, and committer read-write access to the CAYSITE confluence space. It appears that the CAYDOC, CAYDOC12, CAYDOC20, etc space are already all gone.
>
> Also we need infra help to delete CAY/, CAYDOC/, CAYDOC12/, CAYDOC20/, CAYDOC30/, CAYDV/, CAYJPA/ CAYSITE/ folders from https://cwiki.apache.org/
>
> Or do they autoexport everything, regardless of the space purpose? In this case we still need their help to delete autoexports of the previously deleted spaces: CAYDOC/, CAYDOC12/, CAYDOC20/, CAYDOC30/ (and CAYSITE/ once we delete that one as well).
>
> Andrus
>
>
Re: Website CMS
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 5, 2012, at 11:25 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> 1. Hosting from the ci server isn't a good idea in the long term
> 2. The API and docbook are pointing to trunk and this is now for 3.1
>
> However, I don't think that the differences between trunk and 3.1 are important yet and certainly we are a long way before we need to branch docbook.
Cool. I think we need to start publishing javadoc artifacts to Maven central with releases (which is prolly a good idea regardless, as it would improve IDE integration). Then Javadocs publish procedure will be like
* get cayenne-server-XX-javadoc.jar from Maven
* unpack it into site/
* commit
I may do that manually for the relevant releases.
> I'm discussing some ideas with infra about how we might be publishing trunk realtime docbook builds. As you point out, we may never need nightly javadoc published on the website.
>
>
> I'll ask infra now to put our site live, unless anyone has any final words.
Let's do it!
> I've now disabled all my scripts which previously published javadocs and confluence. I have also now disabled public read access, and committer read-write access to the CAYSITE confluence space. It appears that the CAYDOC, CAYDOC12, CAYDOC20, etc space are already all gone.
Also we need infra help to delete CAY/, CAYDOC/, CAYDOC12/, CAYDOC20/, CAYDOC30/, CAYDV/, CAYJPA/ CAYSITE/ folders from https://cwiki.apache.org/
Or do they autoexport everything, regardless of the space purpose? In this case we still need their help to delete autoexports of the previously deleted spaces: CAYDOC/, CAYDOC12/, CAYDOC20/, CAYDOC30/ (and CAYSITE/ once we delete that one as well).
Andrus
Re: Website CMS
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 5/11/12 5:09pm, Andrus Adamchik wrote:
> At the same time I think it is in a shape good enough to be published as "master" 3.1 (and 3.2) documentation set on the site, while I am slowly rewriting the remaining chapters. It should be much more useful to 3.1 users then just cloning the old 3.0 wiki docs (which is what we essentially have on the current site). And publishing would require HTML (and PDF) templates cleanup.
OK, then I've just added more links on the left to the docbook and java api. This is temporary since:
1. Hosting from the ci server isn't a good idea in the long term
2. The API and docbook are pointing to trunk and this is now for 3.1
However, I don't think that the differences between trunk and 3.1 are important yet and certainly we are a long way before we need to branch docbook.
I'm discussing some ideas with infra about how we might be publishing trunk realtime docbook builds. As you point out, we may never need nightly javadoc published on the website.
I'll ask infra now to put our site live, unless anyone has any final words. I've now disabled all my scripts which previously published javadocs and confluence. I have also now disabled public read access, and committer read-write access to the CAYSITE confluence space. It appears that the CAYDOC, CAYDOC12, CAYDOC20, etc space are already all gone.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Website CMS
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 5, 2012, at 2:14 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>> I also have a post launch cleanup list that will require their involvement:
>>
>> * stop cwiki.a.o rsync (you control this one IIRC?)
>> * delete all autoexported files on cwiki.a.o (infra)
>> * track down unlinked files in docroot, delete them, creating 301 redirects where applicable. (me or any other Cayenne committer)
>
> Actually I suspect I can just ask Infra to discard our entire website folder and replace it with the Apache CMS folder. So we should look for 'unlinked' pages now. Personally I can't think of any, and we could review Google webmaster tools after the change to see what pages people link to that are gone. I'll set that up now…
That'll work.
>>> I think the next focus needs to be on getting docbook finished so we can add 3.1 to the left menu. I'm happy to help copy in existing documentation, but Andrus, you said that you wanted to restructure the docs for this project. Perhaps you want to work on it, or outline what you had in mind?
>>
>> Yep. I can create a more site-centric HTML template for docbook and do a manual initial docs dump from the main SVN tree into the "site" and adding needed menus. Once that's live, we can work on improving CSS, etc.
>
> Are we talking about the same thing? I'm not talking about the html template so much as the content of the docbook itself. It is currently missing lots of content from Confluence and in the past you said that you did not want to just copy it over but to rearrange it into more helpful structures. Moving stuff into docbook takes a bit of effort, so any structure changes should be done first.
Yes, the new docbook stuff is about rearranging and a substantial rewrite of the wiki docs. It is still unfinished, and I'd rather we do not just move the old wikidocs to it. That would defeat the purpose of the "modernizing" effort done so far.
At the same time I think it is in a shape good enough to be published as "master" 3.1 (and 3.2) documentation set on the site, while I am slowly rewriting the remaining chapters. It should be much more useful to 3.1 users then just cloning the old 3.0 wiki docs (which is what we essentially have on the current site). And publishing would require HTML (and PDF) templates cleanup.
Andrus
Re: Website CMS
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 4/11/12 11:08pm, Andrus Adamchik wrote:
>
> On Nov 4, 2012, at 2:58 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>
>> Nicely done polishing off those last remaining tasks... My look around the site reveals nothing that needs to be fixed before launch, so let's do it. I think infra will need to be involved to switch the website over from the current synchronisation feed to Apache CMS.
>
> Cool. You are in touch with the infra guys. Could you Jira it for them (or ask on irc)?
Sure.
> I also have a post launch cleanup list that will require their involvement:
>
> * stop cwiki.a.o rsync (you control this one IIRC?)
> * delete all autoexported files on cwiki.a.o (infra)
> * track down unlinked files in docroot, delete them, creating 301 redirects where applicable. (me or any other Cayenne committer)
Actually I suspect I can just ask Infra to discard our entire website folder and replace it with the Apache CMS folder. So we should look for 'unlinked' pages now. Personally I can't think of any, and we could review Google webmaster tools after the change to see what pages people link to that are gone. I'll set that up now...
>> I think the next focus needs to be on getting docbook finished so we can add 3.1 to the left menu. I'm happy to help copy in existing documentation, but Andrus, you said that you wanted to restructure the docs for this project. Perhaps you want to work on it, or outline what you had in mind?
>
> Yep. I can create a more site-centric HTML template for docbook and do a manual initial docs dump from the main SVN tree into the "site" and adding needed menus. Once that's live, we can work on improving CSS, etc.
Are we talking about the same thing? I'm not talking about the html template so much as the content of the docbook itself. It is currently missing lots of content from Confluence and in the past you said that you did not want to just copy it over but to rearrange it into more helpful structures. Moving stuff into docbook takes a bit of effort, so any structure changes should be done first.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Website CMS
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Nov 4, 2012, at 2:58 PM, Aristedes Maniatis <ar...@maniatis.org> wrote:
> Nicely done polishing off those last remaining tasks... My look around the site reveals nothing that needs to be fixed before launch, so let's do it. I think infra will need to be involved to switch the website over from the current synchronisation feed to Apache CMS.
Cool. You are in touch with the infra guys. Could you Jira it for them (or ask on irc)?
I also have a post launch cleanup list that will require their involvement:
* stop cwiki.a.o rsync (you control this one IIRC?)
* delete all autoexported files on cwiki.a.o (infra)
* track down unlinked files in docroot, delete them, creating 301 redirects where applicable. (me or any other Cayenne committer)
> I think the next focus needs to be on getting docbook finished so we can add 3.1 to the left menu. I'm happy to help copy in existing documentation, but Andrus, you said that you wanted to restructure the docs for this project. Perhaps you want to work on it, or outline what you had in mind?
Yep. I can create a more site-centric HTML template for docbook and do a manual initial docs dump from the main SVN tree into the "site" and adding needed menus. Once that's live, we can work on improving CSS, etc.
Andrus
Re: Website CMS
Posted by Aristedes Maniatis <ar...@maniatis.org>.
Nicely done polishing off those last remaining tasks... My look around the site reveals nothing that needs to be fixed before launch, so let's do it. I think infra will need to be involved to switch the website over from the current synchronisation feed to Apache CMS.
I think the next focus needs to be on getting docbook finished so we can add 3.1 to the left menu. I'm happy to help copy in existing documentation, but Andrus, you said that you wanted to restructure the docs for this project. Perhaps you want to work on it, or outline what you had in mind?
Ari
On 4/11/12 1:59am, Andrus Adamchik wrote:
> Ok. I think I am done and we are ready to replace the site.
>
> Last night I played with fancy way to include live feeds (ASF::Value::Blogs, ASF::Value::Twitter, etc.) Unfortunately this didn't work for me. I narrowed it down to third-party XML::Atom::Feed not returning any entries and left it at that for now.
>
> This morning I ported 2 years worth of blog posts to markdown (and even preserved the article URLs!), and simply linked to them from the home page. The whole process was very simple, and for our low rate of news, I don't mind keeping it as is.
>
> We may play with some RSS scanners in parallel without delaying the launch. For instance I would love to get a Twitter panel showing latest stuff from https://twitter.com/ApacheCayenne (a resource that is updated periodically), a commit feed, etc.
>
> Feel free to review and tweak the site at http://cayenne.staging.apache.org/ At some point next week I'd like to flip the switch on the old site and publish the new one.
>
> BTW, beside following this http://www.apache.org/dev/cmsref.html#publishing do we need any infra help to activate publishing?
>
> Andrus
>
>
> On Oct 31, 2012, at 11:50 PM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
>> Tonight I fixed legacy docs wrappers and created small per-version menus for each piece of the docs. Also checked in a bunch of smaller things, like the Twitter button, doc titles with version in them, etc.
>>
>> News seems to be the only thing remaining before we can go live.
>>
>> Andrus
>>
>> On Oct 31, 2012, at 10:31 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>
>>> On 31/10/12 5:20pm, Andrus Adamchik wrote:
>>>> I'll take a look at porting the news. Don't think we need to port many past news.
>>>
>>> Some would be nice to give the project history.
>>>
>>>>> Why can't the third template extend skeleton?
>>>>
>>>> My thinking was that we don't need left hand menu for the docs. For instance looking at Docbook produced HTML I like how clean and distraction free it is. Wanted to keep that across the board for docs. I would imagine we'll just need a Cayenne header with a backlink to the main site, and a copyright/privacy policy footer. Anyways, I'll refactor the templates to maybe have a single skeleton and optional menu include. Will need to play with it a bit.
>>>
>>> Sure, that makes sense. Let me know when you are done and I'll play with the css a bit. It is a bit ugly right now.
>>>
>>>
>>> Ari
>>>
>>>
>>>
>>>> Andrus
>>>>
>>>>
>>>> On Oct 31, 2012, at 1:27 AM, Aristedes Maniatis <ar...@maniatis.org> wrote:
>>>>> On 31/10/12 7:24am, Andrus Adamchik wrote:
>>>>>
>>>>>> Note that second and third templates do not extend skeleton template, as they are essentially incompatible. I just committed the changes, and here are the rendered examples:
>>>>>>
>>>>>> http://cayenne.staging.apache.org/download.html
>>>>>> http://cayenne.staging.apache.org/doc30/api/index.html
>>>>>> http://cayenne.staging.apache.org/doc30/overview.html
>>>>>
>>>>> Why can't the third template extend skeleton? I tried to strip out the bits of the html from the Confluence export which were incompatible, leaving only (hopefully) compatible bits. Perhaps we can put back skeleton and tweak the css a little to cope?
>>>>>
>>>>> I think the next steps are just news and tying in the automated docbook/javadoc builds for trunk documentation.
>>>>>
>>>>> If we go down the Apache Blog approach for news, this is what we do:
>>>>>
>>>>> {% for e in blog.list %}
>>>>> <h2><a href="{{ e.url }}">{{ e.title }}</a></h2>
>>>>> <div class="section-content">{{ e.content|safe|truncatewords_html:355 }}</div>
>>>>> <hr>
>>>>> {% endfor %}
>>>>>
>>>>> in our path.pm file:
>>>>>
>>>>> [ qr!^/index\.mdtext$!, news_page => {
>>>>> blog => ASF::Value::Blogs->new(blog => "cayenne", limit=> 4),
>>>>> } ],
>>>>>
>>>>>
>>>>> Pluses:
>>>>>
>>>>> * people can add comments to the posts
>>>>> * we get broader publicity on the main apache site as well with no extra effort
>>>>> * there is probably an rss feed
>>>>>
>>>>> Minuses:
>>>>>
>>>>> * I don't know if we can carry forward historical news, so we'd need to handle that separately
>>>>>
>>>>>
>>>>> Andrus, would you like to give this a try since you now have a local environment? I can then style up the news items. Later on if we get really clever it seems we might be able to have a feed on the side of recent Jira comments and svn commits. That would be nice to show the activity that happens behind the scenes.
>>>>>
>>>>>
>>>>> Ari
>>>>>
>>>>>
>>>>> --
>>>>> -------------------------->
>>>>> Aristedes Maniatis
>>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>>>
>>>>
>>>
>>> --
>>> -------------------------->
>>> Aristedes Maniatis
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>>>
>>
>>
>
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A