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. 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.
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]> > 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) >>>>>> >>>>> >>>>> >>> >>> >>
