I think I wasn’t clear about which issue I was talking about. I was talking about whether we have an .htaccess file with redirects for all the old page locations (what I want) or keep the old pages in their old locations, with no visible means of having generated them (which is my understanding of what you want, and which I haven’t seen anyone else support).
I haven’t figured out how to do it yet, and don’t think it’s time yet, but I have no problem in principle with moving most or all of the content into the main git repository from what is now aries-antora-site. Thanks, David Jencks > On Sep 1, 2020, at 11:06 PM, Romain Manni-Bucau <[email protected]> wrote: > > Le mar. 1 sept. 2020 à 19:28, David Jencks <[email protected]> a > écrit : > >> Romain, >> >> This issue is keeping me from wanting to work more on the site. I >> attempted a survey on antora/users gitter channel and only got one >> response, which agreed with my position. Can you find any outside opinion >> that supports your position? >> > > We are at least two on three participating in aries and already agreed with > outside people on such arch in other companies (past colleagues) so yes. > > Once again, only reason to split - all other concerns have simple solutions > - is reusability and we will not do it by design. > > >> I’m not interested in working on a site with your proposed solution. >> Since you are more likely than I to participate in the future to evolving >> the site, I suggest that we proceed by me setting up redirects (already >> done in the preview), getting the site deployed, organizing things a bit, >> and when I’ve run out of things to do you can, if the community agrees, put >> in place your proposal. Otherwise, I can stop now. >> > > Have to admit i fail to see what you dislike. It is technically exactly the > same proposal except in terms of storage and i dont think you abandon for a > "mv". Maybe Im missing sthg key :s. > > >> Thoughts? >> >> David Jencks >> >>> On Aug 27, 2020, at 10:43 PM, Romain Manni-Bucau <[email protected]> >> wrote: >>> >>> Le jeu. 27 août 2020 à 23:30, David Jencks <[email protected] >> <mailto:[email protected]>> a >>> écrit : >>> >>>> >>>> >>>>> On Aug 26, 2020, at 11:01 PM, Romain Manni-Bucau < >> [email protected]> >>>> wrote: >>>>> >>>>> Le jeu. 27 août 2020 à 00:22, David Jencks <[email protected]> >> a >>>>> écrit : >>>>> >>>>>> I think this is a really really bad idea and will try to explain why >>>>>> later…. I did’t want it to seem like I was ignoring this since I >>>> replied to >>>>>> my previous message. >>>>>> >>>>>> I would like to know why you don’t like redirect rules; AFAICT they >> are >>>>>> universally used for site updates. Maybe you can convince me I’m >> wrong >>>> :-) >>>>>> >>>>> >>>>> Because >>>>> >>>>> 1. You must maintain them if you change anything (and we will forget >>>> about >>>>> them for sure very very quickly and link validation is not enough to >>>> fully >>>>> validate it - and to add a more "personal" note: it hurts lol) >>>> >>>> Possibly we don’t need to maintain it. I have it set up to work now, >>>> AFAICT, with all content from the old site and the current new >> locations. >>>> Since Antora supports multiple versions of each component very well, one >>>> possibility is to copy the current content to a branch/version called >>>> ‘legacy’ and have .htaccess point there. All subsequent changes can be >> on >>>> ‘master’ version (or whatever we decide). Then links to the old website >>>> will go to the new location of the old version of the page, and updates >> are >>>> accessible through the version selector. >>>> >>>> IMO with a simple tool maintaining .htaccess is not that unpleasant. I >>>> wrote it for camel and after a little updating it worked here too. >>>> Admittedly I don’t know of a way to test it thoroughly, but it certainly >>>> redirects all the existing website addresses. >>>> >>> >>> -1, content is there to not break existing links but not as something >> which >>> must be accessible. >>> Integrating in antora will make it slower and accessible whereas it is >> not >>> intented at all. >>> >>> >>> >>>>> 2. Cause we dont need it at all >>>> >>>> I totally disagree… see below >>>> >>> >>> Hmm, i can say the same I guess ;) >>> >>> >>>> >>>>> Keep in mind we speak of a static website so can keep static resources >>>>> around without any issue and we dont conflict with antora namind - >> except >>>>> main index, so no need to stack layers and increase maintenance cost >> for >>>> no >>>>> gain IMHO. >>>> >>>> I have two main objections to this point of view. >>>> >>>> 1. I think you used this strategy on the current TomEE website, leaving >>>> the old CMS content in place but not very accessible and adding new >> JBake >>>> generated content that was mostly a copy (or 3 copies, I don’t know if >> you >>>> did that part). When I discovered the old content my reaction was >> something >>>> like ‘AAAAAARGH! Are these guys amateurs or what? Can’t they maintain >> their >>>> website? Why are there 2 totally unrelated styles???? I don’t trust >>>> anything about this project! I’m running away!’ In other words, I think >>>> that it’s essential for users to see everything on the site accessible >>>> through one unified mechanism and displayed consistently. >>>> >>> >>> TomEE was a different story. >>> Old website was intended to be dead cause it was already outdated, wrong >> - >>> from multiple migrations, and inconsistent. >>> As discussed on the list we agreed to not maintain it and just move to >> the >>> new website. We kept it around for a kind of testing peruod. >>> After some time and some good feedbacks, a missing page made a lot of >> noise >>> to reactivate the whole old website, current status is most links are >>> broken and content is fully broken (mainly css last time i checked). >>> But once again, the old website was intended to drop, otherwise you dont >>> need to change anything or use antora IMHO. >>> >>> >>> >>>> 2. For anyone to be comfortable maintaining the website I think that a >>>> dead-simple single process that generates all the content is essential. >>>> Keeping some files in aries-site-pub between generations violates this >>>> principle and is apt to lead to situations such as the pages at TomEE >> that >>>> appear to have been accidentally deployed by someone at the wrong >> address >>>> and just left there. Otherwise it’s like building a jar with maven and >>>> keeping all the old classes that got renamed and are no longer in >> source. >>>> >>> >>> As mentionned, TomEE situation was intended, only missing step was the >>> mentionned injection of "this page is legacy" banner. Bringing these not >>> maintained pages - this is what it is, dont make it fakely maintained, to >>> the new theme is more confusing cause it looks up to date. >>> >>> Good example, this is what we discussed, just add to your metaphore that >>> you put @Deprecated on all the old packages/classes. >>> >>> >>>> Thanks, >>>> David Jencks >>>>> >>>>> >>>>> >>>>>> Thanks! >>>>>> David Jencks >>>>>> >>>>>>> On Aug 25, 2020, at 11:33 PM, Romain Manni-Bucau < >>>> [email protected]> >>>>>> wrote: >>>>>>> >>>>>>> Hmm, I think it is ok to have a fully new structure and just keep all >>>> old >>>>>>> pages (by just pasting them in the pubsub dir but no more >> synchronizing >>>>>>> them). >>>>>>> An option which is not bad and probably saner than redirects is to >>>> inject >>>>>>> in all old pages a div.alert block saying "page moved to <a>". >>>>>>> This enables to avoid a silent redirect which can not be what is >>>> expected >>>>>>> and still gives enough data for the user to know where he is exactly. >>>>>>> It is a bit like the banners we can see on doc with versioning "this >> is >>>>>> not >>>>>>> the latest version, here is new the <a>" but more in a backward >>>>>>> compatibility goal. >>>>>>> More will have redirect rules, more it will hurt IMHO so let's try to >>>> not >>>>>>> get any ;). >>>>>>> >>>>>>> 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. 26 août 2020 à 01:13, David Jencks <[email protected] >>> >>>> a >>>>>>> écrit : >>>>>>> >>>>>>>> I requested an aries-sitepub mailing list and then realized how >>>>>> redundant >>>>>>>> the name is. Now I’ve requested [email protected], I >> suspect >>>> it >>>>>>>> will be ready tomorrow and I’ll be able to start experimenting with >>>>>>>> publishing a preview of the new site. >>>>>>>> >>>>>>>> I think we’re likely to want to move pages around for a while when >>>> basic >>>>>>>> publishing works. I have an .htaccess file for the current “new >>>>>> locations” >>>>>>>> of the content, and it has 301 permanent redirects in it. While we >>>> are >>>>>>>> deciding on a new structure, would it work to have 302 temporary >>>>>> redirects >>>>>>>> and never supply redirects from the “current new location” to the >>>> “final >>>>>>>> new location”? >>>>>>>> >>>>>>>> David Jencks >>>>>>>> >>>>>>>>> On Aug 23, 2020, at 10:35 PM, Romain Manni-Bucau < >>>>>> [email protected]> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> 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) >> >>
