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