Le dim. 23 août 2020 à 20:26, David Jencks <[email protected]> a écrit :
> Let’s not try to do everything at once. For me the next step is getting > the site build/publishing working. My question about a separate mailing > list is the next sub-step. > +1 I’m having some medical problems so may not be able to do much on this for > a few days, but resolving any answer to the mailing list quest would be > helpful. > Take care, site does not urge ;) > David Jencks > > Sent from my iPhone > > > On Aug 23, 2020, at 9:41 AM, Romain Manni-Bucau <[email protected]> > wrote: > > > > With Ray on that. > > > > Le dim. 23 août 2020 à 15:11, Raymond Auge <[email protected] > .invalid> > > a écrit : > > > >> Sigh, I had hoped the Aries site sources would be in the main aries > repo. I > >> hate to be combative, but I feel we had consensus to do just that in the > >> beginning of this process. Now we're just in the same boat as before, no > >> one will update the site when source code is modified... > >> > >> - Ray > >> > >>> On Sat., Aug. 22, 2020, 7:05 p.m. David Jencks, < > [email protected]> > >>> wrote: > >>> > >>> Progress: > >>> > >>> - CMS content history and initial antora migration is in the > >>> aries-antora-site repo > >>> - Published site history is in aries-site-pub repo > >>> - html pages from CMS and those in the published site (except for > >>> duplicates) are now visible in Antora site. They don’t all look great, > >> but > >>> they are there. > >>> - javadoc pages are also in the site and accessible > >>> - I think the nav has all the pages except javadoc > >>> - I constructed an .htaccess file which redirects from all locations > from > >>> the old site to the new site, including the xsd urls. This does not > >>> include the apparent mistakes of duplicate files. > >>> - The not-found pages for .htaccess are listed in the aries-antora > >> project > >>> in dot-htaccess-not-found > >>> - I added a package.json and playbook for building the content that > >>> happens to be in the aries-antora-site repo locally. This will be one > of > >>> many, don’t think it can be used for building the site. > >>> - I started on a script to publish to aries-site-pub repo. > >>> > >>> Next steps: > >>> > >>> - I don’t think we want commits to aries-site-pub to go to the commits > >>> list, having source updates from aries-antora-site will be more than > >>> enough. Infra requires commit emails go somewhere, and they suggested > >>> setting up a list just for this. I think this is a fine idea, how > about > >>> aries-site-pub for the list name? > >>> > >>> - when this issue of where the emails go is resolved I’ll work more on > >> the > >>> publish script; I’m hoping it will be straightforward to get the script > >>> working locally, figure out an asf.yml to publish to a preview site. > At > >>> this point I’ll point out the preview. > >>> > >>> - next, figure out how to run the script on ASF hardware. I think > >> there’s > >>> a requirement that only PMC members can cause the site to be published, > >> so > >>> I don’t think it can work off a commit trigger. > >>> > >>> - at some point I’ll write some instructions in README.adoc files. > >>> > >>> Comments: > >>> > >>> - I think we can take advantage of Antora’s multi-version capabilities > by > >>> tagging something like the current state (in aries-antora-site) as > >> “legacy” > >>> and keeping that as a version. On master we can delete obsolete > content, > >>> but it will still be visible in the legacy version. We could mark > >> content > >>> to be deleted with a header attribute ‘obsolete’ and generate a list of > >>> these pages while we consider. (cf. auto-index.adoc). > >>> > >>> - I think the utility of the per-source-repo ‘author-mode’ builds is a > >>> stronger argument for keeping the ui in a separate repo than my strong > >>> personal preference to do so. We’re shortly going to have > >>> (subproject-count) + 2 repos with playbooks in them, and any argument > for > >>> putting the UI in one is just about as strong as for another…… very > weak > >>> IMO. I suggest you try out the current arrangement before rejecting > it. > >>> It will get easier when I write some docs. > >>> > >>> The next steps are, I think, going to involve pushing the new build > site > >>> to aries-site-pub, so we need to either agree that commit emails going > to > >>> [email protected] are fine or agree to set up another list. > >>> > >>> David Jencks > >>> > >>>> On Aug 21, 2020, at 11:18 PM, Romain Manni-Bucau < > >> [email protected]> > >>> wrote: > >>>> > >>>> Still think playbook and ui module must be merged. > >>>> Both will never be released anyway and it makes things easier. > >>>> > >>>> Site history should just be a folder imo, not a repo... > >>>> > >>>> > >>>> Le sam. 22 août 2020 à 02:11, David Jencks <[email protected]> > >> a > >>>> écrit : > >>>> > >>>>> A couple more comments on playbooks… > >>>>> > >>>>> Since IIUC we’re planning to add docs for all the more recent > >>> subprojects > >>>>> that each live in their own repo, to those repos, the “production” > >>> playbook > >>>>> can’t prefer one over the others and be in a content repo. > >>>>> > >>>>> However, we can easily provide a “preview” playbook in each repo for > >>>>> building just the content in that repo, to check local changes in > >> more > >>>>> detail than in the IntelliJIDEA asciidoctor plugin. > >>>>> > >>>>> David Jencks > >>>>> > >>>>>> On Aug 21, 2020, at 3:18 PM, David Jencks <[email protected] > > > >>>>> wrote: > >>>>>> > >>>>>> Here are the repos and why they should be separate: > >>>>>> > >>>>>> aries-antora-site. This contains the content migrated from CMS. It > >>>>> might be possible to migrate all of these into the repos that have > the > >>>>> related source code, but I don’t think that’s really appropriate for > >>> stuff > >>>>> about the community, board reports, etc. In any case that’s a step > >> for > >>>>> after the new web site is working. Generally this is what you’d > >> modify > >>>>> when working on documentation improvements. > >>>>>> > >>>>>> aries-antora. This contains the playbook. Antora works without a > >>>>> checked out copy of the source .adocs, but the playbook does need to > >> be > >>>>> checked out. Therefore this needs to be a separate project. It’s > >>> possible > >>>>> to put this in with the sources, but it’s a bad idea IMO. Generally > >>> this > >>>>> is going to be modified only when a new subproject is added to the > >>>>> documentation, or, if we decide on versioned documentation for some > >>>>> components, possibly when a new version is published (although most > >>> likely > >>>>> this can be handled by wildcards). > >>>>>> > >>>>>> aries-antora-ui. The content here is almost all MPL2.0 licensed. I > >>>>> checked on legal discuss, and the consensus was that it was fine to > >> have > >>>>> such content in an Apache repo as long as it never becomes part of a > >>>>> release. In order to make the licensing more obvious, I think it’s > >>>>> imperative to keep this in a separate repo that we can prominently > >> label > >>>>> “don’t release anything from this repo”. I think few people are > going > >>> to > >>>>> work on this, and as it will change infrequently we’d save some build > >>> time > >>>>> and automation complexity by keeping it separate. > >>>>>> > >>>>>> aries-site-pub. This currently contains the CMS site history, and > is > >>>>> going to be where the new build process commits the site to publish > >>> it. No > >>>>> one should be modifying it by hand. > >>>>>> > >>>>>> David Jencks > >>>>>> > >>>>>>> On Aug 21, 2020, at 6:07 AM, Raymond Auge < > [email protected] > >>> .INVALID> > >>>>> wrote: > >>>>>>> > >>>>>>> Personally, I would really appreciate only having to work with the > >>> main > >>>>>>> source repo and at most with the sub project repos. Having the site > >>>>> tech in > >>>>>>> multiple repos serves only to annoy me (and I feel anyone) that > >> wants > >>> to > >>>>>>> provide quick fixes or just ramp up on updating docs due to a > higher > >>>>>>> barrier for testing. > >>>>>>> > >>>>>>> That's my opinion at least. I had assumed the multiple repos you > >> used > >>>>> David > >>>>>>> were merely for testing (I also do understand the publish repo that > >>>>> holds > >>>>>>> the built site...) > >>>>>>> > >>>>>>> - Ray > >>>>>>> > >>>>>>> On Fri, Aug 21, 2020 at 3:05 AM Romain Manni-Bucau < > >>>>> [email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Le ven. 21 août 2020 à 08:36, David Jencks < > >> [email protected] > >>>> > >>>>> a > >>>>>>>> écrit : > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On Aug 20, 2020, at 11:17 PM, Romain Manni-Bucau < > >>>>>>>> [email protected]> > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> Le ven. 21 août 2020 à 08:15, David Jencks < > >>> [email protected] > >>>>>>>>> <mailto:[email protected]>> a > >>>>>>>>>> écrit : > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> On Aug 17, 2020, at 10:43 PM, Romain Manni-Bucau < > >>>>>>>>> [email protected]> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Le mar. 18 août 2020 à 02:24, David Jencks < > >>>>> [email protected] > >>>>>>>>> > >>>>>>>>> a > >>>>>>>>>>>> écrit : > >>>>>>>>>>>> > >>>>>>>>>>>>> I’ve created 4 repos at Apache for this and started to move > >> the > >>>>>>>>> content > >>>>>>>>>>> to > >>>>>>>>>>>>> them. > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Why 4? Dont we only need the build and publish ones if we put > >>> docs > >>>>> in > >>>>>>>>>>> each > >>>>>>>>>>>> code repo? Theme should probably stay with build one to avoid > >> to > >>>>> make > >>>>>>>>> it > >>>>>>>>>>>> complex since we couple them anyway. > >>>>>>>>>>> > >>>>>>>>>>> Well, I’ve had 3 all along, and the 4th is to publish to. I > >> much > >>>>>>>> prefer > >>>>>>>>>>> keeping all the separate aspects in separate repos. > >>>>>>>>>>> At the moment I’m waiting on infra for > >>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-20724 < > >>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-20724 < > >>>>>>>>> https://issues.apache.org/jira/browse/INFRA-20724>>. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Any reason? It just adds complexity and slows down the build > >>>>> (multiple > >>>>>>>>> hits) > >>>>>>>>> > >>>>>>>>> If you’re building locally, the UI is downloaded when you run npm > >> i > >>>>> (or > >>>>>>>>> preferably nom run clean-install). If they are in one repo, you > >>> have > >>>>> to > >>>>>>>>> build the UI every time to be sure it’s up to date. If it’s > >>>>> referenced > >>>>>>>> in > >>>>>>>>> an already built state, that’s much faster. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Not really, generally all frontend projects push the build state > so > >>> you > >>>>>>>> just reference the built state and when you change it, rebuild it > >>>>> locally > >>>>>>>> and update the pushed state so this is not an issue IMHO. > >>>>>>>> Issue is keep synchronizing repos for nothing or having to clone N > >>>>> repo to > >>>>>>>> work on the website locally. Any indirection increases the entry > >> cost > >>>>> ;). > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> However, I find that keeping the UI, playbook, and sources in > >>>>> different > >>>>>>>>> repo helps keep my thinking more organized, which is far more > >>>>> important > >>>>>>>> to > >>>>>>>>> me than slight time savings. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Source and build repo yes, but UI and playbook don't need to be > >> split > >>>>> at > >>>>>>>> all and from experience, when it is not reusable - our case - it > is > >>>>> saner > >>>>>>>> to keep them in the same repo so I think we should merge it. > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> David Jencks > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> One repo, aries-site-pub, is for publishing the built site > >> from. > >>>>>>>>>>> Locally > >>>>>>>>>>>>> I used svn2git to get the whole history of the published site > >>> out > >>>>> of > >>>>>>>>>>> svn. > >>>>>>>>>>>>> Infra doesn’t seem to recommend doing this, but I think it > >> will > >>> be > >>>>>>>>>>>>> extremely handy to be able to see the history in one place > >>> without > >>>>>>>>>>> having > >>>>>>>>>>>>> to deal with svn. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I’ve already realized that > >>>>>>>>>>>>> > >>>>>>>>>>>>> - there are a bunch of schemas to serve. These can go in an > >>>>>>>>> attachments > >>>>>>>>>>>>> directory. > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> We have some per project so likely a folder per module or just > >>>>>>>> specific > >>>>>>>>>>>> links outside antora since we should never delete one, no? > >>>>>>>>>>> > >>>>>>>>>>> I realized I already put them in attachments, I just didn’t > know > >>>>> about > >>>>>>>>> the > >>>>>>>>>>> redirects. If we end up docs for blueprint, jpa, etc. in the > >> repo > >>>>> the > >>>>>>>>> code > >>>>>>>>>>> is in we can move the schemas too and have yet more redirects. > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> - there’s an existing .htaccess file with a few redirects, and > >> we > >>>>>>>> need > >>>>>>>>>>> one > >>>>>>>>>>>>> that also shows the new location of every previously existing > >>>>> page. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I’ll work on this… > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I’m most of the way to having a reasonable .htaccess. > >>>>>>>>>>> > >>>>>>>>>>>> Sounds great, we keep httpd right? > >>>>>>>>>>> > >>>>>>>>>>> I don’t think we have a choice about that :-) anyway I have no > >>>>>>>> problems > >>>>>>>>>>> with it… > >>>>>>>>>>> > >>>>>>>>>>>> Thans a lot David. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Thanks > >>>>>>>>>>> David Jencks > >>>>>>>>>>>> > >>>>>>>>>>>>> David Jencks > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Aug 14, 2020, at 9:54 AM, David Jencks < > >>>>>>>> [email protected]> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I updated the feather to the current svg version, adjusted > >> the > >>>>>>>>> spacing > >>>>>>>>>>> a > >>>>>>>>>>>>> bit, and added some basic instructions to the UI project. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> David Jencks > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Aug 13, 2020, at 12:29 AM, Romain Manni-Bucau < > >>>>>>>>>>> [email protected] > >>>>>>>>>>>>> <mailto:[email protected]>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Starts to look very good, some sizing and the feather to > >>> change > >>>>> to > >>>>>>>>>>> have > >>>>>>>>>>>>> a better quality and I think it is at least as good as the > >>> website > >>>>>>>> we > >>>>>>>>>>> have > >>>>>>>>>>>>> today. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Romain Manni-Bucau > >>>>>>>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog < > >>>>>>>>>>>>> https://rmannibucau.metawerx.net/> | Old Blog < > >>>>>>>>>>>>> http://rmannibucau.wordpress.com/> | Github < > >>>>>>>>>>>>> https://github.com/rmannibucau> | LinkedIn < > >>>>>>>>>>>>> https://www.linkedin.com/in/rmannibucau> | Book < > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Le mer. 12 août 2020 à 14:38, Andrew Wetmore < > >>>>> [email protected] > >>>>>>>>>>>>> <mailto:[email protected]>> a écrit : > >>>>>>>>>>>>>>> Hi, David! > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Glad to know you are moving forward. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> We need, for each project: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - a formal decision by the PMC approving the move and the > >> tech > >>>>>>>> you > >>>>>>>>>>>>> are > >>>>>>>>>>>>>>> moving to. > >>>>>>>>>>>>>>> - a Jira ticket for INFRA so we have an audit trail on what > >> we > >>>>>>>> are > >>>>>>>>>>>>> doing > >>>>>>>>>>>>>>> and when. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thank you for pointing out Antora. I will add it to our > >> list! > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I will forward your other questions to our team, who are > >> much > >>>>> more > >>>>>>>>>>>>>>> knowledgeable than I on the migration. Basically, whoever > >>> picks > >>>>> up > >>>>>>>>>>> your > >>>>>>>>>>>>>>> Jira ticket will facilitate the move. As far as I know, > >>> keeping > >>>>>>>>>>>>> repository > >>>>>>>>>>>>>>> history is not a problem. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> A good way to contact me/us in near-real-time is to join > >>>>> #asfinfra > >>>>>>>>> on > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>> ASF Slack channel (https://the-asf.slack.com/ < > >>>>>>>>>>>>> https://the-asf.slack.com/>). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I am confident this will go pretty smoothly! > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Andrew > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Virus-free. > >>>>>>>>>>>>>>> www.avast.com <http://www.avast.com/> > >>>>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Wed, Aug 12, 2020 at 2:44 AM David Jencks < > >>>>>>>>>>> [email protected] > >>>>>>>>>>>>> <mailto:[email protected]>> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi Andrew, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I think I’m going to be setting up the new Aries website. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> We’re going to use Antora to build the site. I’m a bit > >>>>> surprised > >>>>>>>>>>> that > >>>>>>>>>>>>>>>> this tool isn’t on your list of common site builders, at > >>> least > >>>>>>>>> Camel > >>>>>>>>>>>>> and > >>>>>>>>>>>>>>>> Isis use it. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I’m also going to be working to move TomEE off of CMS, > that > >>>>> site > >>>>>>>> is > >>>>>>>>>>>>> likely > >>>>>>>>>>>>>>>> to be partly Antora and partly something else. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Something both projects are interested in is preserving > the > >>>>>>>> history > >>>>>>>>>>>>> of the > >>>>>>>>>>>>>>>> website. I think this could be done by running svn2git on > >>> the > >>>>>>>>>>>>> appropriate > >>>>>>>>>>>>>>>> svn url, could you help figure out what that url would be? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> When are you generally available and what is a good way to > >>>>>>>> contact > >>>>>>>>>>>>> you for > >>>>>>>>>>>>>>>> faster than email questions? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thanks > >>>>>>>>>>>>>>>> David Jencks > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Aug 4, 2020, at 6:33 AM, Andrew Wetmore< > >>> [email protected] > >>>>>>>>>>>>> <mailto:[email protected]>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I am part of the Infrastructure team, and am writing to > >> ask > >>>>>>>>> whether > >>>>>>>>>>>>> your > >>>>>>>>>>>>>>>>> project is still using the Apache CMS for your project > >>>>> website. > >>>>>>>> As > >>>>>>>>>>>>> you > >>>>>>>>>>>>>>>>> know, the CMS is reaching end-of-life, and we need > >> projects > >>> to > >>>>>>>>> move > >>>>>>>>>>>>> their > >>>>>>>>>>>>>>>>> websites onto a different option within the next few > >> weeks. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> There are several alternatives available, including those > >>>>> listed > >>>>>>>>> on > >>>>>>>>>>>>> this > >>>>>>>>>>>>>>>>> page [1] on managing project websites. Infra is > >> assembling a > >>>>>>>> Wiki > >>>>>>>>>>>>> page > >>>>>>>>>>>>>>>> [2] > >>>>>>>>>>>>>>>>> on migrating a website from the CMS, and is looking > >> forward > >>> to > >>>>>>>>>>>>> helping > >>>>>>>>>>>>>>>>> projects with this transition. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Please let me know whether your site is still on the > >> Apache > >>>>> CMS > >>>>>>>>>>>>> and, if > >>>>>>>>>>>>>>>> so, > >>>>>>>>>>>>>>>>> who will be the project point-of-contact with Infra for > >> the > >>>>>>>>>>>>> migration. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thank you! > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> [1] https://infra.apache.org/project-site.html < > >>>>>>>>>>>>> https://infra.apache.org/project-site.html> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> [2] > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS > >>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://cwiki.apache.org/confluence/display/INFRA/Migrate+your+project+website+from+the+Apache+CMS > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>> Andrew Wetmore > >>>>>>>>>>>>>>>>> Technical Writer-Editor > >>>>>>>>>>>>>>>>> Infra > >>>>>>>>>>>>>>>>> *Apache Software Foundation* > >>>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Virus-free. > >>>>>>>>>>>>>>>>> www.avast.com <http://www.avast.com/> > >>>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >>>>>>>>>>>>> < > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>> > >>> > >> > https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>> Andrew Wetmore > >>>>>>>>>>>>>>> Technical Writer-Editor > >>>>>>>>>>>>>>> Infra > >>>>>>>>>>>>>>> *Apache Software Foundation* > >>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > >>>>>>> (@rotty3000) > >>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > >>>>>>> (@Liferay) > >>>>>> > >>>>> > >>>>> > >>> > >>> > >> >
