[GitHub] [tomee-site-generator] dblevins merged pull request #61: TOMEE-4193 Added eol pages for website

[via GitHub]

dblevins merged PR #61:
URL: https://github.com/apache/tomee-site-generator/pull/61


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Website not publishing

[David Blevins]

> On Oct 24, 2022, at 6:27 PM, David Blevins  wrote:
> 
>> On Oct 20, 2022, at 4:23 PM, David Blevins  wrote:
>> 
>> One thought that I had is that it's kind of a problem that the Jenkins job 
>> always passes, even if not much occurs
> [...]
>> 
>> In terms of checks one that would be critical would be to check to see that 
>> an html file was created for every .md or .adoc file.  If not fail the build.
> 
> I went ahead and implemented this in a way that you get a "BUILD FAILED" 
> result from Maven if any `adoc` or `md` files do not generate html.  This 
> should benefit people building locally, our main Jenkins job that publishes 
> the site, and any Github Actions we want to create.

I also merged the Github Actions PR and created a new PR that deliberately 
causes a Maven build failure.  We'll see how it goes:

 - https://github.com/apache/tomee-site-generator/pull/53

Seems to be running.

Note, I'm not sure our tomee-site-generator works with Java 11, so things might 
fail for that reason.  Our Jenkins job uses Java 8.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Website not publishing

[David Blevins]

> On Oct 20, 2022, at 4:23 PM, David Blevins  wrote:
> 
> One thought that I had is that it's kind of a problem that the Jenkins job 
> always passes, even if not much occurs
[...]
> 
> In terms of checks one that would be critical would be to check to see that 
> an html file was created for every .md or .adoc file.  If not fail the build.

I went ahead and implemented this in a way that you get a "BUILD FAILED" result 
from Maven if any `adoc` or `md` files do not generate html.  This should 
benefit people building locally, our main Jenkins job that publishes the site, 
and any Github Actions we want to create.

There's a list of files which currently don't generate html.  Ideally, we never 
add to this list and only remove items from the list over time.

 - 
https://github.com/apache/tomee-site-generator/blob/main/src/main/resources/ignored.txt

If people are looking for a way to contribute, helping to clear out that list 
is a great place to start.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Website not publishing

[Richard Zowalla]

Hi,

We can add checks as suggested in [1] to verify, that the related files
exist. That can be implemented easiliy via GitHub actions. 

If we don't want to script (or generate script code), we could also
implement a little Java helper to do the checks (or to generate the
checks), i.e. check that for every .md / adoc we have a html file, if
someone is more familiar writing Java.

We should also fail, if we find "new" documentation or new html files,
which aren't expected. This might be strict but that would enforce that
we are updating our checks, so perhaps it would be better to write some
tooling to run the checks, so we don't bother with manually updating
checks.

Might be a good "first issue" for someone who wants to contribute?
Perhaps we can create a Jira for it and write some outline /
description. Maybe someone wants to give it a try.

Gruß
Richard

[1] https://github.com/apache/tomee-site-generator/pull/52



Am Donnerstag, dem 20.10.2022 um 16:23 -0700 schrieb David Blevins:
> > On Oct 20, 2022, at 4:01 PM, Cesar Hernandez 
> > wrote:
> > 
> > I pulled the latest main branch locally and compile it (mvn compile
> > -Djbake.http=true), but the server doesn't seem to be working.
> > This PR add basic Github Action so we can validate building on each
> > PR
> > https://github.com/apache/tomee-site-generator/pull/52  we can add
> > Jenkins
> > pipeline too, but I'm doing git bisect to see how we can add a
> > check(s)
> > after maven build is successful in trying to validate from CI if
> > all the
> > JBake requirements are met.
> 
> Some checks would be great.  One thought that I had is that it's kind
> of a problem that the Jenkins job always passes, even if not much
> occurs and we end up with say just javadoc -- or no javadoc :)
> 
> I did try to do a git bisect, but it didn't really work out as the
> old revisions that reference the master branch may have worked then,
> but definitely won't work now.  I tried a couple things and gave up.
> 
> In terms of checks one that would be critical would be to check to
> see that an html file was created for every .md or .adoc file.  If
> not fail the build.
> 
> That might be a little too strict at first as I'm sure we have a few
> adoc files that have issues and don't render even when things are
> good, but we could maybe get that list and 1) exclude them from the
> check and 2) fix them over time and yank them from the exclude list.
> 
> Some thoughts at least.
> 
> 
> -David
> 

Re: Website not publishing

[David Blevins]

> On Oct 20, 2022, at 4:01 PM, Cesar Hernandez  wrote:
> 
> I pulled the latest main branch locally and compile it (mvn compile
> -Djbake.http=true), but the server doesn't seem to be working.
> This PR add basic Github Action so we can validate building on each PR
> https://github.com/apache/tomee-site-generator/pull/52  we can add Jenkins
> pipeline too, but I'm doing git bisect to see how we can add a check(s)
> after maven build is successful in trying to validate from CI if all the
> JBake requirements are met.

Some checks would be great.  One thought that I had is that it's kind of a 
problem that the Jenkins job always passes, even if not much occurs and we end 
up with say just javadoc -- or no javadoc :)

I did try to do a git bisect, but it didn't really work out as the old 
revisions that reference the master branch may have worked then, but definitely 
won't work now.  I tried a couple things and gave up.

In terms of checks one that would be critical would be to check to see that an 
html file was created for every .md or .adoc file.  If not fail the build.

That might be a little too strict at first as I'm sure we have a few adoc files 
that have issues and don't render even when things are good, but we could maybe 
get that list and 1) exclude them from the check and 2) fix them over time and 
yank them from the exclude list.

Some thoughts at least.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Website not publishing

[Cesar Hernandez]

I pulled the latest main branch locally and compile it (mvn compile
-Djbake.http=true), but the server doesn't seem to be working.
This PR add basic Github Action so we can validate building on each PR
https://github.com/apache/tomee-site-generator/pull/52  we can add Jenkins
pipeline too, but I'm doing git bisect to see how we can add a check(s)
after maven build is successful in trying to validate from CI if all the
JBake requirements are met.

El jue, 20 oct 2022 a las 15:15, David Blevins ()
escribió:

> > On Oct 20, 2022, at 8:53 AM, Swell  wrote:
> >
> > i noticed we clone several times the same repo for several branches,
> >
> > there is room for performance improvement, but currently out of my
> > league/time.
> >
> [...]
> > we receive the object streams slowly ... twice, or more, for the same
> .git
> > database.
> >
> > we should instead, fetch all the DB once, then iterate on the 2 or 3
> > branches , do a reset hard, copy the current branch "docs" into a
> specific
> > folder for the jbake to read.
>
> It would definitely be a real improvement!
>
> >
> > this would cut the time to build by 2 ? maybe another day !
>
> I'm pretty confident it'll be there waiting in months or years should you
> want to take a swing someday. :)  Open source code is so patient.
>
>
> -David
>
>

-- 
Atentamente:
César Hernández.

Re: Website not publishing

[David Blevins]

> On Oct 20, 2022, at 8:53 AM, Swell  wrote:
> 
> i noticed we clone several times the same repo for several branches,
> 
> there is room for performance improvement, but currently out of my
> league/time.
> 
[...]
> we receive the object streams slowly ... twice, or more, for the same .git
> database.
> 
> we should instead, fetch all the DB once, then iterate on the 2 or 3
> branches , do a reset hard, copy the current branch "docs" into a specific
> folder for the jbake to read.

It would definitely be a real improvement!

> 
> this would cut the time to build by 2 ? maybe another day !

I'm pretty confident it'll be there waiting in months or years should you want 
to take a swing someday. :)  Open source code is so patient.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Website not publishing

[Swell]

i noticed we clone several times the same repo for several branches,

there is room for performance improvement, but currently out of my
league/time.

  > git clone https://github.com/eclipse/microprofile-config.git
Cloning into
'E:\Remote\Github\tomee-site-generator\repos\microprofile-5.0-repos\config'...
remote: Enumerating objects: 8837
remote: Counting objects: 100% (511/511)
remote: Compressing objects: 100% (246/246)
Receiving objects:  100% (8837/8837)
Resolving deltas:   100% (3917/3917)
Checking out files: 100% (127/127)

  > git clone https://github.com/eclipse/microprofile-config.git
Cloning into
'E:\Remote\Github\tomee-site-generator\repos\microprofile-2.0-repos\config'...
remote: Enumerating objects: 8837
remote: Counting objects: 100% (511/511)
remote: Compressing objects: 100% (247/247)
Receiving objects:  100% (8837/8837)
Resolving deltas:   100% (3917/3917)
Checking out files: 100% (84/84)


we receive the object streams slowly ... twice, or more, for the same .git
database.

we should instead, fetch all the DB once, then iterate on the 2 or 3
branches , do a reset hard, copy the current branch "docs" into a specific
folder for the jbake to read.

this would cut the time to build by 2 ? maybe another day !

--
Swell


On Thu, 20 Oct 2022 at 17:16, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> wrote:

> Thanks, Swell!
>
> Normal adoc changes (in the generator itself) seem to work, though.
>
> Am Donnerstag, dem 20.10.2022 um 17:08 +0200 schrieb Swell:
> > i tested and had a
> >
> > Pull Failed. Source{name='tomee-8.0', scmUrl='
> > https://github.com/apache/tomee.git', branch='tomee-8.x'}
> >   > git pull
> > org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout
> > conflict
> > with files:
> > docs/comparison.adoc
> >
> > i'll update to do a reset hard on remote instead of pull
> >
> > and commit that as a pull request, if it can help
> >
> >
> > On Thu, 20 Oct 2022 at 17:06, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> >
> > > Might be related to "master" -> "main" switch a while back.
> > > I added a commit, I had already made in my local repository after
> > > preparing release notes.
> > >
> > > Don't know, if this solves the issue but could be a thing to look
> > > at.
> > >
> > > Am Donnerstag, dem 20.10.2022 um 16:53 +0200 schrieb Swell:
> > > > looked and noticed adoc from only tomee 8.x branch, generated
> > > > html
> > > >
> > > > looking further.
> > > >
> > > > --
> > > > Swell
> > > >
> > > > On Thu, 20 Oct 2022 at 16:30, David Blevins
> > > > 
> > > > wrote:
> > > >
> > > > > I looked into this about two weeks back for a couple hours but
> > > > > didn't
> > > > > really find the cause.
> > > > >
> > > > > Basically our Jenkins job that builds and publishes the site is
> > > > > running,
> > > > > but only javadoc is getting produced and not any adoc -> html:
> > > > >
> > > > >  - https://ci-builds.apache.org/job/Tomee/job/site-publish/
> > > > >
> > > > > I ran the `tomee-site-generator` locally a handful of times and
> > > > > it
> > > > > also
> > > > > fails on my machine, but I ran out of time to debug.
> > > > >
> > > > > Posting here so others can investigate if they want -- I'm
> > > > > going to
> > > > > try
> > > > > and focus on the failing JAX-RS tests.
> > > > >
> > > > >
> > > > > -David
> > > > >
> > > > >
> > >
> > >
>
>

Re: Website not publishing

[Zowalla, Richard]

Thanks, Swell!

Normal adoc changes (in the generator itself) seem to work, though.

Am Donnerstag, dem 20.10.2022 um 17:08 +0200 schrieb Swell:
> i tested and had a
> 
> Pull Failed. Source{name='tomee-8.0', scmUrl='
> https://github.com/apache/tomee.git', branch='tomee-8.x'}
>   > git pull
> org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout
> conflict
> with files:
> docs/comparison.adoc
> 
> i'll update to do a reset hard on remote instead of pull
> 
> and commit that as a pull request, if it can help
> 
> 
> On Thu, 20 Oct 2022 at 17:06, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> 
> > Might be related to "master" -> "main" switch a while back.
> > I added a commit, I had already made in my local repository after
> > preparing release notes.
> > 
> > Don't know, if this solves the issue but could be a thing to look
> > at.
> > 
> > Am Donnerstag, dem 20.10.2022 um 16:53 +0200 schrieb Swell:
> > > looked and noticed adoc from only tomee 8.x branch, generated
> > > html
> > > 
> > > looking further.
> > > 
> > > --
> > > Swell
> > > 
> > > On Thu, 20 Oct 2022 at 16:30, David Blevins
> > > 
> > > wrote:
> > > 
> > > > I looked into this about two weeks back for a couple hours but
> > > > didn't
> > > > really find the cause.
> > > > 
> > > > Basically our Jenkins job that builds and publishes the site is
> > > > running,
> > > > but only javadoc is getting produced and not any adoc -> html:
> > > > 
> > > >  - https://ci-builds.apache.org/job/Tomee/job/site-publish/
> > > > 
> > > > I ran the `tomee-site-generator` locally a handful of times and
> > > > it
> > > > also
> > > > fails on my machine, but I ran out of time to debug.
> > > > 
> > > > Posting here so others can investigate if they want -- I'm
> > > > going to
> > > > try
> > > > and focus on the failing JAX-RS tests.
> > > > 
> > > > 
> > > > -David
> > > > 
> > > > 
> > 
> > 



smime.p7s
Description: S/MIME cryptographic signature

Re: Website not publishing

[Swell]

i tested and had a

Pull Failed. Source{name='tomee-8.0', scmUrl='
https://github.com/apache/tomee.git', branch='tomee-8.x'}
  > git pull
org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict
with files:
docs/comparison.adoc

i'll update to do a reset hard on remote instead of pull

and commit that as a pull request, if it can help


On Thu, 20 Oct 2022 at 17:06, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> wrote:

> Might be related to "master" -> "main" switch a while back.
> I added a commit, I had already made in my local repository after
> preparing release notes.
>
> Don't know, if this solves the issue but could be a thing to look at.
>
> Am Donnerstag, dem 20.10.2022 um 16:53 +0200 schrieb Swell:
> > looked and noticed adoc from only tomee 8.x branch, generated html
> >
> > looking further.
> >
> > --
> > Swell
> >
> > On Thu, 20 Oct 2022 at 16:30, David Blevins 
> > wrote:
> >
> > > I looked into this about two weeks back for a couple hours but
> > > didn't
> > > really find the cause.
> > >
> > > Basically our Jenkins job that builds and publishes the site is
> > > running,
> > > but only javadoc is getting produced and not any adoc -> html:
> > >
> > >  - https://ci-builds.apache.org/job/Tomee/job/site-publish/
> > >
> > > I ran the `tomee-site-generator` locally a handful of times and it
> > > also
> > > fails on my machine, but I ran out of time to debug.
> > >
> > > Posting here so others can investigate if they want -- I'm going to
> > > try
> > > and focus on the failing JAX-RS tests.
> > >
> > >
> > > -David
> > >
> > >
>
>

Re: Website not publishing

[Zowalla, Richard]

Might be related to "master" -> "main" switch a while back.
I added a commit, I had already made in my local repository after
preparing release notes.

Don't know, if this solves the issue but could be a thing to look at.

Am Donnerstag, dem 20.10.2022 um 16:53 +0200 schrieb Swell:
> looked and noticed adoc from only tomee 8.x branch, generated html
> 
> looking further.
> 
> --
> Swell
> 
> On Thu, 20 Oct 2022 at 16:30, David Blevins 
> wrote:
> 
> > I looked into this about two weeks back for a couple hours but
> > didn't
> > really find the cause.
> > 
> > Basically our Jenkins job that builds and publishes the site is
> > running,
> > but only javadoc is getting produced and not any adoc -> html:
> > 
> >  - https://ci-builds.apache.org/job/Tomee/job/site-publish/
> > 
> > I ran the `tomee-site-generator` locally a handful of times and it
> > also
> > fails on my machine, but I ran out of time to debug.
> > 
> > Posting here so others can investigate if they want -- I'm going to
> > try
> > and focus on the failing JAX-RS tests.
> > 
> > 
> > -David
> > 
> > 



smime.p7s
Description: S/MIME cryptographic signature

Re: Website not publishing

[Swell]

looked and noticed adoc from only tomee 8.x branch, generated html

looking further.

--
Swell

On Thu, 20 Oct 2022 at 16:30, David Blevins  wrote:

> I looked into this about two weeks back for a couple hours but didn't
> really find the cause.
>
> Basically our Jenkins job that builds and publishes the site is running,
> but only javadoc is getting produced and not any adoc -> html:
>
>  - https://ci-builds.apache.org/job/Tomee/job/site-publish/
>
> I ran the `tomee-site-generator` locally a handful of times and it also
> fails on my machine, but I ran out of time to debug.
>
> Posting here so others can investigate if they want -- I'm going to try
> and focus on the failing JAX-RS tests.
>
>
> -David
>
>

Website not publishing

[David Blevins]

I looked into this about two weeks back for a couple hours but didn't really 
find the cause.

Basically our Jenkins job that builds and publishes the site is running, but 
only javadoc is getting produced and not any adoc -> html:

 - https://ci-builds.apache.org/job/Tomee/job/site-publish/

I ran the `tomee-site-generator` locally a handful of times and it also fails 
on my machine, but I ran out of time to debug.

Posting here so others can investigate if they want -- I'm going to try and 
focus on the failing JAX-RS tests.


-David



smime.p7s
Description: S/MIME cryptographic signature

[GitHub] [tomee-site-generator] rzo1 merged pull request #38: TOMEE-3894 fixed website generation under windows

[GitBox]

rzo1 merged PR #38:
URL: https://github.com/apache/tomee-site-generator/pull/38


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [tomee-site-generator] sultan opened a new pull request, #38: TOMEE-3894 fixed website generation under windows

[GitBox]

sultan opened a new pull request, #38:
URL: https://github.com/apache/tomee-site-generator/pull/38

   windows build was broken again, i made it ok, no need to deploy on website 
though <3


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Website - Google Analytics vs Matomo

[Zowalla, Richard]

Good idea. I just added a first draft with some resources / links, I
have used in the past: [1]. It isn't complete and needs some more love
but is a starter to add more links / resources, which I do not know or
have straight in my mind.

For example: I do not know where to find the code for the JavaEE API
Jar (SVN?). Maybe we should start a thread to collect these resources
or just add them step by step to the page.

Gruß
Richard

[1] 
https://github.com/apache/tomee-site-generator/blob/12def25c81a1a0e75fb0951b2e5c042d0ad44ec4/src/main/jbake/content/community/contributor-resources.adoc

Am Montag, dem 14.03.2022 um 19:17 -0700 schrieb David Blevins:
> Looks good!  Can't wait to see what it looks like with more data.
> 
> Can you put that matomo link somewhere on the website so we can
> easily find it?  Maybe we need a page for all these kinds of
> committer/contributor resources like Jenkins, the list archives, a
> list of our git repos, the SVN repo where we upload our releases,
> repository.apache.org, etc.
> 
> Most that stuff is scattered around.  One mega-links page would be
> pretty awesome.
> 
> 
> -David
> 
> 
> > On Mar 14, 2022, at 12:51 AM, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > Hi all,
> > 
> > the TomEE website is now migrated towards Matomo and we do not rely
> > on
> > any 3rd party fonts / css from Google anymore. Thus, we are now
> > compliant with the ASF privacy policy and the GDPR in EU :)
> > 
> > The matomo instance is available here [1]. The TomEE tracking is
> > located here [2].
> > 
> > Gruß
> > Richard
> > 
> > [1] https://matomo.privacy.apache.org/
> > [2] 
> > https://matomo.privacy.apache.org/index.php?module=CoreHome=index=yesterday=day=5#?period=day=yesterday=Dashboard_Dashboard=1
> > 
> > Am Mittwoch, dem 09.03.2022 um 06:34 + schrieb Zowalla,
> > Richard:
> > > Hi all,
> > > 
> > > to follow up: I had a quick chat on Slack with Christian
> > > Grobmaier
> > > (VP
> > > Data Privacy @ ASF) and the ladies operating the Matomo instance
> > > @
> > > ASF.
> > > 
> > > Privacy will urge to remove GA in the near future. The new
> > > privacy
> > > policy draft also removes GA [1], i.e. we have to make the move
> > > sooner
> > > or later.
> > > 
> > > Let's be one of the early birds (besides Shiro, Maven and Flink).
> > > I
> > > created a related issue [2].
> > > 
> > > Gruß
> > > Richard
> > > 
> > > [1] 
> > > https://privacy.apache.org/policies/privacy-policy-public.html
> > > [2] https://issues.apache.org/jira/browse/TOMEE-3851
> > > 
> > > Am Dienstag, dem 08.03.2022 um 08:09 +0100 schrieb Jean-Louis
> > > Monteiro:
> > > > Hi Richard,
> > > > 
> > > > Thanks for the useful information. Haven't paid attention or
> > > > the
> > > > restrictions.
> > > > 
> > > > I'm fine to switch
> > > > 
> > > > Le mar. 8 mars 2022 à 07:19, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > 
> > > > > Hi all,
> > > > > 
> > > > > we had a discussion regarding google analytics last year with
> > > > > the
> > > > > site
> > > > > relaunch.
> > > > > 
> > > > > Looks like Google Analytics is now illegal in France [1] but
> > > > > ASF
> > > > > privacy
> > > > > policies still allow the use [2].
> > > > > 
> > > > > I am wondering, If we should switch to the ASF Matomo
> > > > > instance
> > > > > [3].
> > > > > Matomo
> > > > > doesn't track full IPs, doesn't track sessions after closing
> > > > > the
> > > > > browser,
> > > > > etc.
> > > > > 
> > > > > Therefore, I would propose to replace the GA code with Matomo
> > > > > in
> > > > > our
> > > > > website. Wdyt?
> > > > > 
> > > > > Gruß
> > > > > Richard
> > > > > 
> > > > > [1] 
> > > > > https://matomo.org/blog/2022/02/france-google-analytics-gdpr-breach/
> > > > > 
> > > > > [2] https://www.apache.org/foundation/policies/privacy.html
> > > > > 
> > > > > [3] https://matomo.privacy.apache.org/
> > > > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Website - Google Analytics vs Matomo

[David Blevins]

Looks good!  Can't wait to see what it looks like with more data.

Can you put that matomo link somewhere on the website so we can easily find it? 
 Maybe we need a page for all these kinds of committer/contributor resources 
like Jenkins, the list archives, a list of our git repos, the SVN repo where we 
upload our releases, repository.apache.org, etc.

Most that stuff is scattered around.  One mega-links page would be pretty 
awesome.


-David


> On Mar 14, 2022, at 12:51 AM, Zowalla, Richard 
>  wrote:
> 
> Hi all,
> 
> the TomEE website is now migrated towards Matomo and we do not rely on
> any 3rd party fonts / css from Google anymore. Thus, we are now
> compliant with the ASF privacy policy and the GDPR in EU :)
> 
> The matomo instance is available here [1]. The TomEE tracking is
> located here [2].
> 
> Gruß
> Richard
> 
> [1] https://matomo.privacy.apache.org/
> [2] 
> https://matomo.privacy.apache.org/index.php?module=CoreHome=index=yesterday=day=5#?period=day=yesterday=Dashboard_Dashboard=1
> 
> Am Mittwoch, dem 09.03.2022 um 06:34 + schrieb Zowalla, Richard:
>> Hi all,
>> 
>> to follow up: I had a quick chat on Slack with Christian Grobmaier
>> (VP
>> Data Privacy @ ASF) and the ladies operating the Matomo instance @
>> ASF.
>> 
>> Privacy will urge to remove GA in the near future. The new privacy
>> policy draft also removes GA [1], i.e. we have to make the move
>> sooner
>> or later.
>> 
>> Let's be one of the early birds (besides Shiro, Maven and Flink). I
>> created a related issue [2].
>> 
>> Gruß
>> Richard
>> 
>> [1] https://privacy.apache.org/policies/privacy-policy-public.html
>> [2] https://issues.apache.org/jira/browse/TOMEE-3851
>> 
>> Am Dienstag, dem 08.03.2022 um 08:09 +0100 schrieb Jean-Louis
>> Monteiro:
>>> Hi Richard,
>>> 
>>> Thanks for the useful information. Haven't paid attention or the
>>> restrictions.
>>> 
>>> I'm fine to switch
>>> 
>>> Le mar. 8 mars 2022 à 07:19, Zowalla, Richard <
>>> richard.zowa...@hs-heilbronn.de> a écrit :
>>> 
>>>> Hi all,
>>>> 
>>>> we had a discussion regarding google analytics last year with the
>>>> site
>>>> relaunch.
>>>> 
>>>> Looks like Google Analytics is now illegal in France [1] but ASF
>>>> privacy
>>>> policies still allow the use [2].
>>>> 
>>>> I am wondering, If we should switch to the ASF Matomo instance
>>>> [3].
>>>> Matomo
>>>> doesn't track full IPs, doesn't track sessions after closing the
>>>> browser,
>>>> etc.
>>>> 
>>>> Therefore, I would propose to replace the GA code with Matomo in
>>>> our
>>>> website. Wdyt?
>>>> 
>>>> Gruß
>>>> Richard
>>>> 
>>>> [1] 
>>>> https://matomo.org/blog/2022/02/france-google-analytics-gdpr-breach/
>>>> 
>>>> [2] https://www.apache.org/foundation/policies/privacy.html
>>>> 
>>>> [3] https://matomo.privacy.apache.org/
>>>> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Website - Google Analytics vs Matomo

[Zowalla, Richard]

Hi all,

the TomEE website is now migrated towards Matomo and we do not rely on
any 3rd party fonts / css from Google anymore. Thus, we are now
compliant with the ASF privacy policy and the GDPR in EU :)

