Apache CMS doesn't support the build for the new website. The new site uses a number of tools to build the static site. These include bower, assemble, compass, etc to download front end components, assemble the pages, and perform css pre processing. We certainly could take the built site and manually upload via the CMS UI. However, it would be preferable in my opinion to be able to automate that or do so by committing the content directly.
I have committed the files via svn [1] and it wasn't clear how that fit into the existing CMS UI -> Staging -> Publish work flow. What I committed appeared in the staging repository and would be reflected when the site was published. However, the files never ended up in the CMS UI. I'm not sure the work flow intends to support modifications outside the UI. Hence the INFRA comments about ditching CMS with the external build. I could be wrong, I'll try to clarify this with them before it's ditched entirely. Anyways, I think having the site content co-located with our sources makes site updates more accessible to everyone. [1] https://svn.apache.org/repos/infra/websites/staging/nifi/trunk On Thu, Mar 26, 2015 at 9:13 PM, Tony Kurc <[email protected]> wrote: > maybe I'm missing something, but this doesn't seem to be that much > different than using Apache CMS exclusively via svn, like the initial > commits I did. couldn't we be doing something similar now? > > On Thu, Mar 26, 2015 at 9:04 PM, Matt Gilman <[email protected]> > wrote: > > > So I've been in contact with INFRA [1]. They've explained that we can > ditch > > CMS entirely. By going this route we will no longer be able to edit the > > site online (through the Apache CMS tool) or have the staging > capabilities. > > We would be committing the site into a svn/git repository and it would be > > available immediately (no staging). What this means is that the staging > is > > going to be done by the person updating the site on the machine they are > > building on. Once they are comfortable they would deploy the updates by > > committing into the svn/git repository. The mechanics of this commit > > haven't been entirely worked out because I didn't know the particulars > > regarding CMS if we opted for an external build. I am thinking that it > can > > be scripted or integrated into the build tool (grunt). > > > > Additionally, the NiFi maven build could also commit to this svn/git > > repository to automate the deployment of our user/admin/etc guides. There > > is currently some discussion about how to automate the deployment of > > component documentation at build time. Once that is decided, we could > > automate their deployment as well. > > > > Please let me know if there is any opposition to this approach. If I > don't > > hear anything I am going to continue proceeding down this path. > > > > [1] https://issues.apache.org/jira/browse/INFRA-9291 > > > > On Sat, Mar 21, 2015 at 11:25 AM, Matt Gilman <[email protected]> > > wrote: > > > > > I have not begun working on anything generated from the nifi build yet > > > (items identified in that ticket). My focus was on the website side of > > > things and I am currently in a holding pattern. It seems that the > > > referenced ticket is looking for a workaround in the meantime. > > > > > > Without knowing more, I was thinking that once everything was set up > for > > > the website's external build we could use maven to commit the specified > > > artifacts (maybe something like [1]) into the website's SVN repository > > and > > > eliminate the need to generate a tarball that someone would manually > have > > > to upload like we're doing today. > > > > > > Matt > > > > > > [1] http://maven.apache.org/scm/maven-scm-plugin/checkin-mojo.html > > > > > > On Sat, Mar 21, 2015 at 11:12 AM, Joe Witt <[email protected]> wrote: > > > > > >> Matt > > >> > > >> Rgr that. There are several tickets open which could be part of this > > >> work: > > >> > > >> > > >> > > > https://issues.apache.org/jira/browse/NIFI-445?jql=project%20%3D%20NIFI%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20text%20~%20%22website%22 > > >> > > >> Which one are you working on? Perhaps we can divide and conquer. > > >> There are a lot of updates in v1 that are not yet reflected in V2. > > >> Plus in V2 we need an updated image. So perhaps folks will contribute > > >> if we can document the needs on the ticket. > > >> > > >> Thanks > > >> Joe > > >> > > >> On Sat, Mar 21, 2015 at 11:08 AM, Matt Gilman < > [email protected]> > > >> wrote: > > >> > I've sent a couple emails which dev was CC'ed on. Since I wasn't > > hearing > > >> > anything there, I opened a JIRA ticket with them as well [1]. There > > has > > >> > been no activity on it yet. I was not aware of any INFRA chatroom. > > >> > > > >> > It sounds like when configured for an external build, we just need > to > > >> > commit the website to the SVN repository. It's not clear however, if > > >> there > > >> > is still a staging phase or if it's immediately published. These are > > >> > questions I've asked in emails and in the ticket. The idea is that > the > > >> > website and the application build would be separate but would commit > > to > > >> the > > >> > same repository so the documentation and the website can be can be > > >> updated > > >> > and deployed independently. > > >> > > > >> > [1] https://issues.apache.org/jira/browse/INFRA-9291 > > >> > > > >> > On Sat, Mar 21, 2015 at 10:45 AM, Joe Witt <[email protected]> > > wrote: > > >> > > > >> >> Matt, Aldrin, > > >> >> > > >> >> Just specifying you in particular since you were both actively > > engaged > > >> >> on it. But this is really for everyone: > > >> >> > > >> >> Can we reengage on the website v2 effort? I believe the last > thing I > > >> >> saw is that some important ticket or action was held up in INFRA. > I > > >> >> know that INFRA has a chatroom they are available in. I think > > >> >> generally if they fall behind or something falls through the cracks > > >> >> they don't mind a ping. > > >> >> > > >> >> One thing with the change I know was part of the motivation was an > > >> >> easier/more direct path to making updates. That part wasn't > totally > > >> >> clear to me so will be curious to hear more about how that will > work. > > >> >> As Dan or others have pointed out we need to get a more direct line > > >> >> from doc changes to getting them deployed. And ideally we'd have > the > > >> >> extensions all up there as well. > > >> >> > > >> >> Anyway - just want to get a view on where this is at. > > >> >> > > >> >> Thanks > > >> >> Joe > > >> >> > > >> > > > > > > > > >
