You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@gmail.com> on 2021/03/24 22:14:02 UTC

Download page improvements/rework (was Re: Release related Issues created by INFRA)

> On Mar 24, 2021, at 12:40 AM, Richard Zowalla <rz...@apache.org> wrote:
> 
> I have merged the "manual" changes to add the missing links to the .asc
> files of the release download page.
> 
> In this process, I discovered, that we are not using the Downloads
> generator class [2] anymore. My questions is:
> 
> Did we switch on purpose from Maven repository links (for the binaries)
> towards mirror links? (just want to catch up on this)

We definitely should reinstate the automation, but we probably want to redo the Downloads generator class.

Someday, hopefully in the near future, we'll be some form of Jakarta EE certified.  When that happens we'll need to create a "public test results page" for each release.  It needs to contain the following information[1]:

- Product Name, Version and download URL
- Specification Name, Version and download URL
- TCK Version, digital SHA-256 fingerprint and download URL
- Java runtime used to run the implementation
- Summary of the information for the certification environment, operating system, cloud, …​
- List of tests passed (can be a link to another page, say the xml output from running the TCK)

I drafted those requirements that were eventually approved and adopted.  What was in my head is that smart implementations would simply use their actual download page for these details.  Our current table format isn't that great in the first place (kind of noisy and cluttered), so not really a good starting point for adding more.

In the distant past we used to create a page for each release, even including generated release notes from JIRA.

 - http://tomee.apache.org/tomee-1.0.0-beta-1.html
 - http://tomee.apache.org/tomee-1.5.0.html
 - http://tomee.apache.org/tomee-1.6.0.1.html
 - http://tomee.apache.org/tomee-1.7.0.html

 - http://tomee.apache.org/tomee-1.5.0-release-notes.html
 - http://tomee.apache.org/tomee-1.5.1-release-notes.html
 - http://tomee.apache.org/tomee-1.7.0-release-notes.html

The code that generated the release notes (and most the release tasks even including vote threads) is here:

 - http://svn.apache.org/repos/asf/tomee/sandbox/release-tools/src/main/java/org/apache/openejb/tools/release/cmd/

This just decayed over time.  I'd be blissfully happy with a single generated page for each release that contained just the download links for now.  In the future we can add certification information below the download links.  In the future future, we can add generated release notes in list format below that.

There's just so much automation we could be doing around releases, especially now that we could potentially setup Jenkins to do the work.  We could have parameterized jobs to do nearly everything that was going on in the `asf/tomee/sandbox/release-tools/` repo.

Tasks like adding the new release to the mirror and removing the old one could be automated.  As could generating a release page and pushing it to the website, while also updating the page for the just-removed-from-the-mirror release to now point at archive.apache.org.

At tomee.apache.org/download we could either point to the latest release page and have no direct zip, tar links or have some sort of short version of the download links.  I'd probably be in favor of just pointing so it's easier to maintain.

On the release notes, what killed that is all the JIRA APIs changed from RPC, to some xml format to now REST.  The library I wrote in the 2006-range (swizzle-jira) eventually got too outdated and stopped working around 2012.  There are now Atlassian maintained java clients for JIRA as far as I understand, so we'd could potentially make something new with that.

Of course we can just fix the current Downloads.java for now, but if you get inspired it'd be a thing of beauty to see the project become what it once was :)

That said, we have a brief window from now till end of April before Jakarta EE 9.1 is scheduled to be released.  I don't know if we can get completely certified in that time, but we're down to 400-500 failing tests on EE 9.1 and at least a hundred or two of them are tied to changes we'd need to make in the TCK which are only possible between now and end of April.  After that we'd need to file TCK challenges to have tests removed, but can't actually fix them.  I'll be doing what I can in the time I can get to push on that and help is always welcome!

So many things to do, so little time! :)


-David


[1] https://jakarta.ee/committees/specification/tckprocess/

Re: Download page improvements/rework (was Re: Release related Issues created by INFRA)

Posted by David Blevins <da...@gmail.com>.
> On Mar 25, 2021, at 7:53 AM, Zowalla, Richard <ri...@hs-heilbronn.de> wrote:
> 
> Hi,
> 
> I am totally with you. We should automate the release-related tooling,
> the creation of the related notes as well as the download pages. 
> 
> However, we should keep in mind, that we had some Antorra-based website
> rework. I do not remember the current status but I guess it is also
> .adoc based - so I guess, it would be no show stopper.

Exactly.  As long as we generate adoc we're good and can use a wide variety of html generating tools.

We're now of the Apache CMS, so the path is clear for Antora and any other things that can generate html from adoc.  Us being on the CMS was definitely standing in the way.

> Might also a good starting point for some contributors out where :-)

Agreed.


-David