The matomo instance is available here [1]. The TomEE tracking is
located here [2].

Gruß
Richard

[1] https://matomo.privacy.apache.org/
[2] 
https://matomo.privacy.apache.org/index.php?module=CoreHome=index=yesterday=day=5#?period=day=yesterday=Dashboard_Dashboard=1

Am Mittwoch, dem 09.03.2022 um 06:34 + schrieb Zowalla, Richard:
> Hi all,
> 
> to follow up: I had a quick chat on Slack with Christian Grobmaier
> (VP
> Data Privacy @ ASF) and the ladies operating the Matomo instance @
> ASF.
> 
> Privacy will urge to remove GA in the near future. The new privacy
> policy draft also removes GA [1], i.e. we have to make the move
> sooner
> or later.
> 
> Let's be one of the early birds (besides Shiro, Maven and Flink). I
> created a related issue [2].
> 
> Gruß
> Richard
> 
> [1] https://privacy.apache.org/policies/privacy-policy-public.html
> [2] https://issues.apache.org/jira/browse/TOMEE-3851
> 
> Am Dienstag, dem 08.03.2022 um 08:09 +0100 schrieb Jean-Louis
> Monteiro:
> > Hi Richard,
> > 
> > Thanks for the useful information. Haven't paid attention or the
> > restrictions.
> > 
> > I'm fine to switch
> > 
> > Le mar. 8 mars 2022 à 07:19, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> a écrit :
> > 
> > > Hi all,
> > > 
> > > we had a discussion regarding google analytics last year with the
> > > site
> > > relaunch.
> > > 
> > > Looks like Google Analytics is now illegal in France [1] but ASF
> > > privacy
> > > policies still allow the use [2].
> > > 
> > > I am wondering, If we should switch to the ASF Matomo instance
> > > [3].
> > > Matomo
> > > doesn't track full IPs, doesn't track sessions after closing the
> > > browser,
> > > etc.
> > > 
> > > Therefore, I would propose to replace the GA code with Matomo in
> > > our
> > > website. Wdyt?
> > > 
> > > Gruß
> > > Richard
> > > 
> > > [1] 
> > > https://matomo.org/blog/2022/02/france-google-analytics-gdpr-breach/
> > > 
> > > [2] https://www.apache.org/foundation/policies/privacy.html
> > > 
> > > [3] https://matomo.privacy.apache.org/
> > > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Website - Google Analytics vs Matomo

[Zowalla, Richard]

Hi all,

to follow up: I had a quick chat on Slack with Christian Grobmaier (VP
Data Privacy @ ASF) and the ladies operating the Matomo instance @ ASF.

Privacy will urge to remove GA in the near future. The new privacy
policy draft also removes GA [1], i.e. we have to make the move sooner
or later.

Let's be one of the early birds (besides Shiro, Maven and Flink). I
created a related issue [2].

Gruß
Richard

[1] https://privacy.apache.org/policies/privacy-policy-public.html
[2] https://issues.apache.org/jira/browse/TOMEE-3851

Am Dienstag, dem 08.03.2022 um 08:09 +0100 schrieb Jean-Louis Monteiro:
> Hi Richard,
> 
> Thanks for the useful information. Haven't paid attention or the
> restrictions.
> 
> I'm fine to switch
> 
> Le mar. 8 mars 2022 à 07:19, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
> 
> > Hi all,
> > 
> > we had a discussion regarding google analytics last year with the
> > site
> > relaunch.
> > 
> > Looks like Google Analytics is now illegal in France [1] but ASF
> > privacy
> > policies still allow the use [2].
> > 
> > I am wondering, If we should switch to the ASF Matomo instance [3].
> > Matomo
> > doesn't track full IPs, doesn't track sessions after closing the
> > browser,
> > etc.
> > 
> > Therefore, I would propose to replace the GA code with Matomo in
> > our
> > website. Wdyt?
> > 
> > Gruß
> > Richard
> > 
> > [1] 
> > https://matomo.org/blog/2022/02/france-google-analytics-gdpr-breach/
> > 
> > [2] https://www.apache.org/foundation/policies/privacy.html
> > 
> > [3] https://matomo.privacy.apache.org/
> > 


smime.p7s
Description: S/MIME cryptographic signature

Re: Website - Google Analytics vs Matomo

[Jean-Louis Monteiro]

Hi Richard,

Thanks for the useful information. Haven't paid attention or the
restrictions.

I'm fine to switch

Le mar. 8 mars 2022 à 07:19, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> a écrit :

> Hi all,
>
> we had a discussion regarding google analytics last year with the site
> relaunch.
>
> Looks like Google Analytics is now illegal in France [1] but ASF privacy
> policies still allow the use [2].
>
> I am wondering, If we should switch to the ASF Matomo instance [3]. Matomo
> doesn't track full IPs, doesn't track sessions after closing the browser,
> etc.
>
> Therefore, I would propose to replace the GA code with Matomo in our
> website. Wdyt?
>
> Gruß
> Richard
>
> [1] https://matomo.org/blog/2022/02/france-google-analytics-gdpr-breach/
>
> [2] https://www.apache.org/foundation/policies/privacy.html
>
> [3] https://matomo.privacy.apache.org/
>

Website - Google Analytics vs Matomo

[Zowalla, Richard]

Hi all,

we had a discussion regarding google analytics last year with the site relaunch.

Looks like Google Analytics is now illegal in France [1] but ASF privacy 
policies still allow the use [2].

I am wondering, If we should switch to the ASF Matomo instance [3]. Matomo 
doesn't track full IPs, doesn't track sessions after closing the browser, etc.

Therefore, I would propose to replace the GA code with Matomo in our website. 
Wdyt?

Gruß
Richard

[1] https://matomo.org/blog/2022/02/france-google-analytics-gdpr-breach/

[2] https://www.apache.org/foundation/policies/privacy.html

[3] https://matomo.privacy.apache.org/

[GitHub] [tomee-site-generator] rzo1 merged pull request #34: TOMEE-3847 fixed website build on windows

[GitBox]

rzo1 merged pull request #34:
URL: https://github.com/apache/tomee-site-generator/pull/34


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [tomee-site-generator] rzo1 commented on pull request #34: TOMEE-3847 fixed website build on windows

[GitBox]

rzo1 commented on pull request #34:
URL: 
https://github.com/apache/tomee-site-generator/pull/34#issuecomment-1058113303


   @sultan thanks!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [tomee-site-generator] sultan opened a new pull request #34: TOMEE-3847 fixed website build on windows

[GitBox]

sultan opened a new pull request #34:
URL: https://github.com/apache/tomee-site-generator/pull/34


   Fixed exception when building website from windows os
   
   https://issues.apache.org/jira/browse/TOMEE-3847
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [tomee-site-generator] jeanouii merged pull request #33: Prepares Website for TomEE 8.0.10 Release

[GitBox]

jeanouii merged pull request #33:
URL: https://github.com/apache/tomee-site-generator/pull/33


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [tomee-site-generator] rzo1 opened a new pull request #33: Prepares Website for TomEE 8.0.10 Release

[GitBox]

rzo1 opened a new pull request #33:
URL: https://github.com/apache/tomee-site-generator/pull/33


   as the title says


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: Version placeholder on the website

[Jonathan Gallimore]

Thanks for the feedback and +1s. I was just thinking that there may be some
legitimate uses of ${tomee.version} that we don't want to replace - e.g.
where we're showing a pom.xml file, and tomee.version is actually defined
as a property. I'm thinking I'll simply switch this to ${TOMEE_VERSION},
merge this in, and set about updating some of the documentation to
reference it.

Let me know if you have any objections to that.

Thanks

Jon

On Tue, Feb 8, 2022 at 2:31 PM Jonathan Gallimore <
jonathan.gallim...@gmail.com> wrote:

> Hi All,
>
> I've created a PR for the site generator project:
> https://github.com/apache/tomee-site-generator/pull/32.
>
> The idea here is to allow ${tomee.version} to be specified in the
> documentation or example files, and it to be swapped for the specific
> version string (which can be specified in the Configuration class). The
> rationale here for pages to show an up-to-date version, rather than
> referencing really old versions.
>
> If folks are ok with this. I'll merge it in, and start working through the
> relevant files to add in the ${tomee.version} placeholder in the right
> places.
>
> Thanks
>
> Jon
>

Re: Version placeholder on the website

[Alex The Rocker]

+1 of course :)

Alex

Le mar. 8 févr. 2022 à 15:49, Jean-Louis Monteiro
 a écrit :
>
> +1
> Thanks
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Tue, Feb 8, 2022 at 3:39 PM Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
>
> > Hi Jon,
> >
> > I am fine with it: +1
> >
> > Might also be usefull for the documentation, which resides in the main
> > repository.
> >
> > Gruß
> > Richard
> >
> > Am Dienstag, dem 08.02.2022 um 14:31 + schrieb Jonathan Gallimore:
> > > Hi All,
> > >
> > > I've created a PR for the site generator project:
> > > https://github.com/apache/tomee-site-generator/pull/32.
> > >
> > > The idea here is to allow ${tomee.version} to be specified in the
> > > documentation or example files, and it to be swapped for the specific
> > > version string (which can be specified in the Configuration class).
> > > The
> > > rationale here for pages to show an up-to-date version, rather than
> > > referencing really old versions.
> > >
> > > If folks are ok with this. I'll merge it in, and start working
> > > through the
> > > relevant files to add in the ${tomee.version} placeholder in the
> > > right
> > > places.
> > >
> > > Thanks
> > >
> > > Jon
> >

Re: Version placeholder on the website

[Jean-Louis Monteiro]

+1
Thanks
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Tue, Feb 8, 2022 at 3:39 PM Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> wrote:

> Hi Jon,
>
> I am fine with it: +1
>
> Might also be usefull for the documentation, which resides in the main
> repository.
>
> Gruß
> Richard
>
> Am Dienstag, dem 08.02.2022 um 14:31 + schrieb Jonathan Gallimore:
> > Hi All,
> >
> > I've created a PR for the site generator project:
> > https://github.com/apache/tomee-site-generator/pull/32.
> >
> > The idea here is to allow ${tomee.version} to be specified in the
> > documentation or example files, and it to be swapped for the specific
> > version string (which can be specified in the Configuration class).
> > The
> > rationale here for pages to show an up-to-date version, rather than
> > referencing really old versions.
> >
> > If folks are ok with this. I'll merge it in, and start working
> > through the
> > relevant files to add in the ${tomee.version} placeholder in the
> > right
> > places.
> >
> > Thanks
> >
> > Jon
>

Re: Version placeholder on the website

[Zowalla, Richard]

Hi Jon,

I am fine with it: +1

Might also be usefull for the documentation, which resides in the main
repository.

Gruß
Richard

Am Dienstag, dem 08.02.2022 um 14:31 + schrieb Jonathan Gallimore:
> Hi All,
> 
> I've created a PR for the site generator project:
> https://github.com/apache/tomee-site-generator/pull/32.
> 
> The idea here is to allow ${tomee.version} to be specified in the
> documentation or example files, and it to be swapped for the specific
> version string (which can be specified in the Configuration class).
> The
> rationale here for pages to show an up-to-date version, rather than
> referencing really old versions.
> 
> If folks are ok with this. I'll merge it in, and start working
> through the
> relevant files to add in the ${tomee.version} placeholder in the
> right
> places.
> 
> Thanks
> 
> Jon


smime.p7s
Description: S/MIME cryptographic signature

Re: Website documentation for own-git-repo subprojects

[David Jencks]

OOPS wrong list, sorry,

David Jencks

> On Jul 21, 2021, at 9:37 AM, David Jencks  wrote:
> 
> The CMS website and the Antora website currently have the docs source far 
> from the code. As a result several subprojects (SCR, Atomos at least) have 
> put their documentation in a README in the subproject git repo. This results 
> in these subproject documentation appearing really different from other 
> subprojects docs and lacking the overall navigation facilities from the site. 
> Currently the Antora based website doesn’t attempt to include this 
> documentation.
> 
> With Antora this is not necessary: Antora can extract documentation source 
> from any number of git repos and assemble it all seamlessly. I think it would 
> be a good idea to set this up. In general Antora requires sources in each git 
> repo to be in a specific directory structure, for the current felix site 
> `…/modules/ROOT/pages/*.adoc`.
> 
> There are several choices for how to do this:
> 
> - Move the README contents to a concrete .adoc page in the above structure 
> and have the README mostly point to the website.  This allows use of the full 
> power of Asciidoc on the pages, rather than the quite constricted subset 
> available from the GitHub asciidoc renderer (or the GitHub markdown 
> renderer).  I think this is the best choice.
> 
> - Symlink from the above structure location to the README (which will need to 
> be translated to Asciidoc, which will still be rendered by GitHub).  Symlink 
> support was recently added to Antora but I haven’t tried it in this scenario. 
>  This would give the same content at GitHub (in roughly its current format) 
> and in the website(integrated, with nav, header, footer, etc), but would 
> limit subproject documentation to a single page and inhibit links to other 
> website pages, among other problems.
> 
> - Add (external) links in the nav to the READMEs on GitHub.  In this case 
> there will be no version of the documentation integrated into the website.
> 
> Thoughts?
> 
> David Jencks
> 
> 

Website documentation for own-git-repo subprojects

[David Jencks]

The CMS website and the Antora website currently have the docs source far from 
the code. As a result several subprojects (SCR, Atomos at least) have put their 
documentation in a README in the subproject git repo. This results in these 
subproject documentation appearing really different from other subprojects docs 
and lacking the overall navigation facilities from the site. Currently the 
Antora based website doesn’t attempt to include this documentation.

With Antora this is not necessary: Antora can extract documentation source from 
any number of git repos and assemble it all seamlessly. I think it would be a 
good idea to set this up. In general Antora requires sources in each git repo 
to be in a specific directory structure, for the current felix site 
`…/modules/ROOT/pages/*.adoc`.

There are several choices for how to do this:

- Move the README contents to a concrete .adoc page in the above structure and 
have the README mostly point to the website.  This allows use of the full power 
of Asciidoc on the pages, rather than the quite constricted subset available 
from the GitHub asciidoc renderer (or the GitHub markdown renderer).  I think 
this is the best choice.

- Symlink from the above structure location to the README (which will need to 
be translated to Asciidoc, which will still be rendered by GitHub).  Symlink 
support was recently added to Antora but I haven’t tried it in this scenario.  
This would give the same content at GitHub (in roughly its current format) and 
in the website(integrated, with nav, header, footer, etc), but would limit 
subproject documentation to a single page and inhibit links to other website 
pages, among other problems.

- Add (external) links in the nav to the READMEs on GitHub.  In this case there 
will be no version of the documentation integrated into the website.

Thoughts?

David Jencks

Re: Updated website content

[Zowalla, Richard]

I think, that it boils down to a related cookie banner with opt-out /
opt-in to fully comply with GDPR.

We might also need to look for external loading of (Google) fonts via
CSS / embedded Javacscript :/

Gruss
Richard

