Lucene - Core
  1. Lucene - Core
  2. LUCENE-2748

Convert all Lucene web properties to use the ASF CMS

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      The new CMS has a lot of nice features (and some kinks to still work out) and Forrest just doesn't cut it anymore, so we should move to the ASF CMS: http://apache.org/dev/cms.html

      1. modify_ui.diff
        5 kB
        Jeremy Bolanos

        Issue Links

          Activity

          Hide
          Steve Rowe added a comment -

          Where will the subversion space for the site sources go? Under repos/asf/lucene/new-site-dir/?

          Will we still maintained versioned and unversioned content?

          Show
          Steve Rowe added a comment - Where will the subversion space for the site sources go? Under repos/asf/lucene/new-site-dir/ ? Will we still maintained versioned and unversioned content?
          Hide
          Grant Ingersoll added a comment -

          Initial setup is complete. You can see a very barebones site at http://lucene.staging.apache.org/lucene

          Where will the subversion space for the site sources go? Under repos/asf/lucene/new-site-dir/?

          SVN for all this is at: https://svn.apache.org/repos/asf/lucene/cms/trunk

          I'd suggest we can subdivide that to have solr, core, pylucene and ORP. The nice thing is we can have a consistent look and feel and far less maintenance.

          Will we still maintained versioned and unversioned content?

          Not sure what you mean by unversioned content. The Wiki won't be going away.

          Show
          Grant Ingersoll added a comment - Initial setup is complete. You can see a very barebones site at http://lucene.staging.apache.org/lucene Where will the subversion space for the site sources go? Under repos/asf/lucene/new-site-dir/? SVN for all this is at: https://svn.apache.org/repos/asf/lucene/cms/trunk I'd suggest we can subdivide that to have solr, core, pylucene and ORP. The nice thing is we can have a consistent look and feel and far less maintenance. Will we still maintained versioned and unversioned content? Not sure what you mean by unversioned content. The Wiki won't be going away.
          Hide
          Hoss Man added a comment -

          Not sure what you mean by unversioned content. The Wiki won't be going away.

          i'm pretty sure steven meant versioned/unversioned in the sense that the current site has general pages, and then pages that are specific to certain releases..

          Some unversioned pages...

          http://lucene.apache.org/java/docs/index.html
          http://lucene.apache.org/java/docs/features.html
          http://lucene.apache.org/java/docs/whoweare.html

          Some versioned pages...

          http://lucene.apache.org/java/2_9_1/fileformats.html
          http://lucene.apache.org/java/3_0_3/fileformats.html
          ...all the release specific javadocs

          IIRC, the "versioned" pages are not checked in to svn, they are just unziped dumps of the docs from the corresponding release.

          my understanding is that with the new CMS, all of those pages will need to go into SVN - not a big deal really, they go in once and never change

          Show
          Hoss Man added a comment - Not sure what you mean by unversioned content. The Wiki won't be going away. i'm pretty sure steven meant versioned/unversioned in the sense that the current site has general pages, and then pages that are specific to certain releases.. Some unversioned pages... http://lucene.apache.org/java/docs/index.html http://lucene.apache.org/java/docs/features.html http://lucene.apache.org/java/docs/whoweare.html Some versioned pages... http://lucene.apache.org/java/2_9_1/fileformats.html http://lucene.apache.org/java/3_0_3/fileformats.html ...all the release specific javadocs IIRC, the "versioned" pages are not checked in to svn, they are just unziped dumps of the docs from the corresponding release. my understanding is that with the new CMS, all of those pages will need to go into SVN - not a big deal really, they go in once and never change
          Hide
          Grant Ingersoll added a comment -

          I wonder if the best thing to do here is to simply start fresh and clean and simply leave all existing content up as is and link to it as the "old" content.

          Show
          Grant Ingersoll added a comment - I wonder if the best thing to do here is to simply start fresh and clean and simply leave all existing content up as is and link to it as the "old" content.
          Hide
          Grant Ingersoll added a comment -

          Making some progress on this. Here's my intent: We start clean. One website directory for all of our projects (Lucene, Solr, PyLucene and ORP). I'm more or less copying the layout of Mahout, which copied Open For Biz. It's a lot cleaner and a lot nicer to look at. I intend to move the old sites to an archive area and just link to them.

          We'll still need to figure out per release docs, but I suspect it won't be that hard to convert that stuff to Markdown going forward and having our deploy/release mechanism just publish it to the CMS.

          Show
          Grant Ingersoll added a comment - Making some progress on this. Here's my intent: We start clean. One website directory for all of our projects (Lucene, Solr, PyLucene and ORP). I'm more or less copying the layout of Mahout, which copied Open For Biz. It's a lot cleaner and a lot nicer to look at. I intend to move the old sites to an archive area and just link to them. We'll still need to figure out per release docs, but I suspect it won't be that hard to convert that stuff to Markdown going forward and having our deploy/release mechanism just publish it to the CMS.
          Hide
          Grant Ingersoll added a comment -

          If you wish to build/test locally, do the setup at: http://www.apache.org/dev/cmsref.html#local-build

          Then run:

          <path>/build_site.pl --source-base [Path to Lucene CMS SVN checkout top dir] --target-base [OUTPUT]

          Show
          Grant Ingersoll added a comment - If you wish to build/test locally, do the setup at: http://www.apache.org/dev/cmsref.html#local-build Then run: <path>/build_site.pl --source-base [Path to Lucene CMS SVN checkout top dir] --target-base [OUTPUT]
          Hide
          Yonik Seeley added a comment -

          I'm more or less copying the layout of Mahout, which copied Open For Biz.

          +1, I like the looks of the Mahout site.

          Show
          Yonik Seeley added a comment - I'm more or less copying the layout of Mahout, which copied Open For Biz. +1, I like the looks of the Mahout site.
          Hide
          Mark Miller added a comment -

          Made my first commit - update the solr logo from the old one to the new one.

          Overall, I already like this much more than the old system - despite the somewhat painful setup process. We need to work on documenting that better I think.

          Not sure I like the idea of having to run this markup daemon in the background though...

          Show
          Mark Miller added a comment - Made my first commit - update the solr logo from the old one to the new one. Overall, I already like this much more than the old system - despite the somewhat painful setup process. We need to work on documenting that better I think. Not sure I like the idea of having to run this markup daemon in the background though...
          Hide
          Hoss Man added a comment -

          We'll still need to figure out per release docs, but I suspect it won't be that hard to convert that stuff to Markdown going forward and having our deploy/release mechanism just publish it to the CMS.

          I would actually argue that the "per release" docs don't need to have the same look/feel as the site – probably better actually moving forward to make them clearly distinct so there is an obvious distinction between "the site" and "the docs" (which may also help to prevent us from inadvertently putting relative links in the "per release" docs that wont work from a local install of a release)

          On the java side of things, moving all of the per-release docs into the javadoc process (using the doc-files dir, and linking to them from overview.html) would be one good way to keep everything encapsulated nicely.

          I haven't dug into it, but the Apache CMS Ref guide has an details on how to publish a big tar ball of auto-generated docs into the CMS, with an example of how to automate the process with a script (ie: from hudson for nightly docs or as part of a release manager script)

          https://www.apache.org/dev/cmsref.html#generated-docs

          Show
          Hoss Man added a comment - We'll still need to figure out per release docs, but I suspect it won't be that hard to convert that stuff to Markdown going forward and having our deploy/release mechanism just publish it to the CMS. I would actually argue that the "per release" docs don't need to have the same look/feel as the site – probably better actually moving forward to make them clearly distinct so there is an obvious distinction between "the site" and "the docs" (which may also help to prevent us from inadvertently putting relative links in the "per release" docs that wont work from a local install of a release) On the java side of things, moving all of the per-release docs into the javadoc process (using the doc-files dir, and linking to them from overview.html) would be one good way to keep everything encapsulated nicely. I haven't dug into it, but the Apache CMS Ref guide has an details on how to publish a big tar ball of auto-generated docs into the CMS, with an example of how to automate the process with a script (ie: from hudson for nightly docs or as part of a release manager script) https://www.apache.org/dev/cmsref.html#generated-docs
          Hide
          Grant Ingersoll added a comment -

          Not sure I like the idea of having to run this markup daemon in the background though...

          Once we get it up and running, we likely can just commit and then check the staging site. The CMS has a means to push to production from staging. For now, though, w/ multiple people working actively on it, we'll need to do it locally.

          Show
          Grant Ingersoll added a comment - Not sure I like the idea of having to run this markup daemon in the background though... Once we get it up and running, we likely can just commit and then check the staging site. The CMS has a means to push to production from staging. For now, though, w/ multiple people working actively on it, we'll need to do it locally.
          Hide
          Hoss Man added a comment -

          Once we get it up and running, we likely can just commit and then check the staging site

          more importantly: for most small changes (adding new committers, posting release announcements, etc...) the CMS bookmarklet (which lets you edit live pages from your browser) will probably be all you'll ever need to use

          https://cms.apache.org/

          Show
          Hoss Man added a comment - Once we get it up and running, we likely can just commit and then check the staging site more importantly: for most small changes (adding new committers, posting release announcements, etc...) the CMS bookmarklet (which lets you edit live pages from your browser) will probably be all you'll ever need to use https://cms.apache.org/
          Hide
          Grant Ingersoll added a comment -

          On the java side of things, moving all of the per-release docs into the javadoc process (using the doc-files dir, and linking to them from overview.html) would be one good way to keep everything encapsulated nicely.

          I like the thought of moving those things into Javadocs, but it still means converting from Forrest to another format, although it likely isn't that hard to do, given we could render it as HTML and then cut and paste the pertinent content (minus the boilerplate) over to javadoc html.

          Show
          Grant Ingersoll added a comment - On the java side of things, moving all of the per-release docs into the javadoc process (using the doc-files dir, and linking to them from overview.html) would be one good way to keep everything encapsulated nicely. I like the thought of moving those things into Javadocs, but it still means converting from Forrest to another format, although it likely isn't that hard to do, given we could render it as HTML and then cut and paste the pertinent content (minus the boilerplate) over to javadoc html.
          Hide
          Grant Ingersoll added a comment -

          This is shaping up nicely. I've got a fair bit of the look and feel ironed out and it isn't half bad looking, IMO.

          What needs to be done now:

          1. Flesh out the rest of the mantle (slide) images for the top level and sub project sites (so they aren't all the same)
          2. Clean up some transparency issues in the Lucene logo at the top of the page
          3. Get the rest of the main site content moved over
          4. Move over PyLucene and ORP
          5. Prepare the old sites to be moved per the placeholders in the new site
          6. Add in a news section to the site
          7. Fill in missing links, etc. and do a copy edit on the content

          I think if we can get most of these done soon, it would be in good enough shape to migrate.

          Show
          Grant Ingersoll added a comment - This is shaping up nicely. I've got a fair bit of the look and feel ironed out and it isn't half bad looking, IMO. What needs to be done now: Flesh out the rest of the mantle (slide) images for the top level and sub project sites (so they aren't all the same) Clean up some transparency issues in the Lucene logo at the top of the page Get the rest of the main site content moved over Move over PyLucene and ORP Prepare the old sites to be moved per the placeholders in the new site Add in a news section to the site Fill in missing links, etc. and do a copy edit on the content I think if we can get most of these done soon, it would be in good enough shape to migrate.
          Hide
          Grant Ingersoll added a comment -

          News is hooked in. Taking a break. If others want to jump in on the other items, it would be most appreciated.

          Show
          Grant Ingersoll added a comment - News is hooked in. Taking a break. If others want to jump in on the other items, it would be most appreciated.
          Hide
          Mark Miller added a comment -

          stuck in directory hell for a while, but I popped off #2 real quick.

          Show
          Mark Miller added a comment - stuck in directory hell for a while, but I popped off #2 real quick.
          Hide
          Grant Ingersoll added a comment -

          I'm hooking in Google Analytics, which ASF says is fine as long as we publish a privacy policy. If you are a committer and want access to the info and are willing to comply with the ASF privacy policy, please send me your Google account name.

          Show
          Grant Ingersoll added a comment - I'm hooking in Google Analytics, which ASF says is fine as long as we publish a privacy policy. If you are a committer and want access to the info and are willing to comply with the ASF privacy policy, please send me your Google account name.
          Hide
          Grant Ingersoll added a comment -

          #4 above, migrate PyLucene and ORP is more or less done. Those on PyLucene may wish to do more.

          Show
          Grant Ingersoll added a comment - #4 above, migrate PyLucene and ORP is more or less done. Those on PyLucene may wish to do more.
          Hide
          Grant Ingersoll added a comment -

          #6 is also done

          #1 is going to take some graphic design skills, I think, to make interesting images.

          Show
          Grant Ingersoll added a comment - #6 is also done #1 is going to take some graphic design skills, I think, to make interesting images.
          Hide
          Grant Ingersoll added a comment -

          #3 is done. Need to clean up how news gets included on pages

          Show
          Grant Ingersoll added a comment - #3 is done. Need to clean up how news gets included on pages
          Hide
          Param Sethi added a comment -

          I tested home page on IE8 and here are few UI issues that I found. Some of them are trivial.

          Here are list of issues:
          1. Javascript error on page load. Details in the Google doc
          2. Menu bar looks different than ff5
          3. Text Transitions are not smooth as FF5. Intermediate states are visible for about 1 sec.
          4. Top right text box size is different than drop down.
          5. Header Text appears to be cut off from the bottom. Visible on "Large, Vibrant community"

          I have consolidated the list of issues with screenshots at https://docs.google.com/document/d/1VMes9KPBSXuCQdhSVuI-cw0L9bNfq-QwJ7pzKRYhAZY/edit?hl=en_US

          Show
          Param Sethi added a comment - I tested home page on IE8 and here are few UI issues that I found. Some of them are trivial. Here are list of issues: 1. Javascript error on page load. Details in the Google doc 2. Menu bar looks different than ff5 3. Text Transitions are not smooth as FF5. Intermediate states are visible for about 1 sec. 4. Top right text box size is different than drop down. 5. Header Text appears to be cut off from the bottom. Visible on "Large, Vibrant community" I have consolidated the list of issues with screenshots at https://docs.google.com/document/d/1VMes9KPBSXuCQdhSVuI-cw0L9bNfq-QwJ7pzKRYhAZY/edit?hl=en_US
          Hide
          Andi Vajda added a comment -

          Thank you Grant for getting this going.

          #4 above, migrate PyLucene and ORP is more or less done. Those on PyLucene may wish to do more.

          I did a quick check for PyLucene: some fonts are HUGE and the entire jcc section (accessible from a tab in the old site) is gone.
          I hope to be able to get to this within a week or two...

          Show
          Andi Vajda added a comment - Thank you Grant for getting this going. #4 above, migrate PyLucene and ORP is more or less done. Those on PyLucene may wish to do more. I did a quick check for PyLucene: some fonts are HUGE and the entire jcc section (accessible from a tab in the old site) is gone. I hope to be able to get to this within a week or two...
          Hide
          Andi Vajda added a comment -

          I made some progress today:

          • setup local copy of site with the software needed to generate it
          • hooked up missing pylucene/jcc content and templates
          • checked in rev 1160081
            I still need to go through all the content and make sure all links and formatting
            are correct. And last but not least, I need to mess with the .css so that the pages
            are legible, links visible, fonts balanced, etc...
            Is there a plan to have a global CSS for all pages or is this left up to each area ?
          Show
          Andi Vajda added a comment - I made some progress today: setup local copy of site with the software needed to generate it hooked up missing pylucene/jcc content and templates checked in rev 1160081 I still need to go through all the content and make sure all links and formatting are correct. And last but not least, I need to mess with the .css so that the pages are legible, links visible, fonts balanced, etc... Is there a plan to have a global CSS for all pages or is this left up to each area ?
          Hide
          Hoss Man added a comment -

          And last but not least, I need to mess with the .css so that the pages
          are legible, links visible, fonts balanced, etc...
          Is there a plan to have a global CSS for all pages or is this left up to each area ?

          I think one of the goals was to try and make the entire "Lucene" site more consistent in it's look/feel/navigation (and if it wasn't, then i vote for it to be a goal) so i would say having a global css for the entire site is wise – particularly if you're seeing problems with legibility, visibility, and fonts. we should fix that everywhere.

          Show
          Hoss Man added a comment - And last but not least, I need to mess with the .css so that the pages are legible, links visible, fonts balanced, etc... Is there a plan to have a global CSS for all pages or is this left up to each area ? I think one of the goals was to try and make the entire "Lucene" site more consistent in it's look/feel/navigation (and if it wasn't, then i vote for it to be a goal) so i would say having a global css for the entire site is wise – particularly if you're seeing problems with legibility, visibility, and fonts. we should fix that everywhere.
          Hide
          Andi Vajda added a comment -

          I completely agree, there should one css for the whole site. Consistent look and feel is a good thing. Currently, this is not how it's setup, each template gets its own .css.
          That would simple to change, of course.

          Ok, I'm going to try to tweak the pylucene.css to something more legible (I'm as incompetent with .css as anyone but I can copy/paste). Once I like what I see, I'll commit that and the
          other templates are welcome to adopt it.

          If someones feel like intervening there first, by all means

          Show
          Andi Vajda added a comment - I completely agree, there should one css for the whole site. Consistent look and feel is a good thing. Currently, this is not how it's setup, each template gets its own .css. That would simple to change, of course. Ok, I'm going to try to tweak the pylucene.css to something more legible (I'm as incompetent with .css as anyone but I can copy/paste). Once I like what I see, I'll commit that and the other templates are welcome to adopt it. If someones feel like intervening there first, by all means
          Hide
          Jeremy Bolanos added a comment -

          Here is my first pass at modifying the UI to be more consistent across templates. Cleaned up the footer and adjusted the content in the slideshow.

          Show
          Jeremy Bolanos added a comment - Here is my first pass at modifying the UI to be more consistent across templates. Cleaned up the footer and adjusted the content in the slideshow.
          Hide
          Mark Miller added a comment -

          Thanks Jeremy! I've committed this.

          Show
          Mark Miller added a comment - Thanks Jeremy! I've committed this.

            People

            • Assignee:
              Grant Ingersoll
              Reporter:
              Grant Ingersoll
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development