> Am Mittwoch, den 24.03.2021, 15:14 -0700 schrieb David Blevins:
>>> On Mar 24, 2021, at 12:40 AM, Richard Zowalla <rz...@apache.org>
>>> wrote:
>>> 
>>> I have merged the "manual" changes to add the missing links to the
>>> .asc
>>> files of the release download page.
>>> 
>>> In this process, I discovered, that we are not using the Downloads
>>> generator class [2] anymore. My questions is:
>>> 
>>> Did we switch on purpose from Maven repository links (for the
>>> binaries)
>>> towards mirror links? (just want to catch up on this)
>> 
>> We definitely should reinstate the automation, but we probably want
>> to redo the Downloads generator class.
>> 
>> Someday, hopefully in the near future, we'll be some form of Jakarta
>> EE certified.  When that happens we'll need to create a "public test
>> results page" for each release.  It needs to contain the following
>> information[1]:
>> 
>> - Product Name, Version and download URL
>> - Specification Name, Version and download URL
>> - TCK Version, digital SHA-256 fingerprint and download URL
>> - Java runtime used to run the implementation
>> - Summary of the information for the certification environment,
>> operating system, cloud, …
>> - List of tests passed (can be a link to another page, say the xml
>> output from running the TCK)
>> 
>> I drafted those requirements that were eventually approved and
>> adopted.  What was in my head is that smart implementations would
>> simply use their actual download page for these details.  Our current
>> table format isn't that great in the first place (kind of noisy and
>> cluttered), so not really a good starting point for adding more.
>> 
>> In the distant past we used to create a page for each release, even
>> including generated release notes from JIRA.
>> 
>> - http://tomee.apache.org/tomee-1.0.0-beta-1.html
>> - http://tomee.apache.org/tomee-1.5.0.html
>> - http://tomee.apache.org/tomee-1.6.0.1.html
>> - http://tomee.apache.org/tomee-1.7.0.html
>> 
>> - http://tomee.apache.org/tomee-1.5.0-release-notes.html
>> - http://tomee.apache.org/tomee-1.5.1-release-notes.html
>> - http://tomee.apache.org/tomee-1.7.0-release-notes.html
>> 
>> The code that generated the release notes (and most the release tasks
>> even including vote threads) is here:
>> 
>> - 
>> http://svn.apache.org/repos/asf/tomee/sandbox/release-tools/src/main/java/org/apache/openejb/tools/release/cmd/
>> 
>> This just decayed over time.  I'd be blissfully happy with a single
>> generated page for each release that contained just the download
>> links for now.  In the future we can add certification information
>> below the download links.  In the future future, we can add generated
>> release notes in list format below that.
>> 
>> There's just so much automation we could be doing around releases,
>> especially now that we could potentially setup Jenkins to do the
>> work.  We could have parameterized jobs to do nearly everything that
>> was going on in the `asf/tomee/sandbox/release-tools/` repo.
>> 
>> Tasks like adding the new release to the mirror and removing the old
>> one could be automated.  As could generating a release page and
>> pushing it to the website, while also updating the page for the just-
>> removed-from-the-mirror release to now point at archive.apache.org.
>> 
>> At tomee.apache.org/download we could either point to the latest
>> release page and have no direct zip, tar links or have some sort of
>> short version of the download links.  I'd probably be in favor of
>> just pointing so it's easier to maintain.
>> 
>> On the release notes, what killed that is all the JIRA APIs changed
>> from RPC, to some xml format to now REST.  The library I wrote in the
>> 2006-range (swizzle-jira) eventually got too outdated and stopped
>> working around 2012.  There are now Atlassian maintained java clients
>> for JIRA as far as I understand, so we'd could potentially make
>> something new with that.
>> 
>> Of course we can just fix the current Downloads.java for now, but if
>> you get inspired it'd be a thing of beauty to see the project become
>> what it once was :)
>> 
>> That said, we have a brief window from now till end of April before
>> Jakarta EE 9.1 is scheduled to be released.  I don't know if we can
>> get completely certified in that time, but we're down to 400-500
>> failing tests on EE 9.1 and at least a hundred or two of them are
>> tied to changes we'd need to make in the TCK which are only possible
>> between now and end of April.  After that we'd need to file TCK
>> challenges to have tests removed, but can't actually fix them.  I'll
>> be doing what I can in the time I can get to push on that and help is
>> always welcome!
>> 
>> So many things to do, so little time! :)
>> 
>> 
>> -David
>> 
>> 
>> [1] https://jakarta.ee/committees/specification/tckprocess/
> -- 
> 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
> mail: richard.zowalla@hs-heilbronn.de
> web: https://www.mi.hs-heilbronn.de/ 


Re: Download page improvements/rework (was Re: Release related Issues created by INFRA)

Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Hi,