Am Samstag, den 22.05.2021, 12:19 -0700 schrieb David Blevins:
> > On May 22, 2021, at 11:08 AM, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > (b) Remove the usage of Google Analytics according to [1]
> 
> Sounds like there are a couple recommendations we could put in place
> and still use Google Analytics.  I'd be in favor of pursuing those.
> 
> 
> -David
> 
> > Am Donnerstag, den 20.05.2021, 14:10 -0700 schrieb David Blevins:
> > > All,
> > > 
> > > Some updates on content in general as there are some changes
> > > there
> > > too not related to the potential new front page.
> > > 
> > > We had a lot of content still stuck in the old markdown format of
> > > the
> > > Apache CMS.  Every page you might find via Google with a black
> > > bar
> > > across the top is live content left behind when we switched to
> > > JBake.  I pulled them over from svn about 2 years ago.  David
> > > Jencks
> > > converted them from markdown to asiidoc last year.  I pulled them
> > > from his personal branch and pushed them to master.
> > > 
> > > - https://github.com/apache/tomee-site-generator/pull/26
> > > 
> > > That's where a lot of "new" content is coming from.  We needed to
> > > do
> > > this years, but never quite got it done completely.  I wanted to
> > > update a lot of the content, but didn't want to diverge so far
> > > from
> > > David's work that we could no longer use it.  So I pulled that in
> > > first and deleted the old markdown files before doing any content
> > > overhauls.
> > > 
> > > Richard, answering some of your questions here just so we're all
> > > clear that the `new-front-page` branch isn't proposing content
> > > changes aside form the front-page.
> > > 
> > > > On May 20, 2021, at 1:00 AM, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> wrote:
> > > > 
> > > > - In addition, we should change all out going links to "https"
> > > > instead
> > > > of "http" (as the ASF pages have no redirect from "http" to
> > > > "https"
> > > > in
> > > > place) + enable the "http" to "https" redirect for the TomEE
> > > > site -
> > > > but
> > > > these are very minor tasks imho :)
> > > > 
> > > > - Maybe we should remove Google+ from the Social Media section,
> > > > if
> > > > anybody agrees. Imho it is a _dead_ social media network.
> > > > 
> > > > - Don't know if "IRC" is still active or if we should mention
> > > > Slack
> > > > instead on the "Support" page.
> > > 
> > > Feel free to make these changes.
> > > 
> > > > - "Support" links to "Commercial", which is a dead page (404)
> > > 
> > > We had a few incorrect relative links.  I fixed the ones I could
> > > find
> > > via find/replace:
> > > 
> > > - 
> > > https://github.com/apache/tomee-site-generator/commit/2d98d6320e222d7d3c93dd1e497e9aaf93a00b1b
> > > 
> > > If you see any missed it's safe to update them in `tomee-site-
> > > generator` on the `master` branch.
> > > 
> > > FYI on that page specifically, we now have two copies in source:
> > > 
> > > - 
> > > https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/commercial-support.adoc
> > > - 
> > > https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/community/commercial.adoc
> > > 
> > > We always had two copies on the published site for the reasons
> > > above,
> > > just FYI that we still have work to do to get our content
> > > completely
> > > clean.
> > > 
> > > > I can give it some love, if no one objects, but I have some
> > > > workflow
> > > > related questions left.
> > > 
> > > Very welcome and thank you!
> > > 
> > > > ## Workflow Questions:
> > > > 
> > > > - Does the https://github.com/apache/tomee-site-generator repo
> > > > already
> > > > contain the changes @ staging?
> > > 
> > > The same content seen in staging is in tomee-site-generator
> > > master
> > > branch and live on https://tomee.apache.org
> > > 
> > > The front page and template updates from staging are only here:
> > > 
> > > - 
> > > https://github.com/apache/tomee-site-generator/tree/new-home-page
> > > 
> > > > - How does the staging publish work?
> > > > - After this is clarified, we should update the README to
> > > > explain
> > > > the
> > > > new workflow for (new) contributors. (I can do this)
> > > 
> > > I had to dig around for that, so documenting it is super
> > > great.  Thanks for offering!
> > > 
> > > Here's the main resource I used:
> > > 
> > > - 
> > > https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
> > > 
> > > It's kind of a long read.  Here are the most crucial points and
> > > how
> > > it could map to us specifically:
> > > 
> > > - Make a branch in https://github.com/apache/tomee-site-generator
> > > .  
> > > For example: oranges
> > > - 

Re: Updated website content

[David Blevins]

> On May 22, 2021, at 11:08 AM, Zowalla, Richard 
>  wrote:
> 
> (b) Remove the usage of Google Analytics according to [1]

Sounds like there are a couple recommendations we could put in place and still 
use Google Analytics.  I'd be in favor of pursuing those.


-David

> Am Donnerstag, den 20.05.2021, 14:10 -0700 schrieb David Blevins:
>> All,
>> 
>> Some updates on content in general as there are some changes there
>> too not related to the potential new front page.
>> 
>> We had a lot of content still stuck in the old markdown format of the
>> Apache CMS.  Every page you might find via Google with a black bar
>> across the top is live content left behind when we switched to
>> JBake.  I pulled them over from svn about 2 years ago.  David Jencks
>> converted them from markdown to asiidoc last year.  I pulled them
>> from his personal branch and pushed them to master.
>> 
>> - https://github.com/apache/tomee-site-generator/pull/26
>> 
>> That's where a lot of "new" content is coming from.  We needed to do
>> this years, but never quite got it done completely.  I wanted to
>> update a lot of the content, but didn't want to diverge so far from
>> David's work that we could no longer use it.  So I pulled that in
>> first and deleted the old markdown files before doing any content
>> overhauls.
>> 
>> Richard, answering some of your questions here just so we're all
>> clear that the `new-front-page` branch isn't proposing content
>> changes aside form the front-page.
>> 
>>> On May 20, 2021, at 1:00 AM, Zowalla, Richard <
>>> richard.zowa...@hs-heilbronn.de> wrote:
>>> 
>>> - In addition, we should change all out going links to "https"
>>> instead
>>> of "http" (as the ASF pages have no redirect from "http" to "https"
>>> in
>>> place) + enable the "http" to "https" redirect for the TomEE site -
>>> but
>>> these are very minor tasks imho :)
>>> 
>>> - Maybe we should remove Google+ from the Social Media section, if
>>> anybody agrees. Imho it is a _dead_ social media network.
>>> 
>>> - Don't know if "IRC" is still active or if we should mention Slack
>>> instead on the "Support" page.
>> 
>> Feel free to make these changes.
>> 
>>> - "Support" links to "Commercial", which is a dead page (404)
>> 
>> We had a few incorrect relative links.  I fixed the ones I could find
>> via find/replace:
>> 
>> - 
>> https://github.com/apache/tomee-site-generator/commit/2d98d6320e222d7d3c93dd1e497e9aaf93a00b1b
>> 
>> If you see any missed it's safe to update them in `tomee-site-
>> generator` on the `master` branch.
>> 
>> FYI on that page specifically, we now have two copies in source:
>> 
>> - 
>> https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/commercial-support.adoc
>> - 
>> https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/community/commercial.adoc
>> 
>> We always had two copies on the published site for the reasons above,
>> just FYI that we still have work to do to get our content completely
>> clean.
>> 
>>> I can give it some love, if no one objects, but I have some
>>> workflow
>>> related questions left.
>> 
>> Very welcome and thank you!
>> 
>>> ## Workflow Questions:
>>> 
>>> - Does the https://github.com/apache/tomee-site-generator repo
>>> already
>>> contain the changes @ staging?
>> 
>> The same content seen in staging is in tomee-site-generator master
>> branch and live on https://tomee.apache.org
>> 
>> The front page and template updates from staging are only here:
>> 
>> - https://github.com/apache/tomee-site-generator/tree/new-home-page
>> 
>>> - How does the staging publish work?
>>> - After this is clarified, we should update the README to explain
>>> the
>>> new workflow for (new) contributors. (I can do this)
>> 
>> I had to dig around for that, so documenting it is super
>> great.  Thanks for offering!
>> 
>> Here's the main resource I used:
>> 
>> - 
>> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
>> 
>> It's kind of a long read.  Here are the most crucial points and how
>> it could map to us specifically:
>> 
>> - Make a branch in https://github.com/apache/tomee-site-generator.  
>> For example: oranges
>> - Make an `oranges` branch in 
>> https://github.com/apache/tomee-site-pub.
>> - In tomee-site-pub's `oranges` branch, update the .asf.yaml file so
>> that it has the following:
>> 
>>staging:
>>  profile: oranges
>>  whoami: oranges
>> 
>> - Push the .asf.yaml changes to tomee-site-pub oranges branch, wait
>> a minute or two
>> - Verify https://tomee-oranges.staged.apache.org/ exists
>> 
>> From there you can push changes to tomee-site-generator's `oranges`
>> branch, build them, sync them into tomee-site-pub's `oranges` branch
>> and they should show up in a minute or two.  It's near instantaneous
>> if you change just one html file, it takes a minute or so for a
>> change affecting many html pages.
>> 
>>> From the other mailing list
>>> thread, I see, that we have a Jenkins job 

Re: Updated website content

[Zowalla, Richard]

Thanks for the update!

We should also aim for

(a) Automatic redirection from http -> https via .htaccess 
(b) Remove the usage of Google Analytics according to [1]

In addition, there is some ongoing discussion on the INFRA list to move
Google-hosted fonts / css to an ASF-based hosting [2] to honor privacy
constraints.

I will take a look at (a) and (b).

Gruss
Richard

[1] https://privacy.apache.org/faq/committers.html

Am Donnerstag, den 20.05.2021, 14:10 -0700 schrieb David Blevins:
> All,
> 
> Some updates on content in general as there are some changes there
> too not related to the potential new front page.
> 
> We had a lot of content still stuck in the old markdown format of the
> Apache CMS.  Every page you might find via Google with a black bar
> across the top is live content left behind when we switched to
> JBake.  I pulled them over from svn about 2 years ago.  David Jencks
> converted them from markdown to asiidoc last year.  I pulled them
> from his personal branch and pushed them to master.
> 
>  - https://github.com/apache/tomee-site-generator/pull/26
> 
> That's where a lot of "new" content is coming from.  We needed to do
> this years, but never quite got it done completely.  I wanted to
> update a lot of the content, but didn't want to diverge so far from
> David's work that we could no longer use it.  So I pulled that in
> first and deleted the old markdown files before doing any content
> overhauls.
> 
> Richard, answering some of your questions here just so we're all
> clear that the `new-front-page` branch isn't proposing content
> changes aside form the front-page.
> 
> > On May 20, 2021, at 1:00 AM, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> wrote:
> > 
> > - In addition, we should change all out going links to "https"
> > instead
> > of "http" (as the ASF pages have no redirect from "http" to "https"
> > in
> > place) + enable the "http" to "https" redirect for the TomEE site -
> > but
> > these are very minor tasks imho :)
> > 
> > - Maybe we should remove Google+ from the Social Media section, if
> > anybody agrees. Imho it is a _dead_ social media network.
> > 
> > - Don't know if "IRC" is still active or if we should mention Slack
> > instead on the "Support" page.
> 
> Feel free to make these changes.
> 
> > - "Support" links to "Commercial", which is a dead page (404)
> 
> We had a few incorrect relative links.  I fixed the ones I could find
> via find/replace:
> 
>  - 
> https://github.com/apache/tomee-site-generator/commit/2d98d6320e222d7d3c93dd1e497e9aaf93a00b1b
> 
> If you see any missed it's safe to update them in `tomee-site-
> generator` on the `master` branch.
> 
> FYI on that page specifically, we now have two copies in source:
> 
>  - 
> https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/commercial-support.adoc
>  - 
> https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/community/commercial.adoc
> 
> We always had two copies on the published site for the reasons above,
> just FYI that we still have work to do to get our content completely
> clean.
> 
> > I can give it some love, if no one objects, but I have some
> > workflow
> > related questions left.
> 
> Very welcome and thank you!
> 
> > ## Workflow Questions:
> > 
> > - Does the https://github.com/apache/tomee-site-generator repo
> > already
> > contain the changes @ staging?
> 
> The same content seen in staging is in tomee-site-generator master
> branch and live on https://tomee.apache.org
> 
> The front page and template updates from staging are only here:
> 
>  - https://github.com/apache/tomee-site-generator/tree/new-home-page
> 
> > - How does the staging publish work?
> > - After this is clarified, we should update the README to explain
> > the
> > new workflow for (new) contributors. (I can do this)
> 
> I had to dig around for that, so documenting it is super
> great.  Thanks for offering!
> 
> Here's the main resource I used:
> 
>  - 
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features
> 
> It's kind of a long read.  Here are the most crucial points and how
> it could map to us specifically:
> 
>  - Make a branch in https://github.com/apache/tomee-site-generator.  
> For example: oranges
>  - Make an `oranges` branch in 
> https://github.com/apache/tomee-site-pub.
>  - In tomee-site-pub's `oranges` branch, update the .asf.yaml file so
> that it has the following:
> 
> staging:
>   profile: oranges
>   whoami: oranges
> 
>  - Push the .asf.yaml changes to tomee-site-pub oranges branch, wait
> a minute or two
>  - Verify https://tomee-oranges.staged.apache.org/ exists
> 
> From there you can push changes to tomee-site-generator's `oranges`
> branch, build them, sync them into tomee-site-pub's `oranges` branch
> and they should show up in a minute or two.  It's near instantaneous
> if you change just one html file, it takes a minute or so for a
> change affecting many html pages.
> 
> > 

Re: Automatic website publishing

[Cesar Hernandez]

>
> FYI, Cesar, your test didn't work because you need to select
> `git-websites` as the node.  That has the credentials setup and permissions
> to publish to an `asf-site` or `asf-staging-*` branch.


Thank you for the update. I'm deleting now the test-pipeline to clear out
our current number of jenkis jobs.


El jue, 20 may 2021 a las 2:01, Zowalla, Richard (<
richard.zowa...@hs-heilbronn.de>) escribió:

> Great news :) - definitly an important improvement for website / doc
> contributions!
>
>
> Am Mittwoch, den 19.05.2021, 20:36 -0700 schrieb David Blevins:
> > Thanks, David and Cesar!
> >
> > The Jenkins part is working.  My tests runs that pushed to `asf-site`
> > all worked and since the last email I've completed it and we now have
> > automated publishing to the `asf-site` branch.  The job is setup to
> > run daily, but any of us can click the 'Build Now' button at any time
> > if you're impatient.
> >
> >   -
> >
> https://github.com/apache/tomee-site-pub/commit/3409970cd9cd0dbf806da49ff9edc0c37d152e46
> >
> > FYI, Cesar, your test didn't work because you need to select `git-
> > websites` as the node.  That has the credentials setup and
> > permissions to publish to an `asf-site` or `asf-staging-*` branch.
> >
> > What doesn't work is that our website was setup to use `master` not
> > `asf-site`, so after the switch from `master` to `asf-site` updates
> > do not reach https://tomee.apache.org.
> >
> > I filed a ticket (INFRA-21903).  I worked a bit with @fluxo on
> > #asfinfra and neither of us were able to figure it out.  I suspect
> > @Humbedooh will get it resolved.
> >
> > The good news is that when he does, we're completely setup for
> > automated publishes to the website!
> >
> --
> Richard Zowalla, M.Sc.
> Research Associate, PhD Student | Medical Informatics
>
> Hochschule Heilbronn – University of Applied Sciences
> Max-Planck-Str. 39
> D-74081 Heilbronn
> phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar)
> mail: richard.zowa...@hs-heilbronn.de
> web: https://www.mi.hs-heilbronn.de/
>


-- 
Atentamente:
César Hernández.

Updated website content

[David Blevins]

All,

Some updates on content in general as there are some changes there too not 
related to the potential new front page.

We had a lot of content still stuck in the old markdown format of the Apache 
CMS.  Every page you might find via Google with a black bar across the top is 
live content left behind when we switched to JBake.  I pulled them over from 
svn about 2 years ago.  David Jencks converted them from markdown to asiidoc 
last year.  I pulled them from his personal branch and pushed them to master.

 - https://github.com/apache/tomee-site-generator/pull/26

That's where a lot of "new" content is coming from.  We needed to do this 
years, but never quite got it done completely.  I wanted to update a lot of the 
content, but didn't want to diverge so far from David's work that we could no 
longer use it.  So I pulled that in first and deleted the old markdown files 
before doing any content overhauls.

Richard, answering some of your questions here just so we're all clear that the 
`new-front-page` branch isn't proposing content changes aside form the 
front-page.

> On May 20, 2021, at 1:00 AM, Zowalla, Richard 
>  wrote:
> 
> - In addition, we should change all out going links to "https" instead
> of "http" (as the ASF pages have no redirect from "http" to "https" in
> place) + enable the "http" to "https" redirect for the TomEE site - but
> these are very minor tasks imho :)
> 
> - Maybe we should remove Google+ from the Social Media section, if
> anybody agrees. Imho it is a _dead_ social media network.
> 
> - Don't know if "IRC" is still active or if we should mention Slack
> instead on the "Support" page.

Feel free to make these changes.

> - "Support" links to "Commercial", which is a dead page (404)

We had a few incorrect relative links.  I fixed the ones I could find via 
find/replace:

 - 
https://github.com/apache/tomee-site-generator/commit/2d98d6320e222d7d3c93dd1e497e9aaf93a00b1b

If you see any missed it's safe to update them in `tomee-site-generator` on the 
`master` branch.

FYI on that page specifically, we now have two copies in source:

 - 
https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/commercial-support.adoc
 - 
https://github.com/apache/tomee-site-generator/blob/master/src/main/jbake/content/community/commercial.adoc

We always had two copies on the published site for the reasons above, just FYI 
that we still have work to do to get our content completely clean.

> I can give it some love, if no one objects, but I have some workflow
> related questions left.

Very welcome and thank you!

> ## Workflow Questions:
> 
> - Does the https://github.com/apache/tomee-site-generator repo already
> contain the changes @ staging?

The same content seen in staging is in tomee-site-generator master branch and 
live on https://tomee.apache.org

The front page and template updates from staging are only here:

 - https://github.com/apache/tomee-site-generator/tree/new-home-page

> - How does the staging publish work?
> - After this is clarified, we should update the README to explain the
> new workflow for (new) contributors. (I can do this)

I had to dig around for that, so documenting it is super great.  Thanks for 
offering!

Here's the main resource I used:

 - https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features

It's kind of a long read.  Here are the most crucial points and how it could 
map to us specifically:

 - Make a branch in https://github.com/apache/tomee-site-generator.  For 
example: oranges
 - Make an `oranges` branch in https://github.com/apache/tomee-site-pub.
 - In tomee-site-pub's `oranges` branch, update the .asf.yaml file so that it 
has the following:

staging:
  profile: oranges
  whoami: oranges

 - Push the .asf.yaml changes to tomee-site-pub oranges branch, wait a minute 
or two
 - Verify https://tomee-oranges.staged.apache.org/ exists

From there you can push changes to tomee-site-generator's `oranges` branch, 
build them, sync them into tomee-site-pub's `oranges` branch and they should 
show up in a minute or two.  It's near instantaneous if you change just one 
html file, it takes a minute or so for a change affecting many html pages.

> From the other mailing list
> thread, I see, that we have a Jenkins job [1] for the main site in
> place. Might be useful to have one for staging too?

If we can script it, it's possible :)

Maybe we could make a copy of this job, but have it take a tomee-site-generator 
branch name as a build parameter:

 - https://ci-builds.apache.org/job/Tomee/job/site-publish/

The job could automatically create the same branch in tomee-site-pub, update 
the .asf.yaml and do a build/publish.  It could potentially do that 
automatically upon seeing a commit on a branch.  Alternatively, we could have 
one tomee-site-pub branch for staging everyone shares, which could work but 
would have obvious limitations that only one person could really use it at a 
time.

Thinking 

Re: Automatic website publishing

[Zowalla, Richard]

Great news :) - definitly an important improvement for website / doc
contributions!


Am Mittwoch, den 19.05.2021, 20:36 -0700 schrieb David Blevins:
> Thanks, David and Cesar!
> 
> The Jenkins part is working.  My tests runs that pushed to `asf-site` 
> all worked and since the last email I've completed it and we now have
> automated publishing to the `asf-site` branch.  The job is setup to
> run daily, but any of us can click the 'Build Now' button at any time
> if you're impatient.
> 
>   - 
> https://github.com/apache/tomee-site-pub/commit/3409970cd9cd0dbf806da49ff9edc0c37d152e46
> 
> FYI, Cesar, your test didn't work because you need to select `git-
> websites` as the node.  That has the credentials setup and
> permissions to publish to an `asf-site` or `asf-staging-*` branch.
> 
> What doesn't work is that our website was setup to use `master` not
> `asf-site`, so after the switch from `master` to `asf-site` updates
> do not reach https://tomee.apache.org.
> 
> I filed a ticket (INFRA-21903).  I worked a bit with @fluxo on
> #asfinfra and neither of us were able to figure it out.  I suspect
> @Humbedooh will get it resolved.
> 
> The good news is that when he does, we're completely setup for
> automated publishes to the website!
> 
-- 
Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39 
D-74081 Heilbronn 
phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar)
mail: richard.zowa...@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/ 


smime.p7s
Description: S/MIME cryptographic signature

Re: Automatic website publishing

[David Blevins]

Thanks, David and Cesar!

The Jenkins part is working.  My tests runs that pushed to `asf-site` all 
worked and since the last email I've completed it and we now have automated 
publishing to the `asf-site` branch.  The job is setup to run daily, but any of 
us can click the 'Build Now' button at any time if you're impatient.

  - 
https://github.com/apache/tomee-site-pub/commit/3409970cd9cd0dbf806da49ff9edc0c37d152e46

FYI, Cesar, your test didn't work because you need to select `git-websites` as 
the node.  That has the credentials setup and permissions to publish to an 
`asf-site` or `asf-staging-*` branch.

What doesn't work is that our website was setup to use `master` not `asf-site`, 
so after the switch from `master` to `asf-site` updates do not reach 
https://tomee.apache.org.

I filed a ticket (INFRA-21903).  I worked a bit with @fluxo on #asfinfra and 
neither of us were able to figure it out.  I suspect @Humbedooh will get it 
resolved.

The good news is that when he does, we're completely setup for automated 
publishes to the website!

-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On May 19, 2021, at 7:52 PM, Cesar Hernandez  wrote:
> 
> Hi David,
> 
> I tried to do these steps using jenkins pipeline with a test job here:
> https://ci-builds.apache.org/job/Tomee/job/test-pipeline/
> The problem [1] I'm getting seems to be related to the fact that the CI
> user doesn't have write access to the repo:
> 
> "remote: Permission to apache/tomee-site-pub.git denied to . "
> 
> 
> [1]
> 
> + git commit -m test publish from ci-builds.apache.org using jenkins
> [asf-staging-test 678b293a4] test publish from ci-builds.apache.org
> using jenkins
> 1 file changed, 1 insertion(+), 1 deletion(-)[Pipeline]
> withCredentials
> <https://ci-builds.apache.org/job/Tomee/job/test-pipeline/14/console#>Masking
> supported pattern matches of $GIT_USERNAME or $GIT_PASSWORD[Pipeline]
> { 
> <https://ci-builds.apache.org/job/Tomee/job/test-pipeline/14/console#>[Pipeline]
> sh <https://ci-builds.apache.org/job/Tomee/job/test-pipeline/14/console#>
> 
> + git push origin HEAD:asf-staging-test
> remote: Permission to apache/tomee-site-pub.git denied to .
> fatal: unable to access 'https://github.com/apache/tomee-site-pub/':
> The requested URL returned error: 403[Pipeline] }[Pipeline] //
> withCredentials[Pipeline] }[Pipeline] // stage[Pipeline] }[Pipeline]
> // node[Pipeline] End of PipelineERROR: script returned exit code 128
> Finished: FAILURE
> 
> 
> 
> 
> El mié, 19 may 2021 a las 19:03, David Blevins ()
> escribió:
> 
>> I've been trying to setup automatic website publishing.
>> 
>> So far I have a test Jenkins job that does a simple commit/push:
>> 
>> - https://ci-builds.apache.org/job/Tomee/job/site-publish
>> 
>> At the moment it's just a simple Freestyle job with a test script to see a
>> successful commit/push work:
>> 
>>git clone https://gitbox.apache.org/repos/asf/tomee-site-pub.git -b
>> asf-staging-test
>>cd tomee-site-pub
>>date > test.txt
>>git add test.txt
>>git commit -m "test publish from ci-builds.apache.org" test.txt
>>git push origin asf-staging-test
>> 
>> The trick and where I'm stuck is that we're using `master` as our main
>> branch for https://tomee.apache.org and Jenkins is setup to only let us
>> push a branch called `asf-site` or `asf-staging-*`
>> 
>> I've attempted to switch `tomee-site-pub` from `master` to `asf-site`, but
>> it doesn't seem to work.  I've filed a ticket with Infra and will keep you
>> updated:
>> 
>> - https://issues.apache.org/jira/browse/INFRA-21903
>> 
>> 
>> --
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>> 
>> 
> 
> -- 
> Atentamente:
> César Hernández.



smime.p7s
Description: S/MIME cryptographic signature

Re: Automatic website publishing

[Cesar Hernandez]

Hi David,

I tried to do these steps using jenkins pipeline with a test job here:
https://ci-builds.apache.org/job/Tomee/job/test-pipeline/
The problem [1] I'm getting seems to be related to the fact that the CI
user doesn't have write access to the repo:

"remote: Permission to apache/tomee-site-pub.git denied to . "


[1]

+ git commit -m test publish from ci-builds.apache.org using jenkins
[asf-staging-test 678b293a4] test publish from ci-builds.apache.org
using jenkins
 1 file changed, 1 insertion(+), 1 deletion(-)[Pipeline]
withCredentials
<https://ci-builds.apache.org/job/Tomee/job/test-pipeline/14/console#>Masking
supported pattern matches of $GIT_USERNAME or $GIT_PASSWORD[Pipeline]
{ 
<https://ci-builds.apache.org/job/Tomee/job/test-pipeline/14/console#>[Pipeline]
sh <https://ci-builds.apache.org/job/Tomee/job/test-pipeline/14/console#>

+ git push origin HEAD:asf-staging-test
remote: Permission to apache/tomee-site-pub.git denied to .
fatal: unable to access 'https://github.com/apache/tomee-site-pub/':
The requested URL returned error: 403[Pipeline] }[Pipeline] //
withCredentials[Pipeline] }[Pipeline] // stage[Pipeline] }[Pipeline]
// node[Pipeline] End of PipelineERROR: script returned exit code 128
Finished: FAILURE




El mié, 19 may 2021 a las 19:03, David Blevins ()
escribió:

> I've been trying to setup automatic website publishing.
>
> So far I have a test Jenkins job that does a simple commit/push:
>
>  - https://ci-builds.apache.org/job/Tomee/job/site-publish
>
> At the moment it's just a simple Freestyle job with a test script to see a
> successful commit/push work:
>
> git clone https://gitbox.apache.org/repos/asf/tomee-site-pub.git -b
> asf-staging-test
> cd tomee-site-pub
> date > test.txt
> git add test.txt
> git commit -m "test publish from ci-builds.apache.org" test.txt
> git push origin asf-staging-test
>
> The trick and where I'm stuck is that we're using `master` as our main
> branch for https://tomee.apache.org and Jenkins is setup to only let us
> push a branch called `asf-site` or `asf-staging-*`
>
> I've attempted to switch `tomee-site-pub` from `master` to `asf-site`, but
> it doesn't seem to work.  I've filed a ticket with Infra and will keep you
> updated:
>
>  - https://issues.apache.org/jira/browse/INFRA-21903
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
>

-- 
Atentamente:
César Hernández.

Re: Automatic website publishing

[David Jencks]

I got this working recently with the Aries website. I just ran ‘git branch 
asf-site’ and pushed and then my script worked. I run this from a Jenkins 
pipeline in the equivalent of tomee-site-generator ( if I remember the tomee 
repo name correctly).

There’s only one Aries pipeline so it should be easy to find if you want to 
take a look.

David jencks.

Sent from my iPhone

> On May 19, 2021, at 6:03 PM, David Blevins  wrote:
> 
> I've been trying to setup automatic website publishing.
> 
> So far I have a test Jenkins job that does a simple commit/push:
> 
> - https://ci-builds.apache.org/job/Tomee/job/site-publish
> 
> At the moment it's just a simple Freestyle job with a test script to see a 
> successful commit/push work:
> 
>git clone https://gitbox.apache.org/repos/asf/tomee-site-pub.git -b 
> asf-staging-test
>cd tomee-site-pub
>date > test.txt
>git add test.txt
>git commit -m "test publish from ci-builds.apache.org" test.txt
>git push origin asf-staging-test
> 
> The trick and where I'm stuck is that we're using `master` as our main branch 
> for https://tomee.apache.org and Jenkins is setup to only let us push a 
> branch called `asf-site` or `asf-staging-*`
> 
> I've attempted to switch `tomee-site-pub` from `master` to `asf-site`, but it 
> doesn't seem to work.  I've filed a ticket with Infra and will keep you 
> updated:
> 
> - https://issues.apache.org/jira/browse/INFRA-21903
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 

Automatic website publishing

[David Blevins]

I've been trying to setup automatic website publishing.

So far I have a test Jenkins job that does a simple commit/push:

 - https://ci-builds.apache.org/job/Tomee/job/site-publish

At the moment it's just a simple Freestyle job with a test script to see a 
successful commit/push work:

git clone https://gitbox.apache.org/repos/asf/tomee-site-pub.git -b 
asf-staging-test
cd tomee-site-pub
date > test.txt
git add test.txt
git commit -m "test publish from ci-builds.apache.org" test.txt
git push origin asf-staging-test

The trick and where I'm stuck is that we're using `master` as our main branch 
for https://tomee.apache.org and Jenkins is setup to only let us push a branch 
called `asf-site` or `asf-staging-*`

I've attempted to switch `tomee-site-pub` from `master` to `asf-site`, but it 
doesn't seem to work.  I've filed a ticket with Infra and will keep you updated:

 - https://issues.apache.org/jira/browse/INFRA-21903


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com



smime.p7s
Description: S/MIME cryptographic signature

TOMEE-3733 - Results page for website

[Cesar Hernandez]

Hi,

I started to work on the website to add a new page to display the Jakarta
EE TCK summary results base
on the  information required by Eclipse Foundation Technology Compatibility
Kit License [1]
I just created  https://issues.apache.org/jira/browse/TOMEE-3733 and PR is
also available with the first
iteration: https://github.com/apache/tomee-site-generator/pull/22

As a side note, at the beginning I struggle a bit trying to run locally the
project
https://github.com/apache/tomee-site-generator/ because when I tried to run
 mvn compile -Djbake.http=true
the server failed to start with java.lang.IllegalArgumentException
at org.apache.xbean.asm5.ClassReader exception [2]

To fix this I had to downgrade the tika-parsers from 1.25 to 1.17 because
according
to 1.17 release note [3] the project dropped support for Java 7 around that
version.
I made sure that download-ng.java worked fine before and after the change
so no regressions were
introduced by downgrading the tika-parsers since the jar is only used when
running
org.apache.tomee.website.DownloadsNG.java standalone runner.


[1]
https://www.eclipse.org/legal/tck.php

[2]
java.lang.IllegalArgumentException: java.lang.IllegalArgumentException
at org.apache.tomee.embedded.Container.deploy(Container.java:272)
at
org.apache.tomee.embedded.Container.deployPathsAsWebapp(Container.java:228)
at
org.apache.tomee.embedded.Container.deployClasspathAsWebApp(Container.java:193)
at
org.apache.tomee.embedded.Container.deployClasspathAsWebApp(Container.java:173)
at
org.apache.tomee.embedded.Container.deployClasspathAsWebApp(Container.java:164)
at org.apache.tomee.website.JBake.main(JBake.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:282)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException
at org.apache.xbean.asm5.ClassReader.(Unknown Source)
at org.apache.xbean.asm5.ClassReader.(Unknown Source)
at org.apache.xbean.asm5.ClassReader.(Unknown Source)
at
org.apache.xbean.finder.AnnotationFinder.readClassDef(AnnotationFinder.java:1169)
at
org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:147)
at
org.apache.xbean.finder.AnnotationFinder.(AnnotationFinder.java:160)
at
org.apache.openejb.config.FinderFactory$OpenEJBAnnotationFinder.(FinderFactory.java:546)
at org.apache.tomee.embedded.Container.deploy(Container.java:268)

[3]
https://archive.apache.org/dist/tika/CHANGES-1.17.txt
-- 
Atentamente:
César Hernández.

Re: Website

[Jonathan Gallimore]

I personally have issues with all of them. GitHub actions is the one I have
the least knowledge of. If someone specifically wants to work on setting
this up on GitHub actions, there's certainly no objections from me. While I
appreciate the information in the ticket, I don't have enough knowledge to
take that and apply it. I'm happy to learn, but have a lot on the todo list
at the moment. A manual copy to the git repo is fine for now.

Jon

On Wed, Oct 21, 2020 at 5:37 AM David Jencks 
wrote:

>
>
> > On Oct 20, 2020, at 6:11 PM, David Blevins 
> wrote:
> >
> >> On Oct 20, 2020, at 7:11 AM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> >>
> >> Could I get some pointers on publishing the website? I guess its
> changed as
> >> we don't have the CMS any more.
> >>
> >> I have some updates I'd like to get on there, including new download
> links
> >> and updating documentation. I've pushed some updates to SVN, if that
> helps.
> >> :)
> >
> > If you can help with the documentation that'd be great.  The short
> version is everything is the same except now we publish to this git repo
> instead of SVN.
> >
> > - https://github.com/apache/tomee-site-pub
> >
> > The convenience code that does the copy and svn update needs to get
> updated, but short of that there's nothing stopping a manual copy of the
> generated files into a git clone and doing an add/commit/push.
> >
> > After the push, you're done.  Just wait a bit and changes will show up.
> No need to visit https://cms.apache.org/tomee/publish anymore.
> >
> > Long term, Apache has a special Jenkins node that has permissions to
> publish.  Eventually we should set that up to run the generator and check
> in the new content automatically.
> >
>
> Personally I find both jenkins and buildbot 100% incomprehensible.  It
> looks like it may be possible to use GitHub actions to publish websites;
>
>[
> https://issues.apache.org/jira/browse/INFRA-20633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217967#comment-17217967
> <
> https://issues.apache.org/jira/browse/INFRA-20633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217967#comment-17217967>
> ]
>
> Gavin McDonald commented on INFRA-20633:
> 
>
> in combination with Github Actions committing to the same repository as
> the action, to the asf-site branch, then this is possible with a built in
> GHA token. asf-site branch would then be published by configuring a
> .asf.yaml file accordingly.
>
> Example code to use for a built in GHA token:
>
> with:
>repo-token: ${{ secrets.GITHUB_TOKEN }}
>
> Would you like to give that a try?
>
> David Jencks

Re: Website

[Jonathan Gallimore]

Awesome, thanks! I'll give that a shot now.

> The convenience code that does the copy and svn update needs to get
updated, but short of that there's nothing stopping a manual copy of the
generated files into a git clone and doing an add/commit/push.

We had convenience code that did that? I've been manually copying stuff
across to SVN for years!

Jon

On Wed, Oct 21, 2020 at 2:12 AM David Blevins 
wrote:

> > On Oct 20, 2020, at 7:11 AM, Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> >
> > Could I get some pointers on publishing the website? I guess its changed
> as
> > we don't have the CMS any more.
> >
> > I have some updates I'd like to get on there, including new download
> links
> > and updating documentation. I've pushed some updates to SVN, if that
> helps.
> > :)
>
> If you can help with the documentation that'd be great.  The short version
> is everything is the same except now we publish to this git repo instead of
> SVN.
>
>  - https://github.com/apache/tomee-site-pub
>
> The convenience code that does the copy and svn update needs to get
> updated, but short of that there's nothing stopping a manual copy of the
> generated files into a git clone and doing an add/commit/push.
>
> After the push, you're done.  Just wait a bit and changes will show up.
> No need to visit https://cms.apache.org/tomee/publish anymore.
>
> Long term, Apache has a special Jenkins node that has permissions to
> publish.  Eventually we should set that up to run the generator and check
> in the new content automatically.
>
>
> -David
>
>

Re: Website

[David Jencks]

> On Oct 20, 2020, at 6:11 PM, David Blevins  wrote:
> 
>> On Oct 20, 2020, at 7:11 AM, Jonathan Gallimore 
>>  wrote:
>> 
>> Could I get some pointers on publishing the website? I guess its changed as
>> we don't have the CMS any more.
>> 
>> I have some updates I'd like to get on there, including new download links
>> and updating documentation. I've pushed some updates to SVN, if that helps.
>> :)
> 
> If you can help with the documentation that'd be great.  The short version is 
> everything is the same except now we publish to this git repo instead of SVN.
> 
> - https://github.com/apache/tomee-site-pub
> 
> The convenience code that does the copy and svn update needs to get updated, 
> but short of that there's nothing stopping a manual copy of the generated 
> files into a git clone and doing an add/commit/push.
> 
> After the push, you're done.  Just wait a bit and changes will show up.  No 
> need to visit https://cms.apache.org/tomee/publish anymore.
> 
> Long term, Apache has a special Jenkins node that has permissions to publish. 
>  Eventually we should set that up to run the generator and check in the new 
> content automatically.
> 

Personally I find both jenkins and buildbot 100% incomprehensible.  It looks 
like it may be possible to use GitHub actions to publish websites; 

   [ 
https://issues.apache.org/jira/browse/INFRA-20633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217967#comment-17217967
 
<https://issues.apache.org/jira/browse/INFRA-20633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17217967#comment-17217967>
 ] 

Gavin McDonald commented on INFRA-20633:


in combination with Github Actions committing to the same repository as the 
action, to the asf-site branch, then this is possible with a built in GHA 
token. asf-site branch would then be published by configuring a .asf.yaml file 
accordingly.

Example code to use for a built in GHA token:

with:
   repo-token: ${{ secrets.GITHUB_TOKEN }}

Would you like to give that a try?

David Jencks

Re: Website

[David Blevins]

> On Oct 20, 2020, at 7:11 AM, Jonathan Gallimore 
>  wrote:
> 
> Could I get some pointers on publishing the website? I guess its changed as
> we don't have the CMS any more.
> 
> I have some updates I'd like to get on there, including new download links
> and updating documentation. I've pushed some updates to SVN, if that helps.
> :)

If you can help with the documentation that'd be great.  The short version is 
everything is the same except now we publish to this git repo instead of SVN.

 - https://github.com/apache/tomee-site-pub

The convenience code that does the copy and svn update needs to get updated, 
but short of that there's nothing stopping a manual copy of the generated files 
into a git clone and doing an add/commit/push.

After the push, you're done.  Just wait a bit and changes will show up.  No 
need to visit https://cms.apache.org/tomee/publish anymore.

Long term, Apache has a special Jenkins node that has permissions to publish.  
Eventually we should set that up to run the generator and check in the new 
content automatically.


-David



smime.p7s
Description: S/MIME cryptographic signature

Website

[Jonathan Gallimore]

Could I get some pointers on publishing the website? I guess its changed as
we don't have the CMS any more.

I have some updates I'd like to get on there, including new download links
and updating documentation. I've pushed some updates to SVN, if that helps.
:)

Jon

Re: Your project's website

[David Blevins]

> On Sep 4, 2020, at 7:09 PM, David Blevins  wrote:
> 
> Amazing work, David -- sorry for not saying so sooner!
> 
> Since we now have our git repo with all the current html and the required 
> yaml file, I'll file a ticket with infra to have us cutover from 
> CMS/subversion to the git publishing.

Ticket filed for those who want to track/participate:

 - https://issues.apache.org/jira/browse/INFRA-20820


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: Your project's website

[David Blevins]

Amazing work, David -- sorry for not saying so sooner!

Since we now have our git repo with all the current html and the required yaml 
file, I'll file a ticket with infra to have us cutover from CMS/subversion to 
the git publishing.

All other topics such as Antora, etc. still on the table and probably even 
easier to pursue once we get out from behind the CMS.


-David


> On Aug 29, 2020, at 9:02 AM, David Jencks  wrote:
> 
> The content history is now in tomee-site-pub.  I added an .asf.yaml file:
> 
> ```
> notifications:
>  commits: site-...@tomee.apache.org
>  issues: site-...@tomee.apache.org
>  pullrequests: site-...@tomee.apache.org
>  jira_options: link label link label
> 
> # this staging config will publish any commits to 
> https://tomee-beta.staged.apache.org
> #staging:
> #  profile: beta
> #  whoami: master
> ```
> 
> that directs mail to site-...@tomee.apache.org.
> 
> Mail notifications are turned back on.
> 
> For reference, here’s how far I’ve got with publishing the Aries site:
> 
> ```
> #!/bin/bash
> 
> npm run clean-install
> 
> rm -rf build
> mkdir -p build/site
> # clone the aries-site-pub repo
> (
> cd build/site
> git clone --depth 1 g...@github.com:apache/aries-site-pub.git .
> git rm -r .
> )
> 
> npm run build-noclean
> 
> (
> cd build/site
> git add .
> git commit -m "site build"
> git push origin master
> )
> ```
> 
> This is for an Antora-only site; the site build is actually `npm run 
> build-noclean`.  So far I only know how to run this locally, buildbot and 
> jenkins remain mysteries to me.  I don’t see why this couldn’t be run on 
> GitHub using GitHub actions, but it might be against infra policy.
> 
> David Jencks
> 
>> On Aug 27, 2020, at 9:51 PM, David Jencks  wrote:
>> 
>> Maybe my memory’s just a bit slow.
>> 
>> svn log https://svn.apache.org/repos/infra/websites/production/tomee/content 
>> <https://svn.apache.org/repos/infra/websites/production/tomee/content> shows 
>> that I’ve found the last commit.
>> 
>> David Jencks
>> 
>>> On Aug 27, 2020, at 9:47 PM, David Jencks >> <mailto:david.a.jen...@gmail.com>> wrote:
>>> 
>>> I’m afraid I no longer understand how svn works or how to see what’s in it. 
>>>  I can’t find the published site on viewvc.
>>> 
>>> The last imported-to-git revision I got was 
>>> 
>>> commit d971bdc415a5aacedad7a73bfc59a72abe0ddc09 (HEAD -> master, svn/trunk)
>>> Author: Daniel Gruno mailto:humbed...@apache.org>>
>>> Date:   Mon Aug 10 17:53:26 2020 +
>>> 
>>>Publishing svnmucc operation to tomee site by humbedooh
>>> 
>>>git-svn-id: 
>>> https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188
>>>  
>>> <https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188>
>>>  90ea9780-b833-de11-8433-001ec94261de
>>> 
>>> 
>>> however there appeared to be a git gc error after that.  I can’t figure out 
>>> how to confirm that this is indeed the last site commit, although running 
>>> the svn2git command again doesn’t find anything more.
>>> 
>>> What I can find in https://svn.apache.org/viewvc/tomee/site/trunk/?view=log 
>>> <https://svn.apache.org/viewvc/tomee/site/trunk/?view=log> is
>>> 
>>> Revision 1880750 
>>> <https://svn.apache.org/viewvc?view=revision=1880750> - Directory 
>>> Listing <https://svn.apache.org/viewvc/tomee/site/trunk/?pathrev=1880750> 
>>> Modified Mon Aug 10 17:17:31 2020 UTC (2 weeks, 3 days ago) by dblevins
>>> force cms to update
>>> so the time frame seems approximately right.
>>> 
>>> Can anyone confirm I’ve got the whole history?
>>> 
>>> Thanks
>>> David Jencks
>>> 
>>>> On Aug 27, 2020, at 7:44 PM, David Jencks >>> <mailto:david.a.jen...@gmail.com>> wrote:
>>>> 
>>>> tomee-site-pub created
>>>> site-...@tomee.apache.org <mailto:site-...@tomee.apache.org> requested
>>>> INFRA-20781 <https://issues.apache.org/jira/browse/INFRA-20781> (disable 
>>>> commit emails) opened
>>>> svn2git still in process.
>>>> 
>>>> If things go really quickly I might be able to push tomorrow.
>>>> 
>>>> David Jencks
>>>> 
>>>>> On Aug 27, 2020, at 4:42 PM, David Blevins >>>> <mailto:dblev...@tomitribe.com>> wrote:
>>>>> 
>>>

Re: Your project's website

[David Jencks]

The content history is now in tomee-site-pub.  I added an .asf.yaml file:

```
notifications:
  commits: site-...@tomee.apache.org
  issues: site-...@tomee.apache.org
  pullrequests: site-...@tomee.apache.org
  jira_options: link label link label

