You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Richard Zowalla <rz...@apache.org> on 2021/03/09 08:30:35 UTC
Release related Issues created by INFRA
Hi all,
INFRA created two tasks related to our releases on Jira [1,2].
To address [1], I created a PR [3] on the tomee-site-generator project.
Romain had some feedback on it and we discovered, that we changed the
release links from Maven repositories links towards Mirror links.
My PR is a manual fix to address the concerns raised by INFRA related
to missing links to the .asc files. I also added instructions on how to
check the integrity of the provided release files.
However, I think, that we should discuss the approach in general, ie.
which kind of binaries are deployed via the mirroring system and which
binaries are provided via Maven repositories. This is also relevant in
terms of [2] as INFRA has requested to delete non active versions from
the mirroring system.
The problem with the mirroring system might be, that the current
process seems to be of "manual" nature (?) while the "old" process (via
Downloads.java) generated (and verified) the download links for
copy&paste them into the "download-ng.adoc".
Wdyt?
Gruss,
Richard
[1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2975
[2] https://issues.apache.org/jira/browse/TOMEE-1096
[3] https://github.com/apache/tomee-site-generator/pull/21
Re: Release related Issues created by INFRA
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Hi,
thanks for the feedback. It is very welcome!
Gruss
Richard
Am Donnerstag, den 25.03.2021, 19:53 -0700 schrieb David Blevins:
> > On Mar 25, 2021, at 7:53 AM, Zowalla, Richard <
> > richard.zowalla@hs-heilbronn.de> wrote:
> >
> > Hi David, Hi Jon,
> >
> > thanks for your replies.
> >
> > I just pushed some (short term) fixes to the tomee-site-generator:
> >
> > (a) Added an (experimental) generator to create the download page
> > based
> > on downloads.apache.org or archive.apache.org (rather than using
> > repo.maven.apache.org), so we can be sure, that the links are
> > working.
> >
> > (b) I updated the downloads-ng.adoc with (1) the feedback by Sebb
> > and
> > Romain from [1] - so it is now a bit "cleaner" (imho).
> >
> > (c) I updated and automatically converted the previous download-
> > archive.adoc to ensure, that the links are working again. We had
> > some
> > mismatches related to "http" for the repo.maven.apache.org links
> > for
> > very old releases and some broken links due to the request by INFRA
> > to
> > remove very old relases from the mirroring system. Old releases,
> > which
> > previously linked to the mirrors are now linking to
> > archive.apache.org.
> >
> > I will try to update https://github.com/apache/tomee-site-pub with
> > the
> > changes as well.
> >
> > As stated above: This is only a "short term" fix to comply with the
> > infra requirements. I will respond on the other mail as well.
>
> Took a quick look and love the clean and direct approach you have in
> the code! I'm a big fan of static inner classes to keep code tight
> and easy to digest.
>
> Some style advice, get in the habit of using the `final` keyword on
> all fields, variables and parameters. It'll look strange at first,
> but you'll get used to it and it'll change the way you code in a good
> way.
>
> For example these variables should be marked final and not
> initialized immediately:
>
> -
> https://github.com/apache/tomee-site-generator/commit/27a46ae7d958867431398f86abf1ed55df4a3f74#diff-30e729b63bba575db7b6e9681e02c8ff1faf81f33d27c610c2bbeb4fe333cc23R149-R151
>
> Once you did that all your code would work ok, minus this chunk which
> the compiler would force you to deal with differently. You'd be
> forced to handle the situation better than simply a System.out no one
> will read.
>
> -
> https://github.com/apache/tomee-site-generator/commit/27a46ae7d958867431398f86abf1ed55df4a3f74#diff-30e729b63bba575db7b6e9681e02c8ff1faf81f33d27c610c2bbeb4fe333cc23R162-R164
>
> If it's not going to work, better it really doesn't work and just
> throw an exception with "this should never happen." That way the
> future Jenkins job will appear red, not green, and we don't update
> the website with any potentially invalid content. Instead of someone
> coming to the website and seeing links with no names, they'd simply
> see the old-but-valid links. The developer who attempted the website
> update can just as easily determine the update didn't work by
> noticing the links are old as they can by the links are
> invalid. However if they don't notice by looking at the website,
> they can notice by seeing failed Jenkins job. Until they notice, the
> website stays valid (assuming the release wasn't removed from the
> mirror of course).
>
> Moreover, if someone who is not you tried to use this code and that
> "should never happen" situation occurred, they'd have no exception or
> stack trace to immediately point them in the right direction. They'd
> have to be keen to spot "This should not happen. New extensions?"
> among the output, know it is significant, and search for the line in
> the code where it occurs. Often an exception does occur, just later
> in the code and that often means people more easily miss the "This
> should not happen" output, because their attention is drawn to the
> stacktrace which is actually just a symptom.
>
> Avoiding mutable fields and favoring final would have forced you down
> the path of eagerly failing vs continuing with invalid defaults.
>
> Love the update, I see you did use final in many places! You're on
> the right track. Lean into that more and try to force yourself to
> use it even when it at first feels odd. I hope the feedback is
> welcome and you see it as a compliment. You've been doing so much
> great work and spending your time helping the project, it's my way of
> saying thank you and you're worth the time to mentor :) For whatever
> that's worth :)
>
> Keep up the truly awesome work. If we had 5 more Richards this
> project would be signing. We'll get there :)
>
>
> -David
>
--
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: Release related Issues created by INFRA
Posted by David Blevins <da...@gmail.com>.
> On Mar 25, 2021, at 7:53 PM, David Blevins <da...@gmail.com> wrote:
>
> Some style advice, get in the habit of using the `final` keyword on all fields, variables and parameters.
Of course I mean "where possible." There are rare occasions where they are needed. I tend to rework my code till they are't needed and usually end up enjoying the result.
-David
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 David, Hi Jon,
>
> thanks for your replies.
>
> I just pushed some (short term) fixes to the tomee-site-generator:
>
> (a) Added an (experimental) generator to create the download page based
> on downloads.apache.org or archive.apache.org (rather than using
> repo.maven.apache.org), so we can be sure, that the links are working.
>
> (b) I updated the downloads-ng.adoc with (1) the feedback by Sebb and
> Romain from [1] - so it is now a bit "cleaner" (imho).
>
> (c) I updated and automatically converted the previous download-
> archive.adoc to ensure, that the links are working again. We had some
> mismatches related to "http" for the repo.maven.apache.org links for
> very old releases and some broken links due to the request by INFRA to
> remove very old relases from the mirroring system. Old releases, which
> previously linked to the mirrors are now linking to archive.apache.org.
>
> I will try to update https://github.com/apache/tomee-site-pub with the
> changes as well.
>
> As stated above: This is only a "short term" fix to comply with the
> infra requirements. I will respond on the other mail as well.
Took a quick look and love the clean and direct approach you have in the code! I'm a big fan of static inner classes to keep code tight and easy to digest.
Some style advice, get in the habit of using the `final` keyword on all fields, variables and parameters. It'll look strange at first, but you'll get used to it and it'll change the way you code in a good way.
For example these variables should be marked final and not initialized immediately:
- https://github.com/apache/tomee-site-generator/commit/27a46ae7d958867431398f86abf1ed55df4a3f74#diff-30e729b63bba575db7b6e9681e02c8ff1faf81f33d27c610c2bbeb4fe333cc23R149-R151
Once you did that all your code would work ok, minus this chunk which the compiler would force you to deal with differently. You'd be forced to handle the situation better than simply a System.out no one will read.
- https://github.com/apache/tomee-site-generator/commit/27a46ae7d958867431398f86abf1ed55df4a3f74#diff-30e729b63bba575db7b6e9681e02c8ff1faf81f33d27c610c2bbeb4fe333cc23R162-R164
If it's not going to work, better it really doesn't work and just throw an exception with "this should never happen." That way the future Jenkins job will appear red, not green, and we don't update the website with any potentially invalid content. Instead of someone coming to the website and seeing links with no names, they'd simply see the old-but-valid links. The developer who attempted the website update can just as easily determine the update didn't work by noticing the links are old as they can by the links are invalid. However if they don't notice by looking at the website, they can notice by seeing failed Jenkins job. Until they notice, the website stays valid (assuming the release wasn't removed from the mirror of course).
Moreover, if someone who is not you tried to use this code and that "should never happen" situation occurred, they'd have no exception or stack trace to immediately point them in the right direction. They'd have to be keen to spot "This should not happen. New extensions?" among the output, know it is significant, and search for the line in the code where it occurs. Often an exception does occur, just later in the code and that often means people more easily miss the "This should not happen" output, because their attention is drawn to the stacktrace which is actually just a symptom.
Avoiding mutable fields and favoring final would have forced you down the path of eagerly failing vs continuing with invalid defaults.
Love the update, I see you did use final in many places! You're on the right track. Lean into that more and try to force yourself to use it even when it at first feels odd. I hope the feedback is welcome and you see it as a compliment. You've been doing so much great work and spending your time helping the project, it's my way of saying thank you and you're worth the time to mentor :) For whatever that's worth :)
Keep up the truly awesome work. If we had 5 more Richards this project would be signing. We'll get there :)
-David
Re: Release related Issues created by INFRA
Posted by "Zowalla, Richard" <ri...@hs-heilbronn.de>.
Hi David, Hi Jon,
thanks for your replies.
I just pushed some (short term) fixes to the tomee-site-generator:
(a) Added an (experimental) generator to create the download page based
on downloads.apache.org or archive.apache.org (rather than using
repo.maven.apache.org), so we can be sure, that the links are working.
(b) I updated the downloads-ng.adoc with (1) the feedback by Sebb and
Romain from [1] - so it is now a bit "cleaner" (imho).
(c) I updated and automatically converted the previous download-
archive.adoc to ensure, that the links are working again. We had some
mismatches related to "http" for the repo.maven.apache.org links for
very old releases and some broken links due to the request by INFRA to
remove very old relases from the mirroring system. Old releases, which
previously linked to the mirrors are now linking to archive.apache.org.
I will try to update https://github.com/apache/tomee-site-pub with the
changes as well.
As stated above: This is only a "short term" fix to comply with the
infra requirements. I will respond on the other mail as well.
Gruss
Richard
Am Mittwoch, den 24.03.2021, 21:27 +0000 schrieb Jonathan Gallimore:
> On Wed, Mar 24, 2021 at 9:17 PM David Blevins <
> david.blevins@gmail.com>
> wrote:
>
> > Thanks or pushing this back up to the top. Some thoughts below.
> >
>
> I had just come here to say the same thing - thank you Richard!
>
>
> > > On Mar 24, 2021, at 12:46 AM, Richard Zowalla <rz...@apache.org>
> > > wrote:
> > >
> > > It seems, we are already providing SHA256/SHA512 checksums for
> > > newer
> > > releases. To rephrase my comment: If we would switch to Maven
> > > repository links instead, we would need to upgrade the parent
> > > project
> > > in order to deploy SHA256/SHA512 to Maven repositories.
> >
> > I'm curious what others think, but to me it would seem the best
> > source to
> > point at for the signatures is something on apache.org. I
> > completely
> > understand how having the mirror be the source of signatures to
> > verify
> > files on the mirror completely defeats the point :)
> >
>
> We should be linking to signatures on apache.org, and not the
> mirrors.
>
>
> > The most natural source for me would be linking signatures back to
> > the
> > mirror source which is
> > https://dist.apache.org/repos/dist/release/tomee/
> >
> > > - How to deploy changes conducted in
> > > https://github.com/apache/tomee-site-generator ?
> > >
> > > The documentation is outdated and I have no idea of the steps
> > > required
> > > to get the changes "live". If someone can explain the process, I
> > > am
> > > happy to update the documentation as well.
> Thank you in advance for the help! When David and I did work here we
> > didn't really document outside the list conversations.
> >
> > The short version is if you push modified html to this repo, it
> > shows up
> > live eventually:
> >
> > - https://github.com/apache/tomee-site-pub
> >
> > You can regenerate the site with a `mvn compile` as mentioned here:
> >
> > - https://github.com/apache/tomee-site-generator#build
> >
> > The documentation says "you just need to sync it with CMS repo",
> > but
> > doesn't give details.
> >
> >
> >
> I tend to do that manually with Beyond Compare, and I'm happy to do
> that
> for you if that helps. It would be great to have a less manual way to
> do it
> though.
>
> Jon
--
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: Release related Issues created by INFRA
Posted by Jonathan Gallimore <jo...@gmail.com>.
On Wed, Mar 24, 2021 at 9:17 PM David Blevins <da...@gmail.com>
wrote:
> Thanks or pushing this back up to the top. Some thoughts below.
>
I had just come here to say the same thing - thank you Richard!
>
> > On Mar 24, 2021, at 12:46 AM, Richard Zowalla <rz...@apache.org> wrote:
> >
> > It seems, we are already providing SHA256/SHA512 checksums for newer
> > releases. To rephrase my comment: If we would switch to Maven
> > repository links instead, we would need to upgrade the parent project
> > in order to deploy SHA256/SHA512 to Maven repositories.
>
> I'm curious what others think, but to me it would seem the best source to
> point at for the signatures is something on apache.org. I completely
> understand how having the mirror be the source of signatures to verify
> files on the mirror completely defeats the point :)
>
We should be linking to signatures on apache.org, and not the mirrors.
> The most natural source for me would be linking signatures back to the
> mirror source which is https://dist.apache.org/repos/dist/release/tomee/
>
> > - How to deploy changes conducted in
> > https://github.com/apache/tomee-site-generator ?
> >
> > The documentation is outdated and I have no idea of the steps required
> > to get the changes "live". If someone can explain the process, I am
> > happy to update the documentation as well.
>
Thank you in advance for the help! When David and I did work here we
> didn't really document outside the list conversations.
>
> The short version is if you push modified html to this repo, it shows up
> live eventually:
>
> - https://github.com/apache/tomee-site-pub
>
> You can regenerate the site with a `mvn compile` as mentioned here:
>
> - https://github.com/apache/tomee-site-generator#build
>
> The documentation says "you just need to sync it with CMS repo", but
> doesn't give details.
>
>
>
I tend to do that manually with Beyond Compare, and I'm happy to do that
for you if that helps. It would be great to have a less manual way to do it
though.
Jon
Re: Release related Issues created by INFRA
Posted by David Blevins <da...@gmail.com>.
Thanks or pushing this back up to the top. Some thoughts below.
> On Mar 24, 2021, at 12:46 AM, Richard Zowalla <rz...@apache.org> wrote:
>
> It seems, we are already providing SHA256/SHA512 checksums for newer
> releases. To rephrase my comment: If we would switch to Maven
> repository links instead, we would need to upgrade the parent project
> in order to deploy SHA256/SHA512 to Maven repositories.
I'm curious what others think, but to me it would seem the best source to point at for the signatures is something on apache.org. I completely understand how having the mirror be the source of signatures to verify files on the mirror completely defeats the point :)
The most natural source for me would be linking signatures back to the mirror source which is https://dist.apache.org/repos/dist/release/tomee/
> - How to deploy changes conducted in
> https://github.com/apache/tomee-site-generator ?
>
> The documentation is outdated and I have no idea of the steps required
> to get the changes "live". If someone can explain the process, I am
> happy to update the documentation as well.
Thank you in advance for the help! When David and I did work here we didn't really document outside the list conversations.
The short version is if you push modified html to this repo, it shows up live eventually:
- https://github.com/apache/tomee-site-pub
You can regenerate the site with a `mvn compile` as mentioned here:
- https://github.com/apache/tomee-site-generator#build
The documentation says "you just need to sync it with CMS repo", but doesn't give details. We used to do that with this class:
- https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/SvnPub.java
Now we're on Git and probably need a new version of that that uses JGit to commit the new HTML.
We could actually setup an automated process for publishing the site in Jenkins. My last research on that is here:
- https://lists.apache.org/thread.html/r6885ad10294a0e6d9c3ad2552dfe9a04239ac4dd77f15be4da9bcfff%40%3Cdev.tomee.apache.org%3E
On the download page itself, I have a handful of thoughts so I'll put those in a new thread.
Thank you so much for having energy to look into all of this!!
-David
> Am Mittwoch, den 24.03.2021, 08:40 +0100 schrieb Richard Zowalla:
>> Hi,
>>
>> wanted to raise attention on this mail again:
>>
>> 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)
>>
>> In addition, we might need to provide SHA256/SHA512 checksums for new
>> artifacts by INFRA release policies [3]. This might require to
>> upgrade
>> the ASF parent project, see [4].
>>
>> Gruss,
>> Richard
>>
>> [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2975
>> [2]
>> https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/Downloads.java
>> [3] https://infra.apache.org/release-distribution.html
>> [4] https://issues.apache.org/jira/browse/MPOM-205
>>
>> Am Dienstag, den 09.03.2021, 09:30 +0100 schrieb Richard Zowalla:
>>> Hi all,
>>>
>>> INFRA created two tasks related to our releases on Jira [1,2].
>>>
>>> To address [1], I created a PR [3] on the tomee-site-generator
>>> project.
>>> Romain had some feedback on it and we discovered, that we changed
>>> the
>>> release links from Maven repositories links towards Mirror links.
>>>
>>> My PR is a manual fix to address the concerns raised by INFRA
>>> related
>>> to missing links to the .asc files. I also added instructions on
>>> how
>>> to
>>> check the integrity of the provided release files.
>>>
>>> However, I think, that we should discuss the approach in general,
>>> ie.
>>> which kind of binaries are deployed via the mirroring system and
>>> which
>>> binaries are provided via Maven repositories. This is also relevant
>>> in
>>> terms of [2] as INFRA has requested to delete non active versions
>>> from
>>> the mirroring system.
>>>
>>> The problem with the mirroring system might be, that the current
>>> process seems to be of "manual" nature (?) while the "old" process
>>> (via
>>> Downloads.java) generated (and verified) the download links for
>>> copy&paste them into the "download-ng.adoc".
>>>
>>> Wdyt?
>>>
>>> Gruss,
>>> Richard
>>>
>>> [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2975
>>> [2] https://issues.apache.org/jira/browse/TOMEE-1096
>>> [3] https://github.com/apache/tomee-site-generator/pull/21
>>>
Re: Release related Issues created by INFRA
Posted by Richard Zowalla <rz...@apache.org>.
It seems, we are already providing SHA256/SHA512 checksums for newer
releases. To rephrase my comment: If we would switch to Maven
repository links instead, we would need to upgrade the parent project
in order to deploy SHA256/SHA512 to Maven repositories.
Other question:
- How to deploy changes conducted in
https://github.com/apache/tomee-site-generator ?
The documentation is outdated and I have no idea of the steps required
to get the changes "live". If someone can explain the process, I am
happy to update the documentation as well.
Gruss
Richard
Am Mittwoch, den 24.03.2021, 08:40 +0100 schrieb Richard Zowalla:
> Hi,
>
> wanted to raise attention on this mail again:
>
> 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)
>
> In addition, we might need to provide SHA256/SHA512 checksums for new
> artifacts by INFRA release policies [3]. This might require to
> upgrade
> the ASF parent project, see [4].
>
> Gruss,
> Richard
>
> [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2975
> [2]
> https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/Downloads.java
> [3] https://infra.apache.org/release-distribution.html
> [4] https://issues.apache.org/jira/browse/MPOM-205
>
> Am Dienstag, den 09.03.2021, 09:30 +0100 schrieb Richard Zowalla:
> > Hi all,
> >
> > INFRA created two tasks related to our releases on Jira [1,2].
> >
> > To address [1], I created a PR [3] on the tomee-site-generator
> > project.
> > Romain had some feedback on it and we discovered, that we changed
> > the
> > release links from Maven repositories links towards Mirror links.
> >
> > My PR is a manual fix to address the concerns raised by INFRA
> > related
> > to missing links to the .asc files. I also added instructions on
> > how
> > to
> > check the integrity of the provided release files.
> >
> > However, I think, that we should discuss the approach in general,
> > ie.
> > which kind of binaries are deployed via the mirroring system and
> > which
> > binaries are provided via Maven repositories. This is also relevant
> > in
> > terms of [2] as INFRA has requested to delete non active versions
> > from
> > the mirroring system.
> >
> > The problem with the mirroring system might be, that the current
> > process seems to be of "manual" nature (?) while the "old" process
> > (via
> > Downloads.java) generated (and verified) the download links for
> > copy&paste them into the "download-ng.adoc".
> >
> > Wdyt?
> >
> > Gruss,
> > Richard
> >
> > [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2975
> > [2] https://issues.apache.org/jira/browse/TOMEE-1096
> > [3] https://github.com/apache/tomee-site-generator/pull/21
> >
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/
Download page improvements/rework (was Re: Release related Issues
created by INFRA)
Posted by David Blevins <da...@gmail.com>.
> 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: Release related Issues created by INFRA
Posted by Richard Zowalla <rz...@apache.org>.
Hi,
wanted to raise attention on this mail again:
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)
In addition, we might need to provide SHA256/SHA512 checksums for new
artifacts by INFRA release policies [3]. This might require to upgrade
the ASF parent project, see [4].
Gruss,
Richard
[1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2975
[2]
https://github.com/apache/tomee-site-generator/blob/master/src/main/java/org/apache/tomee/website/Downloads.java
[3] https://infra.apache.org/release-distribution.html
[4] https://issues.apache.org/jira/browse/MPOM-205
Am Dienstag, den 09.03.2021, 09:30 +0100 schrieb Richard Zowalla:
> Hi all,
>
> INFRA created two tasks related to our releases on Jira [1,2].
>
> To address [1], I created a PR [3] on the tomee-site-generator
> project.
> Romain had some feedback on it and we discovered, that we changed the
> release links from Maven repositories links towards Mirror links.
>
> My PR is a manual fix to address the concerns raised by INFRA related
> to missing links to the .asc files. I also added instructions on how
> to
> check the integrity of the provided release files.
>
> However, I think, that we should discuss the approach in general, ie.
> which kind of binaries are deployed via the mirroring system and
> which
> binaries are provided via Maven repositories. This is also relevant
> in
> terms of [2] as INFRA has requested to delete non active versions
> from
> the mirroring system.
>
> The problem with the mirroring system might be, that the current
> process seems to be of "manual" nature (?) while the "old" process
> (via
> Downloads.java) generated (and verified) the download links for
> copy&paste them into the "download-ng.adoc".
>
> Wdyt?
>
> Gruss,
> Richard
>
> [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-2975
> [2] https://issues.apache.org/jira/browse/TOMEE-1096
> [3] https://github.com/apache/tomee-site-generator/pull/21
>