I am totally with you. We should automate the release-related tooling,
the creation of the related notes as well as the download pages. 

However, we should keep in mind, that we had some Antorra-based website
rework. I do not remember the current status but I guess it is also
.adoc based - so I guess, it would be no show stopper.

Might also a good starting point for some contributors out where :-)

Gruss
Richard

Am Mittwoch, den 24.03.2021, 15:14 -0700 schrieb David Blevins:
> > On Mar 24, 2021, at 12:40 AM, Richard Zowalla <rz...@apache.org>
> > wrote:
> > 
> > I have merged the "manual" changes to add the missing links to the
> > .asc
> > files of the release download page.
> > 
> > In this process, I discovered, that we are not using the Downloads
> > generator class [2] anymore. My questions is:
> > 
> > Did we switch on purpose from Maven repository links (for the
> > binaries)
> > towards mirror links? (just want to catch up on this)
> 
> We definitely should reinstate the automation, but we probably want
> to redo the Downloads generator class.
> 
> Someday, hopefully in the near future, we'll be some form of Jakarta
> EE certified.  When that happens we'll need to create a "public test
> results page" for each release.  It needs to contain the following
> information[1]:
> 
> - Product Name, Version and download URL
> - Specification Name, Version and download URL
> - TCK Version, digital SHA-256 fingerprint and download URL
> - Java runtime used to run the implementation
> - Summary of the information for the certification environment,
> operating system, cloud, …
> - List of tests passed (can be a link to another page, say the xml
> output from running the TCK)
> 
> I drafted those requirements that were eventually approved and
> adopted.  What was in my head is that smart implementations would
> simply use their actual download page for these details.  Our current
> table format isn't that great in the first place (kind of noisy and
> cluttered), so not really a good starting point for adding more.
> 
> In the distant past we used to create a page for each release, even
> including generated release notes from JIRA.
> 
>  - http://tomee.apache.org/tomee-1.0.0-beta-1.html
>  - http://tomee.apache.org/tomee-1.5.0.html
>  - http://tomee.apache.org/tomee-1.6.0.1.html
>  - http://tomee.apache.org/tomee-1.7.0.html
> 
>  - http://tomee.apache.org/tomee-1.5.0-release-notes.html
>  - http://tomee.apache.org/tomee-1.5.1-release-notes.html
>  - http://tomee.apache.org/tomee-1.7.0-release-notes.html
> 
> The code that generated the release notes (and most the release tasks
> even including vote threads) is here:
> 
>  - 
> http://svn.apache.org/repos/asf/tomee/sandbox/release-tools/src/main/java/org/apache/openejb/tools/release/cmd/
> 
> This just decayed over time.  I'd be blissfully happy with a single
> generated page for each release that contained just the download
> links for now.  In the future we can add certification information
> below the download links.  In the future future, we can add generated
> release notes in list format below that.
> 
> There's just so much automation we could be doing around releases,
> especially now that we could potentially setup Jenkins to do the
> work.  We could have parameterized jobs to do nearly everything that
> was going on in the `asf/tomee/sandbox/release-tools/` repo.
> 
> Tasks like adding the new release to the mirror and removing the old
> one could be automated.  As could generating a release page and
> pushing it to the website, while also updating the page for the just-
> removed-from-the-mirror release to now point at archive.apache.org.
> 
> At tomee.apache.org/download we could either point to the latest
> release page and have no direct zip, tar links or have some sort of
> short version of the download links.  I'd probably be in favor of
> just pointing so it's easier to maintain.
> 
> On the release notes, what killed that is all the JIRA APIs changed
> from RPC, to some xml format to now REST.  The library I wrote in the
> 2006-range (swizzle-jira) eventually got too outdated and stopped
> working around 2012.  There are now Atlassian maintained java clients
> for JIRA as far as I understand, so we'd could potentially make
> something new with that.
> 
> Of course we can just fix the current Downloads.java for now, but if
> you get inspired it'd be a thing of beauty to see the project become
> what it once was :)
> 
> That said, we have a brief window from now till end of April before
> Jakarta EE 9.1 is scheduled to be released.  I don't know if we can
> get completely certified in that time, but we're down to 400-500
> failing tests on EE 9.1 and at least a hundred or two of them are
> tied to changes we'd need to make in the TCK which are only possible
> between now and end of April.  After that we'd need to file TCK
> challenges to have tests removed, but can't actually fix them.  I'll
> be doing what I can in the time I can get to push on that and help is
> always welcome!
> 
> So many things to do, so little time! :)
> 
> 
> -David
> 
> 
> [1] https://jakarta.ee/committees/specification/tckprocess/
-- 
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
mail: richard.zowalla@hs-heilbronn.de
web: https://www.mi.hs-heilbronn.de/