aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david.a.jen...@gmail.com>
Subject Re: The project website
Date Tue, 01 Sep 2020 17:28:08 GMT
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 <rmannibucau@gmail.com> wrote:
> 
> Le jeu. 27 août 2020 à 23:30, David Jencks <david.a.jencks@gmail.com <mailto:david.a.jencks@gmail.com>> a
> écrit :
> 
>> 
>> 
>>> On Aug 26, 2020, at 11:01 PM, Romain Manni-Bucau <rmannibucau@gmail.com>
>> wrote:
>>> 
>>> Le jeu. 27 août 2020 à 00:22, David Jencks <david.a.jencks@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 <
>> rmannibucau@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.jencks@gmail.com>
>> a
>>>>> écrit :
>>>>> 
>>>>>> I requested an aries-sitepub mailing list and then realized how
>>>> redundant
>>>>>> the name is. Now I’ve requested site-pub@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 <
>>>> rmannibucau@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Le dim. 23 août 2020 à 20:26, David Jencks <david.a.jencks@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 <
>>>> rmannibucau@gmail.com
>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> With Ray on that.
>>>>>>>>> 
>>>>>>>>> Le dim. 23 août 2020 à 15:11, Raymond Auge <
>> raymond.auge@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.jencks@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
>>>>>>>>>>> commits@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 <
>>>>>>>>>> rmannibucau@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.jencks@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.jencks@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.auge@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 <
>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Le ven. 21 août 2020 à 08:36, David Jencks <
>>>>>>>>>> david.a.jencks@gmail.com
>>>>>>>>>>>> 
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Aug 20, 2020, at 11:17 PM, Romain Manni-Bucau <
>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Le ven. 21 août 2020 à 08:15, David Jencks <
>>>>>>>>>>> david.a.jencks@gmail.com
>>>>>>>>>>>>>>>>> <mailto:david.a.jencks@gmail.com>> a
>>>>>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Aug 17, 2020, at 10:43 PM, Romain Manni-Bucau <
>>>>>>>>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Le mar. 18 août 2020 à 02:24, David Jencks <
>>>>>>>>>>>>> david.a.jencks@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.jencks@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 <
>>>>>>>>>>>>>>>>>>> rmannibucau@gmail.com
>>>>>>>>>>>>>>>>>>>>> <mailto:rmannibucau@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 <
>>>>>>>>>>>>> andreww@apache.org
>>>>>>>>>>>>>>>>>>>>> <mailto:andreww@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.jencks@gmail.com
>>>>>>>>>>>>>>>>>>>>> <mailto:david.a.jencks@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<
>>>>>>>>>>> andreww@apache.org
>>>>>>>>>>>>>>>>>>>>> <mailto:andreww@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*
>>>>>>>>>>>>>>>>>>>>>>>>> andreww@apache.org <mailto:andreww@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*
>>>>>>>>>>>>>>>>>>>>>>> andreww@apache.org <mailto:andreww@apache.org>
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Raymond Augé* <
>>>> http://www.liferay.com/web/raymond.auge/profile>
>>>>>>>>>>>>>>> (@rotty3000)
>>>>>>>>>>>>>>> Senior Software Architect *Liferay, Inc.* <
>>>>>> http://www.liferay.com>
>>>>>>>>>>>>>>> (@Liferay)


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message