# this staging config will publish any commits to 
https://tomee-beta.staged.apache.org
#staging:
#  profile: beta
#  whoami: master
```

that directs mail to site-...@tomee.apache.org.

Mail notifications are turned back on.

For reference, here’s how far I’ve got with publishing the Aries site:

```
#!/bin/bash

npm run clean-install

rm -rf build
mkdir -p build/site
# clone the aries-site-pub repo
(
cd build/site
git clone --depth 1 g...@github.com:apache/aries-site-pub.git .
git rm -r .
)

npm run build-noclean

(
cd build/site
git add .
git commit -m "site build"
git push origin master
)
```

This is for an Antora-only site; the site build is actually `npm run 
build-noclean`.  So far I only know how to run this locally, buildbot and 
jenkins remain mysteries to me.  I don’t see why this couldn’t be run on GitHub 
using GitHub actions, but it might be against infra policy.

David Jencks

> On Aug 27, 2020, at 9:51 PM, David Jencks  wrote:
> 
> Maybe my memory’s just a bit slow.
> 
> svn log https://svn.apache.org/repos/infra/websites/production/tomee/content 
> <https://svn.apache.org/repos/infra/websites/production/tomee/content> shows 
> that I’ve found the last commit.
> 
> David Jencks
> 
>> On Aug 27, 2020, at 9:47 PM, David Jencks > <mailto:david.a.jen...@gmail.com>> wrote:
>> 
>> I’m afraid I no longer understand how svn works or how to see what’s in it.  
>> I can’t find the published site on viewvc.
>> 
>> The last imported-to-git revision I got was 
>> 
>> commit d971bdc415a5aacedad7a73bfc59a72abe0ddc09 (HEAD -> master, svn/trunk)
>> Author: Daniel Gruno mailto:humbed...@apache.org>>
>> Date:   Mon Aug 10 17:53:26 2020 +
>> 
>> Publishing svnmucc operation to tomee site by humbedooh
>> 
>> git-svn-id: 
>> https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188 
>> <https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188>
>>  90ea9780-b833-de11-8433-001ec94261de
>> 
>> 
>> however there appeared to be a git gc error after that.  I can’t figure out 
>> how to confirm that this is indeed the last site commit, although running 
>> the svn2git command again doesn’t find anything more.
>> 
>> What I can find in https://svn.apache.org/viewvc/tomee/site/trunk/?view=log 
>> <https://svn.apache.org/viewvc/tomee/site/trunk/?view=log> is
>> 
>> Revision 1880750 
>> <https://svn.apache.org/viewvc?view=revision=1880750> - Directory 
>> Listing <https://svn.apache.org/viewvc/tomee/site/trunk/?pathrev=1880750> 
>> Modified Mon Aug 10 17:17:31 2020 UTC (2 weeks, 3 days ago) by dblevins
>> force cms to update
>> so the time frame seems approximately right.
>> 
>> Can anyone confirm I’ve got the whole history?
>> 
>> Thanks
>> David Jencks
>> 
>>> On Aug 27, 2020, at 7:44 PM, David Jencks >> <mailto:david.a.jen...@gmail.com>> wrote:
>>> 
>>> tomee-site-pub created
>>> site-...@tomee.apache.org <mailto:site-...@tomee.apache.org> requested
>>> INFRA-20781 <https://issues.apache.org/jira/browse/INFRA-20781> (disable 
>>> commit emails) opened
>>> svn2git still in process.
>>> 
>>> If things go really quickly I might be able to push tomorrow.
>>> 
>>> David Jencks
>>> 
>>>> On Aug 27, 2020, at 4:42 PM, David Blevins >>> <mailto:dblev...@tomitribe.com>> wrote:
>>>> 
>>>>> On Aug 27, 2020, at 1:58 PM, David Jencks >>>> <mailto:david.a.jen...@gmail.com>> wrote:
>>>>> 
>>>>> I’ve been “warming up” with the Aries website and did this recently for 
>>>>> them.  I think I can do this easily.  What do we want the TomEE repo to 
>>>>> be named? I’d suggest tomee-site-pub.
>>>> 
>>>> I was struggling to think of a good name.  `tomee-site-pub` is great!
>>>> 
>>>>> On Aug 27, 2020, at 2:11 PM, David Jencks >>>> <mailto:david.a.jen...@gmail.com>> wrote:
>>>>> 
>>>>> I started…. should be done in a few hours.  Next step is to create the 
>>>>> apache git repo using self-serve and ask infra to turn off commit emails 
>>>>> for the push (which may take a day or so).
>>>>> 
>>>>> Where sho

Re: Your project's website

[David Jencks]

Maybe my memory’s just a bit slow.

svn log https://svn.apache.org/repos/infra/websites/production/tomee/content 
shows that I’ve found the last commit.

David Jencks

> On Aug 27, 2020, at 9:47 PM, David Jencks  wrote:
> 
> I’m afraid I no longer understand how svn works or how to see what’s in it.  
> I can’t find the published site on viewvc.
> 
> The last imported-to-git revision I got was 
> 
> commit d971bdc415a5aacedad7a73bfc59a72abe0ddc09 (HEAD -> master, svn/trunk)
> Author: Daniel Gruno mailto:humbed...@apache.org>>
> Date:   Mon Aug 10 17:53:26 2020 +
> 
> Publishing svnmucc operation to tomee site by humbedooh
> 
> git-svn-id: 
> https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188 
> <https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188>
>  90ea9780-b833-de11-8433-001ec94261de
> 
> 
> however there appeared to be a git gc error after that.  I can’t figure out 
> how to confirm that this is indeed the last site commit, although running the 
> svn2git command again doesn’t find anything more.
> 
> What I can find in https://svn.apache.org/viewvc/tomee/site/trunk/?view=log 
> <https://svn.apache.org/viewvc/tomee/site/trunk/?view=log> is
> 
> Revision 1880750 
> <https://svn.apache.org/viewvc?view=revision=1880750> - Directory 
> Listing <https://svn.apache.org/viewvc/tomee/site/trunk/?pathrev=1880750> 
> Modified Mon Aug 10 17:17:31 2020 UTC (2 weeks, 3 days ago) by dblevins
> force cms to update
> so the time frame seems approximately right.
> 
> Can anyone confirm I’ve got the whole history?
> 
> Thanks
> David Jencks
> 
>> On Aug 27, 2020, at 7:44 PM, David Jencks > <mailto:david.a.jen...@gmail.com>> wrote:
>> 
>> tomee-site-pub created
>> site-...@tomee.apache.org <mailto:site-...@tomee.apache.org> requested
>> INFRA-20781 <https://issues.apache.org/jira/browse/INFRA-20781> (disable 
>> commit emails) opened
>> svn2git still in process.
>> 
>> If things go really quickly I might be able to push tomorrow.
>> 
>> David Jencks
>> 
>>> On Aug 27, 2020, at 4:42 PM, David Blevins >> <mailto:dblev...@tomitribe.com>> wrote:
>>> 
>>>> On Aug 27, 2020, at 1:58 PM, David Jencks >>> <mailto:david.a.jen...@gmail.com>> wrote:
>>>> 
>>>> I’ve been “warming up” with the Aries website and did this recently for 
>>>> them.  I think I can do this easily.  What do we want the TomEE repo to be 
>>>> named? I’d suggest tomee-site-pub.
>>> 
>>> I was struggling to think of a good name.  `tomee-site-pub` is great!
>>> 
>>>> On Aug 27, 2020, at 2:11 PM, David Jencks >>> <mailto:david.a.jen...@gmail.com>> wrote:
>>>> 
>>>> I started…. should be done in a few hours.  Next step is to create the 
>>>> apache git repo using self-serve and ask infra to turn off commit emails 
>>>> for the push (which may take a day or so).
>>>> 
>>>> Where should commit emails for this repo go?  For aries I created a 
>>>> site-...@aries.apache.org <mailto:site-...@aries.apache.org> list since I 
>>>> don’t think anyone is interested in looking at the html changes directly.  
>>>> Should I ask for such a list for TomEE?  Sending the emails there is 
>>>> configured with the .asf.yaml file in the root of the repo.
>>> 
>>> I think site-pub@ is another very good suggestion.
>>> 
>>> Thank you so much for taking this one up, David!
>>> 
>>> I'm pretty excited to ditch the CMS!  The last publish I did took hours of 
>>> checking/poking and prodding just to get the updates to go live as the 
>>> commit size was so large and there are 2 repos to go through.  It'll be 
>>> wonderful to be done with that.
>>> 
>>> 
>>> -David
>>> 
>> 
> 

Re: Your project's website

[David Jencks]

I’m afraid I no longer understand how svn works or how to see what’s in it.  I 
can’t find the published site on viewvc.

The last imported-to-git revision I got was 

commit d971bdc415a5aacedad7a73bfc59a72abe0ddc09 (HEAD -> master, svn/trunk)
Author: Daniel Gruno 
Date:   Mon Aug 10 17:53:26 2020 +

Publishing svnmucc operation to tomee site by humbedooh

git-svn-id: 
https://svn.apache.org/repos/infra/websites/production/tomee/content@1064188 
90ea9780-b833-de11-8433-001ec94261de


however there appeared to be a git gc error after that.  I can’t figure out how 
to confirm that this is indeed the last site commit, although running the 
svn2git command again doesn’t find anything more.

What I can find in https://svn.apache.org/viewvc/tomee/site/trunk/?view=log is

Revision 1880750 <https://svn.apache.org/viewvc?view=revision=1880750> 
- Directory Listing 
<https://svn.apache.org/viewvc/tomee/site/trunk/?pathrev=1880750> 
Modified Mon Aug 10 17:17:31 2020 UTC (2 weeks, 3 days ago) by dblevins
force cms to update
so the time frame seems approximately right.

Can anyone confirm I’ve got the whole history?

Thanks
David Jencks

> On Aug 27, 2020, at 7:44 PM, David Jencks  wrote:
> 
> tomee-site-pub created
> site-...@tomee.apache.org <mailto:site-...@tomee.apache.org> requested
> INFRA-20781 <https://issues.apache.org/jira/browse/INFRA-20781> (disable 
> commit emails) opened
> svn2git still in process.
> 
> If things go really quickly I might be able to push tomorrow.
> 
> David Jencks
> 
>> On Aug 27, 2020, at 4:42 PM, David Blevins > <mailto:dblev...@tomitribe.com>> wrote:
>> 
>>> On Aug 27, 2020, at 1:58 PM, David Jencks >> <mailto:david.a.jen...@gmail.com>> wrote:
>>> 
>>> I’ve been “warming up” with the Aries website and did this recently for 
>>> them.  I think I can do this easily.  What do we want the TomEE repo to be 
>>> named? I’d suggest tomee-site-pub.
>> 
>> I was struggling to think of a good name.  `tomee-site-pub` is great!
>> 
>>> On Aug 27, 2020, at 2:11 PM, David Jencks >> <mailto:david.a.jen...@gmail.com>> wrote:
>>> 
>>> I started…. should be done in a few hours.  Next step is to create the 
>>> apache git repo using self-serve and ask infra to turn off commit emails 
>>> for the push (which may take a day or so).
>>> 
>>> Where should commit emails for this repo go?  For aries I created a 
>>> site-...@aries.apache.org <mailto:site-...@aries.apache.org> list since I 
>>> don’t think anyone is interested in looking at the html changes directly.  
>>> Should I ask for such a list for TomEE?  Sending the emails there is 
>>> configured with the .asf.yaml file in the root of the repo.
>> 
>> I think site-pub@ is another very good suggestion.
>> 
>> Thank you so much for taking this one up, David!
>> 
>> I'm pretty excited to ditch the CMS!  The last publish I did took hours of 
>> checking/poking and prodding just to get the updates to go live as the 
>> commit size was so large and there are 2 repos to go through.  It'll be 
>> wonderful to be done with that.
>> 
>> 
>> -David
>> 
> 

Re: Your project's website

[David Jencks]

tomee-site-pub created
site-...@tomee.apache.org requested
INFRA-20781 <https://issues.apache.org/jira/browse/INFRA-20781> (disable commit 
emails) opened
svn2git still in process.

If things go really quickly I might be able to push tomorrow.

David Jencks

> On Aug 27, 2020, at 4:42 PM, David Blevins  wrote:
> 
>> On Aug 27, 2020, at 1:58 PM, David Jencks  wrote:
>> 
>> I’ve been “warming up” with the Aries website and did this recently for 
>> them.  I think I can do this easily.  What do we want the TomEE repo to be 
>> named? I’d suggest tomee-site-pub.
> 
> I was struggling to think of a good name.  `tomee-site-pub` is great!
> 
>> On Aug 27, 2020, at 2:11 PM, David Jencks  wrote:
>> 
>> I started…. should be done in a few hours.  Next step is to create the 
>> apache git repo using self-serve and ask infra to turn off commit emails for 
>> the push (which may take a day or so).
>> 
>> Where should commit emails for this repo go?  For aries I created a 
>> site-...@aries.apache.org list since I don’t think anyone is interested in 
>> looking at the html changes directly.  Should I ask for such a list for 
>> TomEE?  Sending the emails there is configured with the .asf.yaml file in 
>> the root of the repo.
> 
> I think site-pub@ is another very good suggestion.
> 
> Thank you so much for taking this one up, David!
> 
> I'm pretty excited to ditch the CMS!  The last publish I did took hours of 
> checking/poking and prodding just to get the updates to go live as the commit 
> size was so large and there are 2 repos to go through.  It'll be wonderful to 
> be done with that.
> 
> 
> -David
> 

Re: Your project's website

[David Blevins]

> On Aug 27, 2020, at 1:58 PM, David Jencks  wrote:
> 
> I’ve been “warming up” with the Aries website and did this recently for them. 
>  I think I can do this easily.  What do we want the TomEE repo to be named? 
> I’d suggest tomee-site-pub.

I was struggling to think of a good name.  `tomee-site-pub` is great!

> On Aug 27, 2020, at 2:11 PM, David Jencks  wrote:
> 
> I started…. should be done in a few hours.  Next step is to create the apache 
> git repo using self-serve and ask infra to turn off commit emails for the 
> push (which may take a day or so).
> 
> Where should commit emails for this repo go?  For aries I created a 
> site-...@aries.apache.org list since I don’t think anyone is interested in 
> looking at the html changes directly.  Should I ask for such a list for 
> TomEE?  Sending the emails there is configured with the .asf.yaml file in the 
> root of the repo.

I think site-pub@ is another very good suggestion.

Thank you so much for taking this one up, David!

I'm pretty excited to ditch the CMS!  The last publish I did took hours of 
checking/poking and prodding just to get the updates to go live as the commit 
size was so large and there are 2 repos to go through.  It'll be wonderful to 
be done with that.


-David

Re: Your project's website

[David Jencks]

I started…. should be done in a few hours.  Next step is to create the apache 
git repo using self-serve and ask infra to turn off commit emails for the push 
(which may take a day or so).

Where should commit emails for this repo go?  For aries I created a 
site-...@aries.apache.org list since I don’t think anyone is interested in 
looking at the html changes directly.  Should I ask for such a list for TomEE?  
Sending the emails there is configured with the .asf.yaml file in the root of 
the repo.

David Jencks

> On Aug 27, 2020, at 1:58 PM, David Jencks  wrote:
> 
> I’ve been “warming up” with the Aries website and did this recently for them. 
>  I think I can do this easily.  What do we want the TomEE repo to be named? 
> I’d suggest tomee-site-pub.
> 
> David Jencks
> 
>> On Aug 26, 2020, at 5:41 PM, David Blevins  wrote:
>> 
>> The first step we need to migrate away from the CMS is a git repo to hold 
>> the finished HTML.  With the help of some fine folks on users@infra.a.o here 
>> is the SVN repo that hold our site currently:
>> 
>> - https://svn.apache.org/repos/infra/websites/production/tomee/content/
>> 
>> Cesar, you were the last person to do an SVN to GIT migration.  Do you 
>> recall the steps or have any documents that helped you?
>> 
>> 
>> -- 
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
>> 
>>> On Aug 7, 2020, at 6:16 AM, Andrew Wetmore  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
>>> 
>>> [2]
>>> 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
>>> 
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>> Virus-free.
>>> www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>> 
> 

Re: Your project's website

[David Jencks]

I’ve been “warming up” with the Aries website and did this recently for them.  
I think I can do this easily.  What do we want the TomEE repo to be named? I’d 
suggest tomee-site-pub.

David Jencks

> On Aug 26, 2020, at 5:41 PM, David Blevins  wrote:
> 
> The first step we need to migrate away from the CMS is a git repo to hold the 
> finished HTML.  With the help of some fine folks on users@infra.a.o here is 
> the SVN repo that hold our site currently:
> 
> - https://svn.apache.org/repos/infra/websites/production/tomee/content/
> 
> Cesar, you were the last person to do an SVN to GIT migration.  Do you recall 
> the steps or have any documents that helped you?
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 
>> On Aug 7, 2020, at 6:16 AM, Andrew Wetmore  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
>> 
>> [2]
>> 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
>> 
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>> Virus-free.
>> www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 

Re: Your project's website

[Zowalla, Richard]

We did such migrations in our university a few years ago.
I digged into our documentation, which provided a link to 
https://blokspeed.net/blog/2010/09/converting-from-subversion-to-git

The required authors list can be found here 
https://infra.apache.org/svn-to-git-migration.html

Hope this helps :)


Am Mittwoch, den 26.08.2020, 17:41 -0700 schrieb David Blevins:
> The first step we need to migrate away from the CMS is a git repo to
> hold the finished HTML.  With the help of some fine folks on 
> users@infra.a.o here is the SVN repo that hold our site currently:
> 
>  - 
> https://svn.apache.org/repos/infra/websites/production/tomee/content/
> 
> Cesar, you were the last person to do an SVN to GIT migration.  Do
> you recall the steps or have any documents that helped you?
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

Re: Your project's website

[David Blevins]

The first step we need to migrate away from the CMS is a git repo to hold the 
finished HTML.  With the help of some fine folks on users@infra.a.o here is the 
SVN repo that hold our site currently:

 - https://svn.apache.org/repos/infra/websites/production/tomee/content/

Cesar, you were the last person to do an SVN to GIT migration.  Do you recall 
the steps or have any documents that helped you?


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Aug 7, 2020, at 6:16 AM, Andrew Wetmore  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
> 
> [2]
> 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
> 
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>



smime.p7s
Description: S/MIME cryptographic signature

Re: [Website-Antora] New preview

[David Jencks]

> On Aug 9, 2020, at 8:49 PM, David Blevins  wrote:
> 
>> On Aug 9, 2020, at 8:10 PM, Willes Reis  wrote:
>> 
>>> I’m not sure supplying identical copies of the documentation  that claim
>>> to be for different versions is entirely desirable.  Presumably we need two
>>> copies for javax/jakarta, but I’m not sure the one in tomee-site (from CMS)
>>> or the identical 7.0, 7.1, and 8.0 versions are truly essential.
>>> 
>>> Next I may look into the examples. IIUC the java source for them is going
>>> to remain as javax for the foreseeable future.  I think that means that the
>>> README’s should also remain javax-only. Among other things this should
>>> enable easy inclusion of source-code snippets and avoid confusion when the
>>> doc says jakarta and the source says javax.
>>> 
>>> I suggested earlier that there’s no need for more than one version of the
>>> examples.  I haven’t changed my mind on this and although someone didn’t
>>> seem to like the idea, I didn’t see any arguments why having more than one
>>> version was a good idea.  Since IMO the largest problem with the docs site
>>> is that there’s too much outdated useless and wrong content, and it’s
>>> nearly totally disorganized, I think reducing the size will make everything
>>> else easier.
>>> 
>> 
>> I agree with David Jencks.
>> For sake of organization, I would like to suggest that we keep the
>> documentations isolated by branches, where each branch is a documentation
>> version (7.0.x, 7.1.x, 8.x and 9.x). Therefore, old docs will be
>> kept, while newly created ones evolve, beyond being compatible with
>> Antora's source repositories through branches.
> 
> I'd agree with that as well and it's what we currently have.  I get the 
> impression this is what David points out as a problem.
> 
> We historically have had one base of documentation that applied to all 
> versions.  It's only been in the last year that we've attempted to branch the 
> documentation as described.  I'm the only one who put any effort into it, so 
> it didn't go far.  I do think that's the right long-term approach, but I am 
> sympathetic to the argument with the documentation in the shape it's in we 
> perhaps branched too early.
> 
> I could be on board for focusing on one branch for a while with the plan to 
> return to branching once we get something we like.
> 
> As we have done one doc-base for all the versions over 19 of the last 20 
> years I wouldn't be willing to make that the permanent plan.  A major problem 
> with it is no one deletes anything because "maybe it applies to an older 
> version."  When Romain created the JBake setup he included only a subset of 
> the documentation in an attempt to fix that problem.  The way he did it ended 
> up creating new problems as much of those documents still applied, but I 
> understand what he was trying to solve.
> 

I didn’t notice any differences between any of the doc versions in february 
except fairly different bad attempts to translate from markdown to asciidoc.  
IIRC some pages disappeared but I didn’t see any content updates in the 
versioned docs.

I think it would be a really good idea for someone (hopefully someone more 
familiar with TomEE than me) to spend some time and organize the existing docs 
by hand.  To me, the current “sort by tag” approach is an admission that the 
docs are incoherent and will stay that way.  One way this might work would be 
to copy the “originals” from common to 7.0.x, then organize them there, and 
then propagate the organization to include stubs in the other versions, 
removing the copy from common.  I suppose it might be possible to write a 
script to produce an include stub matching every “original” in all the copied 
versions, in which case we could start by moving the “originals” from common to 
7.0.x.

David Jencks


> 
> 
> -David

Re: [Website-Antora] New preview

[David Blevins]

> On Aug 9, 2020, at 8:10 PM, Willes Reis  wrote:
> 
>> I’m not sure supplying identical copies of the documentation  that claim
>> to be for different versions is entirely desirable.  Presumably we need two
>> copies for javax/jakarta, but I’m not sure the one in tomee-site (from CMS)
>> or the identical 7.0, 7.1, and 8.0 versions are truly essential.
>> 
>> Next I may look into the examples. IIUC the java source for them is going
>> to remain as javax for the foreseeable future.  I think that means that the
>> README’s should also remain javax-only. Among other things this should
>> enable easy inclusion of source-code snippets and avoid confusion when the
>> doc says jakarta and the source says javax.
>> 
>> I suggested earlier that there’s no need for more than one version of the
>> examples.  I haven’t changed my mind on this and although someone didn’t
>> seem to like the idea, I didn’t see any arguments why having more than one
>> version was a good idea.  Since IMO the largest problem with the docs site
>> is that there’s too much outdated useless and wrong content, and it’s
>> nearly totally disorganized, I think reducing the size will make everything
>> else easier.
>> 
> 
> I agree with David Jencks.
> For sake of organization, I would like to suggest that we keep the
> documentations isolated by branches, where each branch is a documentation
> version (7.0.x, 7.1.x, 8.x and 9.x). Therefore, old docs will be
> kept, while newly created ones evolve, beyond being compatible with
> Antora's source repositories through branches.

I'd agree with that as well and it's what we currently have.  I get the 
impression this is what David points out as a problem.

We historically have had one base of documentation that applied to all 
versions.  It's only been in the last year that we've attempted to branch the 
documentation as described.  I'm the only one who put any effort into it, so it 
didn't go far.  I do think that's the right long-term approach, but I am 
sympathetic to the argument with the documentation in the shape it's in we 
perhaps branched too early.

I could be on board for focusing on one branch for a while with the plan to 
return to branching once we get something we like.

As we have done one doc-base for all the versions over 19 of the last 20 years 
I wouldn't be willing to make that the permanent plan.  A major problem with it 
is no one deletes anything because "maybe it applies to an older version."  
When Romain created the JBake setup he included only a subset of the 
documentation in an attempt to fix that problem.  The way he did it ended up 
creating new problems as much of those documents still applied, but I 
understand what he was trying to solve.


-David

Re: [Website-Antora] New preview

[Willes Reis]

> I’m not sure supplying identical copies of the documentation  that claim
> to be for different versions is entirely desirable.  Presumably we need two
> copies for javax/jakarta, but I’m not sure the one in tomee-site (from CMS)
> or the identical 7.0, 7.1, and 8.0 versions are truly essential.
>
> Next I may look into the examples. IIUC the java source for them is going
> to remain as javax for the foreseeable future.  I think that means that the
> README’s should also remain javax-only. Among other things this should
> enable easy inclusion of source-code snippets and avoid confusion when the
> doc says jakarta and the source says javax.
>
> I suggested earlier that there’s no need for more than one version of the
> examples.  I haven’t changed my mind on this and although someone didn’t
> seem to like the idea, I didn’t see any arguments why having more than one
> version was a good idea.  Since IMO the largest problem with the docs site
> is that there’s too much outdated useless and wrong content, and it’s
> nearly totally disorganized, I think reducing the size will make everything
> else easier.
>

I agree with David Jencks.
For sake of organization, I would like to suggest that we keep the
documentations isolated by branches, where each branch is a documentation
version (7.0.x, 7.1.x, 8.x and 9.x). Therefore, old docs will be
kept, while newly created ones evolve, beyond being compatible with
Antora's source repositories through branches.

Willes.

Re: [Website-Antora] New preview

[David Jencks]

I’ve rebased my branches on current work, added 9.0 docs and implemented 
javax/jakarta via an attribute, and pushed the preview.

You can see the javax/jakarta at work by looking at different versions of 
https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/9.0/jpa-concepts.html#_valid_resource_local_unit_usage

I think a few pages got added to explain 9.0 but I don’t think they are in the 
right place in any of my branches.  Could someone point me to all the new pages?

I asked about this in perhaps february with no response, but I’ll try again 
since the situation is now 25% worse.

With the exception of a few pages getting dropped as time went on, there are 
now 5 identical copies of every page in the docs component.  The original is in 
tomes-site, where I found it.  In order to prevent the sort of unintended drift 
that plagues the current site, the other copies are all made to be identical  
with include stubs, like this:

include::{common-vc}::page$unix-daemon.adoc[]

I’m not sure supplying identical copies of the documentation  that claim to be 
for different versions is entirely desirable.  Presumably we need two copies 
for javax/jakarta, but I’m not sure the one in tomee-site (from CMS) or the 
identical 7.0, 7.1, and 8.0 versions are truly essential.

Next I may look into the examples. IIUC the java source for them is going to 
remain as javax for the foreseeable future.  I think that means that the 
README’s should also remain javax-only. Among other things this should enable 
easy inclusion of source-code snippets and avoid confusion when the doc says 
jakarta and the source says javax.

I suggested earlier that there’s no need for more than one version of the 
examples.  I haven’t changed my mind on this and although someone didn’t seem 
to like the idea, I didn’t see any arguments why having more than one version 
was a good idea.  Since IMO the largest problem with the docs site is that 
there’s too much outdated useless and wrong content, and it’s nearly totally 
disorganized, I think reducing the size will make everything else easier.

BTW if anyone wants to try editing asciidoc I recommend using intellij tools 
with the asciidctor plugin.  It’s fairly Antora-aware and is by far the best 
tool I’ve found.  IDEA CE works fine for this.

David Jencks


> On Aug 7, 2020, at 10:56 PM, David Jencks  wrote:
> 
> 
> 
>> On Aug 7, 2020, at 6:16 PM, David Blevins  wrote:
>> 
>>> On Aug 7, 2020, at 5:02 PM, David Jencks  wrote:
>>> 
>>> It’s possible to customize antora to do some sorts of editing on the fly, 
>>> but I really don’t recommend it.  The first two possibilities are also 
>>> pretty bad ideas near Antora.
>> 
>> Do you have a link on the editing capabilities?
> 
> As far as I know no one has ever done this, and as I said I think it’s a 
> really bad idea.  However, Antora is flexible enough so this is possible.
> 
> IMO magic is really bad news in something like a website that no one is 
> really interested in dedicating themselves to.  Any time you have something 
> happening that is the least bit non-standard and non-obvious you dramatically 
> increase the barriers to contribution and maintenance.  Maven is sort of 
> awful, but it’s fairly consistent, and it pretty much brought about a 
> revolution in build systems by a great deal of transparency and consistency.  
> I’m going to argue really strongly against any solution that isn’t entirely 
> visible from the source.  The two solutions I know of are two copies of the 
> docs, with the EE prefix hardcoded, and one copy with the prefix as an 
> attribute, i.e. asciidoctor “variable”.
> 
> Lets look for a solution that is completely visible in the adoc source.  I 
> think an ee prefix attribute will do that, lets try it.
> 
>> 
>> Recommended or not, is it possible to do either of the last two and what 
>> would that look like?
> 
> It would look like incomprehensible magic, and no one would be able to figure 
> out how the result was obtained.  At least I wouldn’t be able to if I stepped 
> away for a week.
> 
>> 
>>> I think we should take a look at the attribute idea in action before ruling 
>>> it out.  For one thing, it might be possible to check for non-use of the 
>>> attribute by grepping for javax or jakarta, maybe in a pre-commit hook.
>> 
>> We can certainly take a look.  Even if the feature doesn't get used for this 
>> problem doesn't mean learning about it is bad -- we may see another valuable 
>> way to use it.
>> 
>> In terms of commit hooks, if I had to chose between writing tool/script to 
>> force a developer to do something or writing a tool/script to do it for 
>> them, I'll always favor the latter if that's possible.
> 
> Well, the commit hook might replace either of ‘javax’ or ‘jakarta’ with 
> {ee-prefix}.  I imagine there would need to be a way to use the other prefix 
> in a particular document.  That could be another 2 attributes.
> 
> David Jencks
> 
>> 
>> 
>> -David
>> 
> 

Re: [Website-Antora] New preview

[Evaldo Junior]

David, this site is very beautiful, the art is pretty coll, a little
different.


Evaldo Junior


Em sáb., 8 de ago. de 2020 às 02:57, David Jencks 
escreveu:

>
>
> > On Aug 7, 2020, at 6:16 PM, David Blevins 
> wrote:
> >
> >> On Aug 7, 2020, at 5:02 PM, David Jencks 
> wrote:
> >>
> >> It’s possible to customize antora to do some sorts of editing on the
> fly, but I really don’t recommend it.  The first two possibilities are also
> pretty bad ideas near Antora.
> >
> > Do you have a link on the editing capabilities?
>
> As far as I know no one has ever done this, and as I said I think it’s a
> really bad idea.  However, Antora is flexible enough so this is possible.
>
> IMO magic is really bad news in something like a website that no one is
> really interested in dedicating themselves to.  Any time you have something
> happening that is the least bit non-standard and non-obvious you
> dramatically increase the barriers to contribution and maintenance.  Maven
> is sort of awful, but it’s fairly consistent, and it pretty much brought
> about a revolution in build systems by a great deal of transparency and
> consistency.  I’m going to argue really strongly against any solution that
> isn’t entirely visible from the source.  The two solutions I know of are
> two copies of the docs, with the EE prefix hardcoded, and one copy with the
> prefix as an attribute, i.e. asciidoctor “variable”.
>
> Lets look for a solution that is completely visible in the adoc source.  I
> think an ee prefix attribute will do that, lets try it.
>
> >
> > Recommended or not, is it possible to do either of the last two and what
> would that look like?
>
> It would look like incomprehensible magic, and no one would be able to
> figure out how the result was obtained.  At least I wouldn’t be able to if
> I stepped away for a week.
>
> >
> >> I think we should take a look at the attribute idea in action before
> ruling it out.  For one thing, it might be possible to check for non-use of
> the attribute by grepping for javax or jakarta, maybe in a pre-commit hook.
> >
> > We can certainly take a look.  Even if the feature doesn't get used for
> this problem doesn't mean learning about it is bad -- we may see another
> valuable way to use it.
> >
> > In terms of commit hooks, if I had to chose between writing tool/script
> to force a developer to do something or writing a tool/script to do it for
> them, I'll always favor the latter if that's possible.
>
> Well, the commit hook might replace either of ‘javax’ or ‘jakarta’ with
> {ee-prefix}.  I imagine there would need to be a way to use the other
> prefix in a particular document.  That could be another 2 attributes.
>
> David Jencks
>
> >
> >
> > -David
> >
>
>

Re: [Website-Antora] New preview

[David Jencks]

> On Aug 7, 2020, at 6:16 PM, David Blevins  wrote:
> 
>> On Aug 7, 2020, at 5:02 PM, David Jencks  wrote:
>> 
>> It’s possible to customize antora to do some sorts of editing on the fly, 
>> but I really don’t recommend it.  The first two possibilities are also 
>> pretty bad ideas near Antora.
> 
> Do you have a link on the editing capabilities?

As far as I know no one has ever done this, and as I said I think it’s a really 
bad idea.  However, Antora is flexible enough so this is possible.

IMO magic is really bad news in something like a website that no one is really 
interested in dedicating themselves to.  Any time you have something happening 
that is the least bit non-standard and non-obvious you dramatically increase 
the barriers to contribution and maintenance.  Maven is sort of awful, but it’s 
fairly consistent, and it pretty much brought about a revolution in build 
systems by a great deal of transparency and consistency.  I’m going to argue 
really strongly against any solution that isn’t entirely visible from the 
source.  The two solutions I know of are two copies of the docs, with the EE 
prefix hardcoded, and one copy with the prefix as an attribute, i.e. 
asciidoctor “variable”.

Lets look for a solution that is completely visible in the adoc source.  I 
think an ee prefix attribute will do that, lets try it.

> 
> Recommended or not, is it possible to do either of the last two and what 
> would that look like?

It would look like incomprehensible magic, and no one would be able to figure 
out how the result was obtained.  At least I wouldn’t be able to if I stepped 
away for a week.

> 
>> I think we should take a look at the attribute idea in action before ruling 
>> it out.  For one thing, it might be possible to check for non-use of the 
>> attribute by grepping for javax or jakarta, maybe in a pre-commit hook.
> 
> We can certainly take a look.  Even if the feature doesn't get used for this 
> problem doesn't mean learning about it is bad -- we may see another valuable 
> way to use it.
> 
> In terms of commit hooks, if I had to chose between writing tool/script to 
> force a developer to do something or writing a tool/script to do it for them, 
> I'll always favor the latter if that's possible.

Well, the commit hook might replace either of ‘javax’ or ‘jakarta’ with 
{ee-prefix}.  I imagine there would need to be a way to use the other prefix in 
a particular document.  That could be another 2 attributes.

David Jencks

> 
> 
> -David
> 

Re: [Website-Antora] New preview

[David Blevins]

> On Aug 7, 2020, at 5:02 PM, David Jencks  wrote:
> 
> It’s possible to customize antora to do some sorts of editing on the fly, but 
> I really don’t recommend it.  The first two possibilities are also pretty bad 
> ideas near Antora.

Do you have a link on the editing capabilities?

Recommended or not, is it possible to do either of the last two and what would 
that look like?

> I think we should take a look at the attribute idea in action before ruling 
> it out.  For one thing, it might be possible to check for non-use of the 
> attribute by grepping for javax or jakarta, maybe in a pre-commit hook.

We can certainly take a look.  Even if the feature doesn't get used for this 
problem doesn't mean learning about it is bad -- we may see another valuable 
way to use it.

In terms of commit hooks, if I had to chose between writing tool/script to 
force a developer to do something or writing a tool/script to do it for them, 
I'll always favor the latter if that's possible.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: [Website-Antora] New preview

[David Jencks]

> On Aug 7, 2020, at 4:25 PM, David Blevins  wrote:
> 
>> On Aug 7, 2020, at 3:49 PM, David Jencks  wrote:
>> 
>>> On Aug 7, 2020, at 1:47 PM, David Blevins  wrote:
>>> 
>>>> On Aug 4, 2020, at 11:55 PM, David Jencks  wrote:
>>>> 
>>>> I updated the navigation in the preview to include all the common pages 
>>>> (most of which are from apache CMS and previously hard to find) and the 
>>>> doc pages to more closely match the existing sections.
>>>> 
>>>> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html
>>>> 
>>>> There are some pages I used to help generate the navigation that will be 
>>>> useful until things stabilize a bit more.
>>>> 
>>>> This isn’t perfect but I think it’s in a state where it could replace the 
>>>> current site, with the exception of examples and javadoc.
>>> 
>>> It's definitely a large step forward.  I think there needs to be some TomEE 
>>> 9 presence even if the docs are a 100% copy of 8 -- i.e. you point Antora 
>>> at the same place as where 8 docs are getting pulled, but publish it as 9.
>>> 
>>> Ultimately I just did a very surgical javax-to-jakarta rename on the 8 docs 
>>> to turn them into 9.
>>> 
>>> Would any of these be an option we could employ?
>>> 
>>> - post-processing: perform some final edits to the Antora-generated html 
>>> pages before they are committed to git
>>> - pre-processing: supply a non-git source for TomEE 9 asciidoc files 
>>> (perhaps a zip) so we ourselves can clone/edit them and hand them to Antora
>>> - hooks: does Antora have any way to allow us to hook in so we can do our 
>>> own prep before the generation happens?
>> 
>> I haven’t looked into incorporating any of the doc changes since March, 
>> including the new TomEE 9.
>> If the desired changes are that all uses of `javax`  are replaced with 
>> `jakarta` the simplest way to do it is probably to use an attribute and 
>> define it as `javax` for versions < 9 and `jakarta` for versions >= 9.
> 
> Not a complete set of concerns, but anytime someone has to remember do 
> something different or special to write a doc my observation is it ages very 
> poorly.  Someone writes a script and runs it once, then it shifts to a human 
> task and starts to degrade.  If possible, leaving it a script task run 
> automatically is best.
> 
> Do you know if any of the options I mention are possible?

It’s possible to customize antora to do some sorts of editing on the fly, but I 
really don’t recommend it.  The first two possibilities are also pretty bad 
ideas near Antora.

I think we should take a look at the attribute idea in action before ruling it 
out.  For one thing, it might be possible to check for non-use of the attribute 
by grepping for javax or jakarta, maybe in a pre-commit hook.  For another, I’d 
guess new documentation is likely to apply only to jakarta, and if someone 
hardcodes jakarta there it won’t be a problem.

I’m sure we can find a good solution here.

> 
> 
>>>> I think that the apache git website deploy system allows a preview site, 
>>>> so i may investigate and see if I can get that set up.
>>> 
>>> The Apache CMS has staging built into it (it's not great for a site of our 
>>> size).  I asked about similar capabilities in the git-based publishing that 
>>> is there now and I swear there was something that allowed you to create 
>>> branches, but I have to go back and read those emails.
>> 
>> There’s something about that in the asf.yml documentation here: 
>> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features 
>> <https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features> 
>> but I haven’t tried anything related to that yet.
> 
> That's the one.  Here was the most encouraging section:
> 
>Staging a web site preview domain
> 
>To enable staging (live preview) of your project's web site, add a
>staging entry to the site repository's .asf.yaml file.  As an
>example, take the imaginary yourproject-website.git with an
>.asf.yaml file containing the following entry:
> 
>staging:
>  profile: beta
> 
>This would stage the current branch at
>https://yourproject-beta.staged.apache.org/ 
> <https://yourproject-beta.staged.apache.org/> . You can add multiple
>staging profiles and thus multiple branches staged for
>preview. This can be helpful when doing A/B evaluations of website
>contents and features.
> 
> The ability to have many different preview sites would be an awesome enabler 
> of change.

yes :-)

David Jencks
> 
> 
> -David

Re: [Website-Antora] New preview

[David Blevins]

> On Aug 7, 2020, at 3:49 PM, David Jencks  wrote:
> 
>> On Aug 7, 2020, at 1:47 PM, David Blevins  wrote:
>> 
>>> On Aug 4, 2020, at 11:55 PM, David Jencks  wrote:
>>> 
>>> I updated the navigation in the preview to include all the common pages 
>>> (most of which are from apache CMS and previously hard to find) and the doc 
>>> pages to more closely match the existing sections.
>>> 
>>> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html
>>> 
>>> There are some pages I used to help generate the navigation that will be 
>>> useful until things stabilize a bit more.
>>> 
>>> This isn’t perfect but I think it’s in a state where it could replace the 
>>> current site, with the exception of examples and javadoc.
>> 
>> It's definitely a large step forward.  I think there needs to be some TomEE 
>> 9 presence even if the docs are a 100% copy of 8 -- i.e. you point Antora at 
>> the same place as where 8 docs are getting pulled, but publish it as 9.
>> 
>> Ultimately I just did a very surgical javax-to-jakarta rename on the 8 docs 
>> to turn them into 9.
>> 
>> Would any of these be an option we could employ?
>> 
>> - post-processing: perform some final edits to the Antora-generated html 
>> pages before they are committed to git
>> - pre-processing: supply a non-git source for TomEE 9 asciidoc files 
>> (perhaps a zip) so we ourselves can clone/edit them and hand them to Antora
>> - hooks: does Antora have any way to allow us to hook in so we can do our 
>> own prep before the generation happens?
> 
> I haven’t looked into incorporating any of the doc changes since March, 
> including the new TomEE 9.
> If the desired changes are that all uses of `javax`   are replaced with 
> `jakarta` the simplest way to do it is probably to use an attribute and 
> define it as `javax` for versions < 9 and `jakarta` for versions >= 9.

Not a complete set of concerns, but anytime someone has to remember do 
something different or special to write a doc my observation is it ages very 
poorly.  Someone writes a script and runs it once, then it shifts to a human 
task and starts to degrade.  If possible, leaving it a script task run 
automatically is best.

Do you know if any of the options I mention are possible?


>>> I think that the apache git website deploy system allows a preview site, so 
>>> i may investigate and see if I can get that set up.
>> 
>> The Apache CMS has staging built into it (it's not great for a site of our 
>> size).  I asked about similar capabilities in the git-based publishing that 
>> is there now and I swear there was something that allowed you to create 
>> branches, but I have to go back and read those emails.
> 
> There’s something about that in the asf.yml documentation here: 
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features 
> but I haven’t tried anything related to that yet.

That's the one.  Here was the most encouraging section:

Staging a web site preview domain

To enable staging (live preview) of your project's web site, add a
staging entry to the site repository's .asf.yaml file.  As an
example, take the imaginary yourproject-website.git with an
.asf.yaml file containing the following entry:

staging:
  profile: beta
  
This would stage the current branch at
https://yourproject-beta.staged.apache.org/ . You can add multiple
staging profiles and thus multiple branches staged for
preview. This can be helpful when doing A/B evaluations of website
contents and features.

The ability to have many different preview sites would be an awesome enabler of 
change.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: [Website-Antora] New preview

[David Jencks]

> On Aug 7, 2020, at 1:47 PM, David Blevins  wrote:
> 
>> On Aug 4, 2020, at 11:55 PM, David Jencks  wrote:
>> 
>> I updated the navigation in the preview to include all the common pages 
>> (most of which are from apache CMS and previously hard to find) and the doc 
>> pages to more closely match the existing sections.
>> 
>> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html
>> 
>> There are some pages I used to help generate the navigation that will be 
>> useful until things stabilize a bit more.
>> 
>> This isn’t perfect but I think it’s in a state where it could replace the 
>> current site, with the exception of examples and javadoc.
> 
> It's definitely a large step forward.  I think there needs to be some TomEE 9 
> presence even if the docs are a 100% copy of 8 -- i.e. you point Antora at 
> the same place as where 8 docs are getting pulled, but publish it as 9.
> 
> Ultimately I just did a very surgical javax-to-jakarta rename on the 8 docs 
> to turn them into 9.
> 
> Would any of these be an option we could employ?
> 
> - post-processing: perform some final edits to the Antora-generated html 
> pages before they are committed to git
> - pre-processing: supply a non-git source for TomEE 9 asciidoc files (perhaps 
> a zip) so we ourselves can clone/edit them and hand them to Antora
> - hooks: does Antora have any way to allow us to hook in so we can do our own 
> prep before the generation happens?

I haven’t looked into incorporating any of the doc changes since March, 
including the new TomEE 9.
If the desired changes are that all uses of `javax` are replaced with 
`jakarta` the simplest way to do it is probably to use an attribute and define 
it as `javax` for versions < 9 and `jakarta` for versions >= 9.  The three 
existing doc versions are all the same except for a couple pages that appear or 
disappear in different versions.

> 
>> I think that the apache git website deploy system allows a preview site, so 
>> i may investigate and see if I can get that set up.
> 
> The Apache CMS has staging built into it (it's not great for a site of our 
> size).  I asked about similar capabilities in the git-based publishing that 
> is there now and I swear there was something that allowed you to create 
> branches, but I have to go back and read those emails.

There’s something about that in the asf.yml documentation here: 
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features but 
I haven’t tried anything related to that yet.

David Jencks
> 
> 
> -David
> 

Re: [Website-Antora] New preview

[David Blevins]

> On Aug 4, 2020, at 11:55 PM, David Jencks  wrote:
> 
> I updated the navigation in the preview to include all the common pages (most 
> of which are from apache CMS and previously hard to find) and the doc pages 
> to more closely match the existing sections.
> 
> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html
> 
> There are some pages I used to help generate the navigation that will be 
> useful until things stabilize a bit more.
> 
> This isn’t perfect but I think it’s in a state where it could replace the 
> current site, with the exception of examples and javadoc.

It's definitely a large step forward.  I think there needs to be some TomEE 9 
presence even if the docs are a 100% copy of 8 -- i.e. you point Antora at the 
same place as where 8 docs are getting pulled, but publish it as 9.

Ultimately I just did a very surgical javax-to-jakarta rename on the 8 docs to 
turn them into 9.

Would any of these be an option we could employ?

 - post-processing: perform some final edits to the Antora-generated html pages 
before they are committed to git
 - pre-processing: supply a non-git source for TomEE 9 asciidoc files (perhaps 
a zip) so we ourselves can clone/edit them and hand them to Antora
 - hooks: does Antora have any way to allow us to hook in so we can do our own 
prep before the generation happens?

> I think that the apache git website deploy system allows a preview site, so i 
> may investigate and see if I can get that set up.

The Apache CMS has staging built into it (it's not great for a site of our 
size).  I asked about similar capabilities in the git-based publishing that is 
there now and I swear there was something that allowed you to create branches, 
but I have to go back and read those emails.


-David



smime.p7s
Description: S/MIME cryptographic signature

Re: [Website-Antora] New preview

[Daniel Dias Dos Santos]

Hello David,

fantastic site, very good. :)

--

*Daniel Dias dos Santos*
Java Developer
SouJava & JCP Member
GitHub: https://github.com/Daniel-Dos
Linkedin: www.linkedin.com/in/danieldiasjava
Twitter: http://twitter.com/danieldiasjava


Em sex., 7 de ago. de 2020 às 15:46, Jonathan Gallimore <
jonathan.gallim...@gmail.com> escreveu:

> Hi David
>
> I think this looks fantastic - thank you for the update. I replied on the
> CMS retirement thread, but I'd be in favour of moving this forward.
>
> Jon
>
> On Wed, Aug 5, 2020 at 7:56 AM David Jencks 
> wrote:
>
> > I updated the navigation in the preview to include all the common pages
> > (most of which are from apache CMS and previously hard to find) and the
> doc
> > pages to more closely match the existing sections.
> >
> > https://tomee-preview.s3-us-west-2.amazonaws.com/index.html
> >
> > There are some pages I used to help generate the navigation that will be
> > useful until things stabilize a bit more.
> >
> > This isn’t perfect but I think it’s in a state where it could replace the
> > current site, with the exception of examples and javadoc.
> >
> > I think that the apache git website deploy system allows a preview site,
> > so i may investigate and see if I can get that set up.
> >
> > David Jencks
>

Re: [Website-Antora] New preview

[Jonathan Gallimore]

Hi David

I think this looks fantastic - thank you for the update. I replied on the
CMS retirement thread, but I'd be in favour of moving this forward.

Jon

On Wed, Aug 5, 2020 at 7:56 AM David Jencks 
wrote:

> I updated the navigation in the preview to include all the common pages
> (most of which are from apache CMS and previously hard to find) and the doc
> pages to more closely match the existing sections.
>
> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html
>
> There are some pages I used to help generate the navigation that will be
> useful until things stabilize a bit more.
>
> This isn’t perfect but I think it’s in a state where it could replace the
> current site, with the exception of examples and javadoc.
>
> I think that the apache git website deploy system allows a preview site,
> so i may investigate and see if I can get that set up.
>
> David Jencks

Re: Your project's website

[Jonathan Gallimore]

If you're willing to do that, that's fantastic - thank you. I think the
retirement of the CMS gives us a good opportunity to move this forward.

Thanks David.

Jon

On Fri, Aug 7, 2020 at 7:38 PM David Jencks 
wrote:

> At this point I’m willing to do the following with the Antora site effort:
>
> - put the examples back into the Antora site
> - find some way of including or referencing javadoc.
> - figuring out how to relate to the  pypubsub system so the site is
> published through git.
> - be the point of contact with infra.
>
> What I’m not willing to do is try to have a two-builder site when AFAICT
> one part is distinctly inferior and less capable and no one will tell me
> anything about why it’s better or required or nice or 
> I’m also not willing to wait indefinitely for feedback.  If I proceed with
> this it will have to be commit-then-review, as my previous requests for
> review have generally been met with silence.
>
> David Jencks
>
> > On Aug 7, 2020, at 6:16 AM, Andrew Wetmore  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
> >
> > [2]
> >
> 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
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > Virus-free.
> > www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>

Re: Your project's website

[David Jencks]

At this point I’m willing to do the following with the Antora site effort:

- put the examples back into the Antora site
- find some way of including or referencing javadoc.
- figuring out how to relate to the  pypubsub system so the site is published 
through git.
- be the point of contact with infra.

What I’m not willing to do is try to have a two-builder site when AFAICT one 
part is distinctly inferior and less capable and no one will tell me anything 
about why it’s better or required or nice or 
I’m also not willing to wait indefinitely for feedback.  If I proceed with this 
it will have to be commit-then-review, as my previous requests for review have 
generally been met with silence.

David Jencks

> On Aug 7, 2020, at 6:16 AM, Andrew Wetmore  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
> 
> [2]
> 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
> 
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Your project's website

[Andrew Wetmore]

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

[2]
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

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

[Website-Antora] New preview

[David Jencks]

I updated the navigation in the preview to include all the common pages (most 
of which are from apache CMS and previously hard to find) and the doc pages to 
more closely match the existing sections.

https://tomee-preview.s3-us-west-2.amazonaws.com/index.html

There are some pages I used to help generate the navigation that will be useful 
until things stabilize a bit more.

This isn’t perfect but I think it’s in a state where it could replace the 
current site, with the exception of examples and javadoc.

I think that the apache git website deploy system allows a preview site, so i 
may investigate and see if I can get that set up.

David Jencks

Re: [Antora Website] home page experiment

[David Jencks]

I’ve updated this with Willes’ header PR which I think looks really nice.

David Jencks

> On Jul 23, 2020, at 11:34 AM, David Jencks  wrote:
> 
> At least two people (David Blevins and Cesar Hernandez) have expressed the 
> idea that the “static site” should not be generated by Antora.  I’ve been 
> wondering why, and what the “static site” might be.  The home page of the 
> current site seems like the most obvious candidate, so I decided to learn a 
> little bit of css…
> 
> Investigating the source of the current home page, it appears to be a 
> hodgepodge of outdated table layout and scripts and css whose origin is not 
> clear to me.  Understanding what it does I found rather difficult.
> 
> I’ve replicated most of the features of the current home page in an .adoc 
> page rendered by Antora.  I learned enough css for now, so I didn’t pursue an 
> exact replica.  I imagine that for someone who knows a reasonable amount of 
> css finishing the synchronization would be easy.
> 
> Present:
> 
> - Layout and images
> - general behavior of hover animation
> 
> Missing:
> 
> - clipping on background image
> - “typewriter” effect on subtitle (personally this reminds me of a “blink” 
> tag….)
> - specific details of hover animation
> 
> I find the .adoc source very clear about the structure of the resulting page, 
> and the css is really quite short and to the point.  I can easily understand 
> and work with both.
> 
> What is better about the current situation?
> 
> ——
> 
> Preview:  https://tomee-preview.s3-us-west-2.amazonaws.com/ 
> 
> 
> branches “home-page” at 
> 
> - tomee-antora  (playbook)
> 
> - tomee-antora-ui 
> 
> — css: src/css/home-doc.css, src/css/home.css 
> (https://raw.githubusercontent.com/djencks/tomee-antora-ui/home-page/src/css/home-doc.css
>  
> )
> — layout: src/layouts/home-page.hbs, src/partials/home-body.hbs
> 
> - tomee-site-generator 
> 
> — tomee/modules/ROOT/pages/home-page.adoc  
> (https://raw.githubusercontent.com/djencks/tomee-site-generator/home-page/tomee/modules/ROOT/pages/home-page.adoc
>  
> )
> 
> David Jencks
> 
> 

[Antora Website] home page experiment

[David Jencks]

At least two people (David Blevins and Cesar Hernandez) have expressed the idea 
that the “static site” should not be generated by Antora.  I’ve been wondering 
why, and what the “static site” might be.  The home page of the current site 
seems like the most obvious candidate, so I decided to learn a little bit of 
css…

Investigating the source of the current home page, it appears to be a 
hodgepodge of outdated table layout and scripts and css whose origin is not 
clear to me.  Understanding what it does I found rather difficult.

I’ve replicated most of the features of the current home page in an .adoc page 
rendered by Antora.  I learned enough css for now, so I didn’t pursue an exact 
replica.  I imagine that for someone who knows a reasonable amount of css 
finishing the synchronization would be easy.

Present:

- Layout and images
- general behavior of hover animation

Missing:

- clipping on background image
- “typewriter” effect on subtitle (personally this reminds me of a “blink” 
tag….)
- specific details of hover animation

I find the .adoc source very clear about the structure of the resulting page, 
and the css is really quite short and to the point.  I can easily understand 
and work with both.

What is better about the current situation?

——

Preview:  https://tomee-preview.s3-us-west-2.amazonaws.com/

branches “home-page” at 

- tomee-antora  (playbook)

- tomee-antora-ui 

— css: src/css/home-doc.css, src/css/home.css 
(https://raw.githubusercontent.com/djencks/tomee-antora-ui/home-page/src/css/home-doc.css)
— layout: src/layouts/home-page.hbs, src/partials/home-body.hbs

- tomee-site-generator 

— tomee/modules/ROOT/pages/home-page.adoc  
(https://raw.githubusercontent.com/djencks/tomee-site-generator/home-page/tomee/modules/ROOT/pages/home-page.adoc)

David Jencks

Re: TOMEE-2837 - adjust the site documentation link in WebSite

[Daniel Dias Dos Santos]

merged.
--

*Daniel Dias dos Santos*
Java Developer
SouJava & JCP Member
GitHub: https://github.com/Daniel-Dos
Linkedin: www.linkedin.com/in/danieldiasjava
Twitter: http://twitter.com/danieldiasjava


Em ter., 2 de jun. de 2020 às 20:39, Daniel Dias Dos Santos <
daniel.dias.analist...@gmail.com> escreveu:

> Hi,
>
> I created a PR [1] .
>
> Can someone do a review?
>
> [1] https://github.com/apache/tomee-site-generator/pull/20
>
> thanks
>
> --
>
> *Daniel Dias dos Santos*
> Java Developer
> SouJava & JCP Member
> GitHub: https://github.com/Daniel-Dos
> Linkedin: www.linkedin.com/in/danieldiasjava
> Twitter: http://twitter.com/danieldiasjava
>
>
> Em ter., 2 de jun. de 2020 às 20:34, Daniel Dias Dos Santos <
> daniel.dias.analist...@gmail.com> escreveu:
>
>> Hi Jira Admins,
>>
>> Please, could some Jira Admin assign this ticket[1] to username
>> *danieldiasjava*
>>
>> [1] https://issues.apache.org/jira/browse/TOMEE-2837
>> thanks.
>> --
>>
>> *Daniel Dias dos Santos*
>> Java Developer
>> SouJava & JCP Member
>> GitHub: https://github.com/Daniel-Dos
>> Linkedin: www.linkedin.com/in/danieldiasjava
>> Twitter: http://twitter.com/danieldiasjava
>>
>

[GitHub] [tomee-site-generator] Daniel-Dos merged pull request #20: TOMEE-2837: adjust the site documentation link in WebSite

[GitBox]

Daniel-Dos merged pull request #20:
URL: https://github.com/apache/tomee-site-generator/pull/20


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: TOMEE-2837 - adjust the site documentation link in WebSite

[Daniel Dias Dos Santos]

Hi,

I created a PR [1] .

Can someone do a review?

[1] https://github.com/apache/tomee-site-generator/pull/20

thanks

--

*Daniel Dias dos Santos*
Java Developer
SouJava & JCP Member
GitHub: https://github.com/Daniel-Dos
Linkedin: www.linkedin.com/in/danieldiasjava
Twitter: http://twitter.com/danieldiasjava


Em ter., 2 de jun. de 2020 às 20:34, Daniel Dias Dos Santos <
daniel.dias.analist...@gmail.com> escreveu:

> Hi Jira Admins,
>
> Please, could some Jira Admin assign this ticket[1] to username
> *danieldiasjava*
>
> [1] https://issues.apache.org/jira/browse/TOMEE-2837
> thanks.
> --
>
> *Daniel Dias dos Santos*
> Java Developer
> SouJava & JCP Member
> GitHub: https://github.com/Daniel-Dos
> Linkedin: www.linkedin.com/in/danieldiasjava
> Twitter: http://twitter.com/danieldiasjava
>

[GitHub] [tomee-site-generator] Daniel-Dos opened a new pull request #20: TOMEE-2837: adjust the site documentation link in WebSite

[GitBox]

Daniel-Dos opened a new pull request #20:
URL: https://github.com/apache/tomee-site-generator/pull/20


   link to jira: https://issues.apache.org/jira/browse/TOMEE-2837



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

TOMEE-2837 - adjust the site documentation link in WebSite

[Daniel Dias Dos Santos]

Hi Jira Admins,

Please, could some Jira Admin assign this ticket[1] to username
*danieldiasjava*

[1] https://issues.apache.org/jira/browse/TOMEE-2837
thanks.
--

*Daniel Dias dos Santos*
Java Developer
SouJava & JCP Member
GitHub: https://github.com/Daniel-Dos
Linkedin: www.linkedin.com/in/danieldiasjava
Twitter: http://twitter.com/danieldiasjava

Re: Antora-based website progress

[Cesar Hernandez]

Hi David,

The deployed preview looks pretty good. Thanks for the effort so far
executed!

>>>3. There are a lot of pages that are basically empty.  Maybe someone had
an idea that documenting something would be a good idea and added an empty
page for it.  Since these have been around for many years with no change, I
think it’s time to remove these.
If they are empty, I don't see a reason to keep them.

>>>4. There are a lot of pages explaining svn, tomcat <= 6, OpenEJB 1 and
3, etc. Is there any reason to keep these?
I would suggest creating an Archive category.

>>>5. There are several pages with helpful links to people's
people.apache.org accounts.  This is surely not appropriate, and I think
all of these are seriously out of date.  Is there any reason to keep these?
I think we can update those links to redirect readers to dev and/or the
user's mailing list.

There are many threads related to the website update so I'll try t
summarize my vision on this latest website update effort:

1) Keep current tomee-site generator as the main content and website layout
2) Once set up as a production-ready instance, keep the Antora setup for
the project documentation. This means that the current website link:
https://tomee.apache.org/docs.html will be redirected to the Antora
awesomeness UI.

In short, keep Antora usage for what it was made for, documentation. Keep
JBake for the static website layout and content.

[1] "Antora The multi-repository documentation site generator for tech
writers who  writing in AsciiDoc."https://antora.org/
[2] "Jbake Static site/blog generator for developers & designers"
https://jbake.org/


El vie., 13 mar. 2020 a las 14:43, Me via Boomerang ()
escribió:

> Message moved to top of Inbox by Boomerang (view this conversation
> <https://mail.google.com/mail/u/cesargu...@gmail.com/#search/rfc822msgid:%3CCAPkio3F8EAaT_y_rd1wokcO5QAbXNfvygqbP6qbVrVG8%3DdC5oA%40mail.gmail.com%3E>
> ).
>
> Don't want this notification email in the future? Go to
> https://b4g.baydin.com/settings and uncheck the 'At the top of your
> Inbox' option under Settings. Please note that your Boomeranged messages
> would no longer return to the top of your Inbox.
>
> Like Boomerang? Tell a friend! Click here
> <https://mail.google.com/mail/?view=cm=2=0=1=Have%20you%20tried%20Boomerang%20for%20Gmail%3F=I%20am%20using%20Boomerang%20for%20Gmail%20to%20schedule%20outgoing%20emails%2C%20remind%20myself%20about%20important%20messages%2C%20and%20track%20if%20I%20am%20getting%20responses.%20I%20really%20like%20it%2C%20and%20I%20think%20you%20might%20like%20it%20too.%20It%20is%20free%20to%20try%2C%20so%20check%20it%20out%20at%20http%3A//www.boomeranggmail.com.>
> .
>


-- 
Atentamente:
César Hernández.

Re: Antora-based website progress

[Jean-Louis Monteiro]

Wow, that's awesome.
Antora is made for this kind of thing and I believe you did a great job in
trying it out.

The result is very good and you have done a great job, not only trying, but
getting something done.
Thanks for the huge contribution.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Sat, Mar 7, 2020 at 9:06 PM Jonathan S. Fisher 
wrote:

> This is incredible, and beautiful! Thank you for putting in the work to
> make this happen!
>
> On Fri, Mar 6, 2020 at 9:06 PM David Jencks 
> wrote:
>
> > Preview at https://tomee-preview.s3-us-west-2.amazonaws.com/index.html <
> > https://tomee-preview.s3-us-west-2.amazonaws.com/index.html>
> >
> > Current state:
> >
> > - all content from old source locations on the site (AFAICT, I’ve stopped
> > looking). This includes all the .md and .mdtext from tomee-site.
> > - no asciidoc syntax errors
> > - no internal broken links
> > - (easy) content deduplication
> >
> > There are still some content fixes left to do such as swizzle
> > elimination.  I don’t think these are currently any worse on the preview
> > than on the live site.
> >
> > I think the main remaining questions about the website organization
> relate
> > to duplicate and useless or obsolete content.  To me, history makes clear
> > that maintaining the website is difficult for the community and generally
> > neglected.  I think the highest priority should be making it smaller and
> > better organized so there’s less to maintain and when someone has an
> > interest in working on it it’s not an insuperable task to figure out how.
> >
> > The current preview organization has:
> >
> > - content from tomee-site-generator and tomee-site under “common”;
> there’s
> > only one version
> > - content from tomee branches under “tomee” with three versions.  Almost
> > all of this content also appears in “common”; see (1)
> > - content from the tomee master examples under “examples”, with 3
> language
> > versions.
> > - the beginnings of embedded JavaDoc, see
> >
> https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/tomee/index.html
> > <
> >
> https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/tomee/index.html
> > >
> >
> > I think the largest remaining questions about the website organization
> > relate to duplicate and useless or obsolete content.  To me, history
> makes
> > clear that maintaining the website is difficult for the community and
> > generally neglected.  I think the highest priority should be making it
> > smaller and better organized so there’s less to maintain and when someone
> > has an interest in working on it it’s not an insuperable task to figure
> out
> > how.
> >
> > 1. Previously, except for perhaps a couple of pages, the 8.0, 7.1, and
> 7.0
> > doc branches were identical except for different asciidoc syntax errors.
> > Now that I’ve brought in the previous .mdtext content from tomee-site git
> > repo and fixed the syntax errors, there are 4 identical copies.  I’ve
> made
> > this obvious by eliminating the full text of all but one and using
> > include:: directives in the other 3.  I think much of this content is
> > somewhere between outdated and wrong, so having 4 identical copies seems
> > like a less than ideal situation.  I think it’s extremely unlikely any of
> > this content is going to change, although some might be removed.  I’d
> > suggest keeping only the copy in “common” and leaving the versioned
> > branches for release-specific content, with a pointer to the common docs.
> >
> > 2. I haven’t examined the situation in detail, but I think that the
> > examples are pretty much the same for 7, 7.1, and 8.  I don’t think old
> > examples will ever change, but new ones added.  Therefore I suggest
> having
> > only one “examples” component with each example saying “since version
> xxx”.
> >
> > 3. There are a lot of pages that are basically empty.  Maybe someone had
> > an idea that documenting something would be a good idea and added an
> empty
> > page for it.  Since these have been around for many years with no
> change, I
> > think it’s time to remove these.
> >
> > 4. There are a lot of pages explaining svn, tomcat <= 6, OpenEJB 1 and 3,
> > etc. Is there any reason to keep these?
> >
> > 5. There are several pages with helpful links to peoples
> people.apache.org
> > accounts.  This is surely not appropriate, and I think all of these are
> > seriously out of date.  Is there any reason to keep these?
> >
> >

Re: Antora-based website progress

[Jonathan S. Fisher]

This is incredible, and beautiful! Thank you for putting in the work to
make this happen!

On Fri, Mar 6, 2020 at 9:06 PM David Jencks 
wrote:

> Preview at https://tomee-preview.s3-us-west-2.amazonaws.com/index.html <
> https://tomee-preview.s3-us-west-2.amazonaws.com/index.html>
>
> Current state:
>
> - all content from old source locations on the site (AFAICT, I’ve stopped
> looking). This includes all the .md and .mdtext from tomee-site.
> - no asciidoc syntax errors
> - no internal broken links
> - (easy) content deduplication
>
> There are still some content fixes left to do such as swizzle
> elimination.  I don’t think these are currently any worse on the preview
> than on the live site.
>
> I think the main remaining questions about the website organization relate
> to duplicate and useless or obsolete content.  To me, history makes clear
> that maintaining the website is difficult for the community and generally
> neglected.  I think the highest priority should be making it smaller and
> better organized so there’s less to maintain and when someone has an
> interest in working on it it’s not an insuperable task to figure out how.
>
> The current preview organization has:
>
> - content from tomee-site-generator and tomee-site under “common”; there’s
> only one version
> - content from tomee branches under “tomee” with three versions.  Almost
> all of this content also appears in “common”; see (1)
> - content from the tomee master examples under “examples”, with 3 language
> versions.
> - the beginnings of embedded JavaDoc, see
> https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/tomee/index.html
> <
> https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/tomee/index.html
> >
>
> I think the largest remaining questions about the website organization
> relate to duplicate and useless or obsolete content.  To me, history makes
> clear that maintaining the website is difficult for the community and
> generally neglected.  I think the highest priority should be making it
> smaller and better organized so there’s less to maintain and when someone
> has an interest in working on it it’s not an insuperable task to figure out
> how.
>
> 1. Previously, except for perhaps a couple of pages, the 8.0, 7.1, and 7.0
> doc branches were identical except for different asciidoc syntax errors.
> Now that I’ve brought in the previous .mdtext content from tomee-site git
> repo and fixed the syntax errors, there are 4 identical copies.  I’ve made
> this obvious by eliminating the full text of all but one and using
> include:: directives in the other 3.  I think much of this content is
> somewhere between outdated and wrong, so having 4 identical copies seems
> like a less than ideal situation.  I think it’s extremely unlikely any of
> this content is going to change, although some might be removed.  I’d
> suggest keeping only the copy in “common” and leaving the versioned
> branches for release-specific content, with a pointer to the common docs.
>
> 2. I haven’t examined the situation in detail, but I think that the
> examples are pretty much the same for 7, 7.1, and 8.  I don’t think old
> examples will ever change, but new ones added.  Therefore I suggest having
> only one “examples” component with each example saying “since version xxx”.
>
> 3. There are a lot of pages that are basically empty.  Maybe someone had
> an idea that documenting something would be a good idea and added an empty
> page for it.  Since these have been around for many years with no change, I
> think it’s time to remove these.
>
> 4. There are a lot of pages explaining svn, tomcat <= 6, OpenEJB 1 and 3,
> etc. Is there any reason to keep these?
>
> 5. There are several pages with helpful links to peoples people.apache.org
> accounts.  This is surely not appropriate, and I think all of these are
> seriously out of date.  Is there any reason to keep these?
>
>
> ———
>
> JavaDoc
>
> I’ve experimented with javadoc a bit.  In my tomee-site antora branch
> there’s a small example of using maven to build a java 11 style javadoc jar
> from a few bits of stuff pulled into the jbake-built javadoc. This makes
> more sense to me than running the javadoc tool every time you want to
> preview the website. I also have an experimental Antora plugin that adds
> the javadoc to the generated website.  There are several ways to do this,
> but I like the idea of having the javadoc content inside the Antora page
> layout: this is what the preview has.  I’m having trouble figuring out how
> to make the antora navigation and javadoc search work in this context.
> Also, javadoc jars now include some gpl2 licensed scripts, so I’m a bit
> unclear as to whether it’s even i

Antora-based website progress

[David Jencks]

Preview at https://tomee-preview.s3-us-west-2.amazonaws.com/index.html 
<https://tomee-preview.s3-us-west-2.amazonaws.com/index.html>

Current state:

- all content from old source locations on the site (AFAICT, I’ve stopped 
looking). This includes all the .md and .mdtext from tomee-site.
- no asciidoc syntax errors
- no internal broken links
- (easy) content deduplication

There are still some content fixes left to do such as swizzle elimination.  I 
don’t think these are currently any worse on the preview than on the live site.

I think the main remaining questions about the website organization relate to 
duplicate and useless or obsolete content.  To me, history makes clear that 
maintaining the website is difficult for the community and generally neglected. 
 I think the highest priority should be making it smaller and better organized 
so there’s less to maintain and when someone has an interest in working on it 
it’s not an insuperable task to figure out how.

The current preview organization has:

- content from tomee-site-generator and tomee-site under “common”; there’s only 
one version
- content from tomee branches under “tomee” with three versions.  Almost all of 
this content also appears in “common”; see (1)
- content from the tomee master examples under “examples”, with 3 language 
versions.
- the beginnings of embedded JavaDoc, see 
https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/tomee/index.html 
<https://tomee-preview.s3-us-west-2.amazonaws.com/tomee/8.0/tomee/index.html>

I think the largest remaining questions about the website organization relate 
to duplicate and useless or obsolete content.  To me, history makes clear that 
maintaining the website is difficult for the community and generally neglected. 
 I think the highest priority should be making it smaller and better organized 
so there’s less to maintain and when someone has an interest in working on it 
it’s not an insuperable task to figure out how.

1. Previously, except for perhaps a couple of pages, the 8.0, 7.1, and 7.0 doc 
branches were identical except for different asciidoc syntax errors.  Now that 
I’ve brought in the previous .mdtext content from tomee-site git repo and fixed 
the syntax errors, there are 4 identical copies.  I’ve made this obvious by 
eliminating the full text of all but one and using include:: directives in the 
other 3.  I think much of this content is somewhere between outdated and wrong, 
so having 4 identical copies seems like a less than ideal situation.  I think 
it’s extremely unlikely any of this content is going to change, although some 
might be removed.  I’d suggest keeping only the copy in “common” and leaving 
the versioned branches for release-specific content, with a pointer to the 
common docs.

2. I haven’t examined the situation in detail, but I think that the examples 
are pretty much the same for 7, 7.1, and 8.  I don’t think old examples will 
ever change, but new ones added.  Therefore I suggest having only one 
“examples” component with each example saying “since version xxx”.

3. There are a lot of pages that are basically empty.  Maybe someone had an 
idea that documenting something would be a good idea and added an empty page 
for it.  Since these have been around for many years with no change, I think 
it’s time to remove these.

4. There are a lot of pages explaining svn, tomcat <= 6, OpenEJB 1 and 3, etc. 
Is there any reason to keep these?

5. There are several pages with helpful links to peoples people.apache.org 
accounts.  This is surely not appropriate, and I think all of these are 
seriously out of date.  Is there any reason to keep these?


———

JavaDoc

I’ve experimented with javadoc a bit.  In my tomee-site antora branch there’s a 
small example of using maven to build a java 11 style javadoc jar from a few 
bits of stuff pulled into the jbake-built javadoc. This makes more sense to me 
than running the javadoc tool every time you want to preview the website. I 
also have an experimental Antora plugin that adds the javadoc to the generated 
website.  There are several ways to do this, but I like the idea of having the 
javadoc content inside the Antora page layout: this is what the preview has.  
I’m having trouble figuring out how to make the antora navigation and javadoc 
search work in this context.  Also, javadoc jars now include some gpl2 licensed 
scripts, so I’m a bit unclear as to whether it’s even in line with Apache 
policy to show generated javadoc on an apache site.  The gpl code doesn’t do 
much, so I think it’s plausible to replace it with MIT or apache licensed code.

I could use some help with:
- constructing a full javadoc jar with maven, having the same source contents 
as the jbake javadoc
- figuring out the css and script problems with the embedded javadoc.  This is 
implausible now, since I haven’t pushed the Antora UI project I’m using, but I 
hope to do this soon.  If anyone is interested in working on 

Re: Draft Proposal for overall website direction

[David Jencks]

Part of this discussion is about how to organize the website.

I was just pointed to this, which I think has a very nice description of 
different purposes for different documentation, no matter what technology is 
used for the site:

https://lisk.io/blog/announcement/lisk-documentation-migrated-asciidoc-and-antora

David Jencks

> 
>> On Feb 19, 2020, at 5:24 AM, gilbertoca  wrote:
>> 
>> David Blevins-2 wrote
>>> There's an entire facet of this discussion we probably should be talking
>>> about which is how to deal with our heaps of content in various states of
>>> health; how did it get unhealthy, how do we deal with it, how do we
>>> prevent it, how do we encourage more contribution to main docs.
>>> 
>>> I think any tool in the hands of someone willing to lead an effort to
>>> improve our main docs is a good tool.
>>> 
>>> -David
>> 
>> We could follow (again) apache friends and others [1] condensing all
>> relevant content in something like a User Guide or Reference Guide - that
>> would help the Maintenance and contribution. This organization can reduce
>> the tooling and it easy integrate(asciidoctor-maven-plugin?) in build
>> system[2].
>> 
>> [1]
>> https://netbeans.apache.org/kb/docs/java/index.html
>> https://ci.apache.org/projects/wicket/guide/8.x/single.html
>> https://beanvalidation.org/2.0/spec/
>> https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html
>> https://shiro.apache.org/reference.html
>> 
>> [2] https://asciidoctor.org/docs/asciidoctor-maven-plugin/
>> 
>> Regards,
>> 
>> Gilberto
>> 
>> 
>> 
>> --
>> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> 

Re: (new) website content sanity check :-)

[David Jencks]

I have a new idea for clarifying the website duplication.

Antora lets you include the same page in several components by using “include 
stubs”, i.e. a page that only has an include:: preprocessor directive, pointing 
to the single copy. (includes work in plain asciidoc, but there’s no practical 
way to refer to the originating page without Antora page coordinates).

Intellij tools such as IDEA and WebStorm have a nice diff fe total.ature and 
customizable live templates.  I made a live template to insert the include:: to 
the “actual copy” of the page.

My workflow is to compare a page in 8.0@tomee (i.e. my antora clone of master 
of the tomee git repo) with the same page in the tomes-site antora branch using 
WebStorm’s side-by-side diff.  I combine the asciidoc to get something that is 
more correct than either source, edit any other errors I see, put the corrected 
version in tomee-site, and replace the tomee master copy with an include stub.

One of the edits is including the jbake attributes from master.

This reduces the number of duplicates by one, and indicates:
- on master that the page is duplicated in common
- on tomee-site that the page is duplicated in master, and edited to look OK.

I now have only 2 errors in 8.0@tomee, 367 in common, and 386 total.

David Jencks

> On Feb 17, 2020, at 4:39 PM, David Jencks  wrote:
> 
> I pushed another preview update.  This has all the content I’ve found and 
> except for a few pages from svn that seem to originate as html and some pages 
> currently generated by the tomee-stie-generator  I believe it has all the 
> content that is supposed to be published.
> 
> There are about 450 errors noted by Antora building this.  These are asciidoc 
> syntax errors (mostly section level errors) and broken links.
> 
> AFAICT most of the content is duplicated in 4 places: what I’m calling 
> “common”, 8.0, 7.1, and 7.0.  Fixing only one copy would be considerably 
> quicker than comparing and fixing 4.
> 
> My extremely biased opinion is that the content is approximately as good 
> shape as the live site.  There is decidedly less organization and navigation. 
>  Some pages are worse, and some are better, but it’s all presented uniformly.
> 
> TomEE Documentation AWS 
> <https://tomee-preview.s3-us-west-2.amazonaws.com/index.html>
> 
> Thanks
> David Jencks
> 
>> On Feb 16, 2020, at 7:41 PM, David Jencks > <mailto:david.a.jen...@gmail.com>> wrote:
>> 
>> Thanks for the more info, and I have plenty to do so no hurry, if you do 
>> have some time some quick questions…
>> 
>> is https://svn.apache.org/repos/asf/tomee/site/trunk/content 
>> <https://svn.apache.org/repos/asf/tomee/site/trunk/content> the “same as” 
>> the website content, so modulo .md and mdtext > html conversion I can look 
>> at it and act like that’s the website to mimic? (also module files that have 
>> no source)
>> 
>> Is all the source from tomee-site, tomee-site-generator (including 
>> java-generated content), and tomee?  So anything not present in some format 
>> from one of these that’s in the above svn repo can be left out?
>> 
>> I’d think there must be some configuration for the Builder 
>> tomee-site-staging but I can’t find it.
>> 
>> IMO the site in any form is in such a mess that it’s hard to know where to 
>> work first.  There are tons of broken formatting, both in the existing site 
>> and the .adoc translations, and loads of broken links that have no plausible 
>> target.  For instance one of the pages you note  has 
>> 
>> \{include:OPENEJBx30:Singleton Beans}
>> 
>> I didn’t touch that one :-) It’s a bit confusing because there’s no 
>> OPENEJBx30 anywhere in sight, but I expect it’s supposed to refer to the 
>> same component/version.  When I get to it it will turn into a redirect.
>> 
>> I’m mostly concentrating on finding all the sources, getting them into some 
>> sort of semi-coherent structure, and fixing formatting and links that 
>> asciidoctor complains about.  I thought I was nearly done, but now there are 
>> a lot more files :-)
>> 
>> After the automatically recognized problems are fixed, examining the pages 
>> for other problems can start.
>> 
>> Thanks for the hints!
>> 
>> David Jencks
>> 
>> 
>> 
>>> On Feb 16, 2020, at 6:58 PM, David Blevins >> <mailto:david.blev...@gmail.com>> wrote:
>>> 
>>> Hi David,
>>> 
>>> Looks like you got there in the end.  I attempted to give a heads up on 
>>> that in my first email about the Apache CMS, but all this is complicated.  
>>> Read this then go back and read my first email on the "Documenta

Re: Draft Proposal for overall website direction

[David Jencks]

I was more or less assuming that before reorganizing the website content, 
organizing it was required.  Otherwise, you could just drop all current content 
and start over, which admittedly might be faster and more satisfactory.

The asciidoctor-maven-plugin is only usable if you want a site with only one 
version.  All of the sites you note below indeed only have one version.  
Although primitive, what David Blevins came up with in tomee-site-generator at 
least allows multiple versions.

For me, two hard requirements would be:
- generate the entire site in one action.  I think this is needed to track what 
is supposed to be there and avoid orphaned content like we have now.
- support multiple components and versions with easy navigation between them.  
At a minimum, I think there can be general version less information and version 
specific information.  Separating content into perhaps a User Guide and a 
Reference Guide would be even better.

Here are some Antora generated sites:

Customized UI:
https://camel.apache.org/manual/latest/getting-started.html / 
https://github.com/apache/camel/tree/master/docs
https://isis.apache.org/guides/ugfun/ugfun.html (using rather non-standard 
navigation; I find this confusing) 
/https://github.com/apache/isis/tree/master/antora (I think this is far too 
complicated, but it’s one approach to organizing a gigantic disorganized set of 
documentation)
https://docs.couchbase.com/server/6.5/introduction/intro.html / 
https://github.com/couchbase/docs-site
https://www.uyuni-project.org/uyuni-docs/uyuni/index.html / 
https://github.com/uyuni-project/uyuni-docs

Unmodified UI
https://books.japila.pl/apache-spark-internals/apache-spark-internals/latest/index.html
 / https://github.com/japila-books/apache-spark-internals

There’s a list of more sites here:

https://gitlab.com/antora/antora.org/issues/20

Some of these sites, for reasons I don’t understand, avoid making it clear that 
there are multiple components and versions.  In the default UI, and several of 
these sites, at the lower left there’s a component selector allowing you to 
choose which component/version you want to look at.

This is also visible in my preview site.

I’m not aware of any other comparable system that provides built in this level 
of organization.

David Jencks

> On Feb 19, 2020, at 5:24 AM, gilbertoca  wrote:
> 
> David Blevins-2 wrote
>> There's an entire facet of this discussion we probably should be talking
>> about which is how to deal with our heaps of content in various states of
>> health; how did it get unhealthy, how do we deal with it, how do we
>> prevent it, how do we encourage more contribution to main docs.
>> 
>> I think any tool in the hands of someone willing to lead an effort to
>> improve our main docs is a good tool.
>> 
>> -David
> 
> We could follow (again) apache friends and others [1] condensing all
> relevant content in something like a User Guide or Reference Guide - that
> would help the Maintenance and contribution. This organization can reduce
> the tooling and it easy integrate(asciidoctor-maven-plugin?) in build
> system[2].
> 
> [1]
> https://netbeans.apache.org/kb/docs/java/index.html
> https://ci.apache.org/projects/wicket/guide/8.x/single.html
> https://beanvalidation.org/2.0/spec/
> https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html
> https://shiro.apache.org/reference.html
> 
> [2] https://asciidoctor.org/docs/asciidoctor-maven-plugin/
> 
> Regards,
> 
> Gilberto
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Draft Proposal for overall website direction

[Daniel Cunha]

I like the ideas as well and I'm totally agree with you Jon.

Em qua., 19 de fev. de 2020 às 10:38, Jonathan Gallimore <
jonathan.gallim...@gmail.com> escreveu:

> I'm not strongly opinionated on the tools to actually generate the content.
> In terms of the organization of the content, I've never quite felt it we
> had right. I know there's been user vs developer and version vs not-version
> discussions in the past.
>
> I quite like the idea of the guide Gilberto has suggested below. If we
> followed that route, I'd still like to see it specific to a TomEE version.
> If it enabled us to provide a complete PDF for offline reading as well,
> that would be amazing. We probably have the content to produce a guide, but
> it would need some re-arranging from what's there I would imagine.
>
> Jon
>
> On Wed, Feb 19, 2020 at 1:24 PM gilbertoca  wrote:
>
> > David Blevins-2 wrote
> > > There's an entire facet of this discussion we probably should be
> talking
> > > about which is how to deal with our heaps of content in various states
> of
> > > health; how did it get unhealthy, how do we deal with it, how do we
> > > prevent it, how do we encourage more contribution to main docs.
> > >
> > > I think any tool in the hands of someone willing to lead an effort to
> > > improve our main docs is a good tool.
> > >
> > > -David
> >
> > We could follow (again) apache friends and others [1] condensing all
> > relevant content in something like a User Guide or Reference Guide - that
> > would help the Maintenance and contribution. This organization can reduce
> > the tooling and it easy integrate(asciidoctor-maven-plugin?) in build
> > system[2].
> >
> > [1]
> > https://netbeans.apache.org/kb/docs/java/index.html
> > https://ci.apache.org/projects/wicket/guide/8.x/single.html
> > https://beanvalidation.org/2.0/spec/
> > https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html
> > https://shiro.apache.org/reference.html
> >
> > [2] https://asciidoctor.org/docs/asciidoctor-maven-plugin/
> >
> > Regards,
> >
> > Gilberto
> >
> >
> >
> > --
> > Sent from:
> > http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
> >
>


-- 
Daniel "soro" Cunha
https://twitter.com/dvlc_

Re: Draft Proposal for overall website direction

[Jonathan Gallimore]

I'm not strongly opinionated on the tools to actually generate the content.
In terms of the organization of the content, I've never quite felt it we
had right. I know there's been user vs developer and version vs not-version
discussions in the past.

I quite like the idea of the guide Gilberto has suggested below. If we
followed that route, I'd still like to see it specific to a TomEE version.
If it enabled us to provide a complete PDF for offline reading as well,
that would be amazing. We probably have the content to produce a guide, but
it would need some re-arranging from what's there I would imagine.

Jon

On Wed, Feb 19, 2020 at 1:24 PM gilbertoca  wrote:

> David Blevins-2 wrote
> > There's an entire facet of this discussion we probably should be talking
> > about which is how to deal with our heaps of content in various states of
> > health; how did it get unhealthy, how do we deal with it, how do we
> > prevent it, how do we encourage more contribution to main docs.
> >
> > I think any tool in the hands of someone willing to lead an effort to
> > improve our main docs is a good tool.
> >
> > -David
>
> We could follow (again) apache friends and others [1] condensing all
> relevant content in something like a User Guide or Reference Guide - that
> would help the Maintenance and contribution. This organization can reduce
> the tooling and it easy integrate(asciidoctor-maven-plugin?) in build
> system[2].
>
> [1]
> https://netbeans.apache.org/kb/docs/java/index.html
> https://ci.apache.org/projects/wicket/guide/8.x/single.html
> https://beanvalidation.org/2.0/spec/
> https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html
> https://shiro.apache.org/reference.html
>
> [2] https://asciidoctor.org/docs/asciidoctor-maven-plugin/
>
> Regards,
>
> Gilberto
>
>
>
> --
> Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>

Re: Draft Proposal for overall website direction

[gilbertoca]

David Blevins-2 wrote
> There's an entire facet of this discussion we probably should be talking
> about which is how to deal with our heaps of content in various states of
> health; how did it get unhealthy, how do we deal with it, how do we
> prevent it, how do we encourage more contribution to main docs.
> 
> I think any tool in the hands of someone willing to lead an effort to
> improve our main docs is a good tool.
> 
> -David

We could follow (again) apache friends and others [1] condensing all
relevant content in something like a User Guide or Reference Guide - that
would help the Maintenance and contribution. This organization can reduce
the tooling and it easy integrate(asciidoctor-maven-plugin?) in build
system[2].

[1]
https://netbeans.apache.org/kb/docs/java/index.html
https://ci.apache.org/projects/wicket/guide/8.x/single.html
https://beanvalidation.org/2.0/spec/
https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html
https://shiro.apache.org/reference.html

[2] https://asciidoctor.org/docs/asciidoctor-maven-plugin/

Regards,

Gilberto



--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Draft Proposal for overall website direction

[David Jencks]

Sorry for top posting… I might have a slightly different direction to look in.

Thinking about some of the comments along the lines of “jbake is good enough” 
I’ve realized that, for me, the main benefit Antora brings over anything else 
I’m aware of is that it helps you organize your content in a sensible yet very 
flexible way.

I’d like to draw an analogy to the ant-vs.-maven controversy, if anyone 
remembers that far back :-)  They are both build tools that take your java 
source and use the java compiler to create class files.  Aren’t they just the 
same then?  Well, would you suggest taking TomEE to an ant-based build?  
Perhaps not…. maven suggests a project organization that makes good sense for 
most java projects, and does about 70-99% of the organizational work for you.

Perhaps similarly, Antora more or less enforces a simple sensible documentation 
organization, and provides a simple consistent way to get a nice looking 
website out with almost no configuration needed.

This documentation project is much larger than I anticipated at first, and the 
hard part is finding all the content and figuring out a plausible organization. 
 I think I’ve found pretty much everything, and have a preliminary 
organization.  Admittedly I’m strongly biased in favor of Antora, but I would 
never have considered the project of even collecting all the existing content 
without the organization Antora provides.

That said, I’m fairly amazed at how much of Antora’s functionality David has 
compressed into the tomcat-site-generator.  However, it’s incomplete, 
undocumented, unmaintained, and buggy.  I suggest that maintaining something 
like that is not what anyone involved in TomEE wants to be spending their time 
on.

One possible other factor to consider is that my interest here is primarily in 
finding out what it’s like to migrate a moderately complex disorganized website 
to Antora, and investigating what extensions or outside work (such as javadoc) 
are needed. I’m really not interested in participating in other solutions.  I 
expect to continue until I get something I’m satisfied with or I get tired.  I 
think I already have pretty much all the content as Asciidoctor, and I hope to 
get it to idiomatic error-free asciidoc. If the community wants a non-Antora 
solution it should be moderately straightforward to de-Antora-ize the content, 
but it’s not something I’m likely to be participating in.

In partial answer to David’s last question, I think one reason for the doc 
decay was allowing too many choices, so that it quickly became too hard to 
figure out how to do anything.

Thanks
David Jencks




> On Feb 18, 2020, at 1:27 PM, David Blevins  wrote:
> 
>> On Feb 18, 2020, at 12:57 PM, Guillermo García  wrote:
>> 
>> I don't want to open a difficult debate about which technology is the best,
>> but in the worst case is it possible to call a committee for a votation?
>> How the TomEE committers team defines which direction to take in these
>> cases?
> 
> We definitely still need much more discussion and participation to hammer out 
> all the topics on this.  In ideal situations you can find agreement on parts 
> and then reduce the scope of what's being discussed so where people disagree 
> is more clear.  That often allows it to be more easily addressed.
> 
> When you've done a good job on all that and everyone feels they understand 
> what's being discussed and are all "talked out", it's a definite sign a vote 
> is the only remaining way to move forward and you hold one.
> 
> Some projects are pretty strict about whose votes count.  Some say just votes 
> from the PMC members count (small group).  Some say just the committers 
> (slightly larger).  We've typically been pretty open and say everyone's votes 
> count; it's hard to grow a project while telling people who are your future 
> growth, "your vote doesn't count." :)
> 
> On this topic specifically, I also agree with David on several things and I 
> definitely don't feel "talked out", so at least for my perspective, we're 
> aways away from voting on anything.
> 
> More participation will definitely help the discussion along.
> 
> There's an entire facet of this discussion we probably should be talking 
> about which is how to deal with our heaps of content in various states of 
> health; how did it get unhealthy, how do we deal with it, how do we prevent 
> it, how do we encourage more contribution to main docs.
> 
> I think any tool in the hands of someone willing to lead an effort to improve 
> our main docs is a good tool.
> 
> 
> -David
> 
> 
> 
> 
> 
> 
> 
> 

Re: Draft Proposal for overall website direction

[David Blevins]

> On Feb 18, 2020, at 12:57 PM, Guillermo García  wrote:
> 
> I don't want to open a difficult debate about which technology is the best,
> but in the worst case is it possible to call a committee for a votation?
> How the TomEE committers team defines which direction to take in these
> cases?

We definitely still need much more discussion and participation to hammer out 
all the topics on this.  In ideal situations you can find agreement on parts 
and then reduce the scope of what's being discussed so where people disagree is 
more clear.  That often allows it to be more easily addressed.

When you've done a good job on all that and everyone feels they understand 
what's being discussed and are all "talked out", it's a definite sign a vote is 
the only remaining way to move forward and you hold one.

Some projects are pretty strict about whose votes count.  Some say just votes 
from the PMC members count (small group).  Some say just the committers 
(slightly larger).  We've typically been pretty open and say everyone's votes 
count; it's hard to grow a project while telling people who are your future 
growth, "your vote doesn't count." :)

On this topic specifically, I also agree with David on several things and I 
definitely don't feel "talked out", so at least for my perspective, we're aways 
away from voting on anything.

More participation will definitely help the discussion along.

There's an entire facet of this discussion we probably should be talking about 
which is how to deal with our heaps of content in various states of health; how 
did it get unhealthy, how do we deal with it, how do we prevent it, how do we 
encourage more contribution to main docs.

I think any tool in the hands of someone willing to lead an effort to improve 
our main docs is a good tool.


-David

Re: Draft Proposal for overall website direction

[Guillermo García]

Hi Hilberto,

I have been following some David's ideas and I agree with him in the
direction of using Antora.  I consider Antora in a mature state to let us
manage the website efficiently. And I am not worried about learning a new
tool, even if it is jbake.

I don't want to open a difficult debate about which technology is the best,
but in the worst case is it possible to call a committee for a votation?
How the TomEE committers team defines which direction to take in these
cases?


Best,

Guillermo

On Tue, Feb 18, 2020, 2:49 PM David Jencks  wrote:

> Antora already supports “edit this page". Some pages in the current site
> have a button for it, but I don’t know if it works.
>
> David Jencks
>
> > On Feb 18, 2020, at 10:43 AM, gilbertoca  wrote:
> >
> > I would stick with jvm tool (jbake) instead of add/learn one
> > more(node-antora). Specially I would to suggest we adopt what our Apache
> > Netbeans friends have done with jbake (jbake.org) in thier site
> > (https://netbeans.apache.org/). There, in each page you have a button
> ("See
> > this page in GitHub") where you/anyone can edit the original asciidoc
> file
> > and make PR for contribution.
> >
> > Regards,
> >
> > Gilberto
> >
> >
> > David Blevins-2 wrote
> >> All,
> >>
> >> I have a draft of something we can kick around for our website overall.
> >>
> >> -
> >>
> https://github.com/apache/tomee-site-generator/blob/master/WEBSITE-2020.adoc
> >>
> >> This took 3 hours to write so apologies for the size.  Much of this is
> >> experience from all the efforts of the past, some imagined improvements
> to
> >> successful parts of the site, while paving the way for the Antora work.
> >>
> >> Food on the table, cranky wife!  Must go!
> >>
> >> Sorry for the short email! :)
> >>
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >
> >
> >
> >
> >
> > --
> > Sent from:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>
>

Re: Draft Proposal for overall website direction

[David Blevins]

Everyone should follow Gilberto's example and jump into the conversation.

It's common on open source for two people to race out ahead of everyone.  The 
train looks like it's moving fast and jumping in looks dangerous, so people get 
intimidated and that compounds.  Trains that go too fast often derail.

Jumping even with questions is a huge contribution.  You don't need to jump in 
with an expert opinion.  Just jump :)


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Feb 18, 2020, at 10:43 AM, gilbertoca  wrote:
> 
> I would stick with jvm tool (jbake) instead of add/learn one
> more(node-antora). Specially I would to suggest we adopt what our Apache
> Netbeans friends have done with jbake (jbake.org) in thier site
> (https://netbeans.apache.org/). There, in each page you have a button ("See
> this page in GitHub") where you/anyone can edit the original asciidoc file
> and make PR for contribution.
> 
> Regards,
> 
> Gilberto
> 
> 
> David Blevins-2 wrote
>> All,
>> 
>> I have a draft of something we can kick around for our website overall.
>> 
>> -
>> https://github.com/apache/tomee-site-generator/blob/master/WEBSITE-2020.adoc
>> 
>> This took 3 hours to write so apologies for the size.  Much of this is
>> experience from all the efforts of the past, some imagined improvements to
>> successful parts of the site, while paving the way for the Antora work.
>> 
>> Food on the table, cranky wife!  Must go!
>> 
>> Sorry for the short email! :)
>> 
>> 
>> -- 
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
> 
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Draft Proposal for overall website direction

[David Jencks]

Antora already supports “edit this page". Some pages in the current site have a 
button for it, but I don’t know if it works.

David Jencks

> On Feb 18, 2020, at 10:43 AM, gilbertoca  wrote:
> 
> I would stick with jvm tool (jbake) instead of add/learn one
> more(node-antora). Specially I would to suggest we adopt what our Apache
> Netbeans friends have done with jbake (jbake.org) in thier site
> (https://netbeans.apache.org/). There, in each page you have a button ("See
> this page in GitHub") where you/anyone can edit the original asciidoc file
> and make PR for contribution.
> 
> Regards,
> 
> Gilberto
> 
> 
> David Blevins-2 wrote
>> All,
>> 
>> I have a draft of something we can kick around for our website overall.
>> 
>> -
>> https://github.com/apache/tomee-site-generator/blob/master/WEBSITE-2020.adoc
>> 
>> This took 3 hours to write so apologies for the size.  Much of this is
>> experience from all the efforts of the past, some imagined improvements to
>> successful parts of the site, while paving the way for the Antora work.
>> 
>> Food on the table, cranky wife!  Must go!
>> 
>> Sorry for the short email! :)
>> 
>> 
>> -- 
>> David Blevins
>> http://twitter.com/dblevins
>> http://www.tomitribe.com
> 
> 
> 
> 
> 
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

Re: Draft Proposal for overall website direction

[gilbertoca]

I would stick with jvm tool (jbake) instead of add/learn one
more(node-antora). Specially I would to suggest we adopt what our Apache
Netbeans friends have done with jbake (jbake.org) in thier site
(https://netbeans.apache.org/). There, in each page you have a button ("See
this page in GitHub") where you/anyone can edit the original asciidoc file
and make PR for contribution.

Regards,

Gilberto


David Blevins-2 wrote
> All,
> 
> I have a draft of something we can kick around for our website overall.
> 
>  -
> https://github.com/apache/tomee-site-generator/blob/master/WEBSITE-2020.adoc
> 
> This took 3 hours to write so apologies for the size.  Much of this is
> experience from all the efforts of the past, some imagined improvements to
> successful parts of the site, while paving the way for the Antora work.
> 
> Food on the table, cranky wife!  Must go!
> 
> Sorry for the short email! :)
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com





--
Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html

[GitHub] [tomee-site-generator] djencks merged pull request #19: Website 2020 - some initial too long and unfocused comments, but at least written down.

[GitBox]

djencks merged pull request #19: Website 2020 - some initial too long and 
unfocused comments, but at least written down.
URL: https://github.com/apache/tomee-site-generator/pull/19
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services