Le jeu. 27 août 2020 à 23:30, David Jencks <david.a.jen...@gmail.com> a écrit :
> > > > On Aug 26, 2020, at 11:01 PM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > > Le jeu. 27 août 2020 à 00:22, David Jencks <david.a.jen...@gmail.com> 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 < > rmannibu...@gmail.com> > >> 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 <david.a.jen...@gmail.com> > a > >>> écrit : > >>> > >>>> I requested an aries-sitepub mailing list and then realized how > >> redundant > >>>> the name is. Now I’ve requested site-...@aries.apache.org, 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 < > >> rmannibu...@gmail.com> > >>>> wrote: > >>>>> > >>>>> Le dim. 23 août 2020 à 20:26, David Jencks <david.a.jen...@gmail.com > > > >> 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 < > >> rmannibu...@gmail.com > >>>>> > >>>>>> wrote: > >>>>>>> > >>>>>>> With Ray on that. > >>>>>>> > >>>>>>> Le dim. 23 août 2020 à 15:11, Raymond Auge < > raymond.a...@liferay.com > >>>>>> .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, < > >>>>>> david.a.jen...@gmail.com> > >>>>>>>>> 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 > >>>>>>>>> comm...@aries.apache.org are fine or agree to set up another > list. > >>>>>>>>> > >>>>>>>>> David Jencks > >>>>>>>>> > >>>>>>>>>> On Aug 21, 2020, at 11:18 PM, Romain Manni-Bucau < > >>>>>>>> rmannibu...@gmail.com> > >>>>>>>>> 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 < > >>>> david.a.jen...@gmail.com> > >>>>>>>> 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 < > >>>> david.a.jen...@gmail.com > >>>>>>> > >>>>>>>>>>> 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 < > >>>>>> raymond.a...@liferay.com > >>>>>>>>> .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 < > >>>>>>>>>>> rmannibu...@gmail.com> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Le ven. 21 août 2020 à 08:36, David Jencks < > >>>>>>>> david.a.jen...@gmail.com > >>>>>>>>>> > >>>>>>>>>>> a > >>>>>>>>>>>>>> écrit : > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Aug 20, 2020, at 11:17 PM, Romain Manni-Bucau < > >>>>>>>>>>>>>> rmannibu...@gmail.com> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Le ven. 21 août 2020 à 08:15, David Jencks < > >>>>>>>>> david.a.jen...@gmail.com > >>>>>>>>>>>>>>> <mailto:david.a.jen...@gmail.com>> a > >>>>>>>>>>>>>>>> écrit : > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Aug 17, 2020, at 10:43 PM, Romain Manni-Bucau < > >>>>>>>>>>>>>>> rmannibu...@gmail.com> > >>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Le mar. 18 août 2020 à 02:24, David Jencks < > >>>>>>>>>>> david.a.jen...@gmail.com > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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 < > >>>>>>>>>>>>>> david.a.jen...@gmail.com> > >>>>>>>>>>>>>>>>>>> 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 < > >>>>>>>>>>>>>>>>> rmannibu...@gmail.com > >>>>>>>>>>>>>>>>>>> <mailto:rmannibu...@gmail.com>> 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 < > >>>>>>>>>>> andr...@apache.org > >>>>>>>>>>>>>>>>>>> <mailto:andr...@apache.org>> 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 < > >>>>>>>>>>>>>>>>> david.a.jen...@gmail.com > >>>>>>>>>>>>>>>>>>> <mailto:david.a.jen...@gmail.com>> > >>>>>>>>>>>>>>>>>>>>> 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< > >>>>>>>>> andr...@apache.org > >>>>>>>>>>>>>>>>>>> <mailto:andr...@apache.org>> 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* > >>>>>>>>>>>>>>>>>>>>>>> andr...@apache.org <mailto:andr...@apache.org> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> > 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* > >>>>>>>>>>>>>>>>>>>>> andr...@apache.org <mailto:andr...@apache.org> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> -- > >>>>>>>>>>>>> *Raymond Augé* < > >> http://www.liferay.com/web/raymond.auge/profile> > >>>>>>>>>>>>> (@rotty3000) > >>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.* < > >>>> http://www.liferay.com> > >>>>>>>>>>>>> (@Liferay) > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >>>> > >> > >> > >
