RE: Re: [TESTING] What is the status of this component?
It's also worth checking what alternatives already offer. For instance, https://junit-pioneer.org/ has @DefaultLocale which would make DefaultLocaleTestRule obsolete. Rob On 2023/12/20 18:18:25 Gary Gregory wrote: I had intended to gather various reusable JUnit rules and utilities but never got around to finishing off a first release. Since then JUnit 5 has been released. There is long term value there IMO especially with all that JUnit 5 has broken in compatibility but I've not taken the time to pursue it. Gary On Wed, Dec 20, 2023, 12:31 PM sebb wrote: > There is a repo at https://github.com/apache/commons-testing, but > almost no actual code changes. > > The component does not appear in the sandbox, dormant or proper > categories, and I could find no website for it. Seems to me the repo > should at least be flagged as dormant or sandbox. > > Sebb > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [TESTING] What is the status of this component?
On Wed, 20 Dec 2023 at 18:20, Gary Gregory wrote: > > I had intended to gather various reusable JUnit rules and utilities but > never got around to finishing off a first release. Since then JUnit 5 has > been released. There is long term value there IMO especially with all that > JUnit 5 has broken in compatibility but I've not taken the time to pursue > it. So Sandbox? > Gary > > On Wed, Dec 20, 2023, 12:31 PM sebb wrote: > > > There is a repo at https://github.com/apache/commons-testing, but > > almost no actual code changes. > > > > The component does not appear in the sandbox, dormant or proper > > categories, and I could find no website for it. Seems to me the repo > > should at least be flagged as dormant or sandbox. > > > > Sebb > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [TESTING] What is the status of this component?
I had intended to gather various reusable JUnit rules and utilities but never got around to finishing off a first release. Since then JUnit 5 has been released. There is long term value there IMO especially with all that JUnit 5 has broken in compatibility but I've not taken the time to pursue it. Gary On Wed, Dec 20, 2023, 12:31 PM sebb wrote: > There is a repo at https://github.com/apache/commons-testing, but > almost no actual code changes. > > The component does not appear in the sandbox, dormant or proper > categories, and I could find no website for it. Seems to me the repo > should at least be flagged as dormant or sandbox. > > Sebb > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [ALL] Deploying SNAPSHOTS from GH workflows
On Wed, 20 Dec 2023 at 17:15, sebb wrote: > > Numbers is now deploying OK, as does Crypto. I cannot see anything in the GH action config that specifies that deploy should be only on the master/main branch in the original Apache repo. How is the deploy goal handled in forked repos and subsequently PRs? Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Deploying SNAPSHOTS from GH workflows
Hi Gary, On Wed, 20 Dec 2023 at 14:57, Gary Gregory wrote: > > Also FYI, over at Log4j, we (Volkan and Piotr are the drivers) have been > creating releases from GitHub. I'm not sure we need to go this far here, > but there might be tidbits there that may prove useful. Thanks for mentioning it. I think we could put all our scripts together and create something better without reinventing the wheel in each project. For example: * We all receive Dependabot PRs. Volkan did a tremendous amount of work to find a way to merge them automatically (there are GHA permissions everywhere that make it a complex operation, especially if we want to keep the Github token's permissions to a minimum). Commons could reuse that. * At Log4j we use a Beanshell script to create bin and src archives. Personally I find the results acceptable, but somehow lacking (e.g. it fails in Git worktrees). For this task the `commons-release-plugin` together with the `maven-assembly-plugin` and a list of files from the `maven-scm-plugin` could be a better choice. * If we were to start publishing VEX files, a common Github Actions bot could help inter-project coordination. For example if a `commons-compress` dependency publishes a CVE (let's say `snappy-java` to make it real), the bot could open an issue in `commons-compress`. After the Commons team analyses the issue with a justification, the bot could open an issue with `log4j-core` (which uses `commons-compress`) and attach the analysis performed by the Commons team, thus greatly simplifying the process. Piotr - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[TESTING] What is the status of this component?
There is a repo at https://github.com/apache/commons-testing, but almost no actual code changes. The component does not appear in the sandbox, dormant or proper categories, and I could find no website for it. Seems to me the repo should at least be flagged as dormant or sandbox. Sebb - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Deploying SNAPSHOTS from GH workflows
Numbers is now deploying OK, as does Crypto. Jira issue created: https://issues.apache.org/jira/browse/INFRA-25299 On Wed, 20 Dec 2023 at 13:56, Gary Gregory wrote: > > Also FYI, over at Log4j, we (Volkan and Piotr are the drivers) have been > creating releases from GitHub. I'm not sure we need to go this far here, > but there might be tidbits there that may prove useful. > > Gary > > On Wed, Dec 20, 2023, 8:25 AM sebb wrote: > > > On Tue, 19 Dec 2023 at 16:03, Gary Gregory wrote: > > > > > > I think it would be a nice-to-have feature for all active components, > > > allowing us to achieve parity with what used to happen with Jenkins > > (which > > > I never used and rarely pay attention to). When can then drop all Jenkins > > > build and free up those resources. > > > > Agreed. > > > > Infra would be OK with a single Jira for all the components that need > > access to the secrets. > > There was an issue with the deploy for Numbers - the BOM module failed > > because it needs a GPG secret key. > > I think we should resolve that before going ahead with any other requests. > > > > > Gary > > > > > > On Tue, Dec 19, 2023, 5:41 AM sebb wrote: > > > > > > > Crypto now has a workflow [4] that deploys a SNAPSHOT version. > > > > > > > > I don't know if we want to do this for all components, but if so, the > > > > process is: > > > > - raise INFRA Jira to request access to the secrets that hold the > > > > credentials [1] > > > > - use the java-settings action to create a settings.xml which > > > > references the variables holding the credentials [2] > > > > - pass the secrets as environment variables in the job-step that needs > > > > them [3] (Note:: we don't need the GPG variable) > > > > > > > > The Crypto workflow is rather complicated because it needs to build > > > > the code on several different OSes and then piece the bits together. > > > > Other components will be much simpler. > > > > > > > > Are there any other components that would benefit from/need snapshots? > > > > > > > > Sebb > > > > [1] e.g. https://issues.apache.org/jira/browse/INFRA-25296 > > > > [2] https://github.com/actions/setup-java#maven-options > > > > [3] > > > > > > https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#yaml-example > > > > [4] > > > > > > https://github.com/apache/commons-crypto/blob/master/.github/workflows/maven_crosstest.yml > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [NUMBERS] GH deploy snapshot test
On Wed, 20 Dec 2023 at 16:16, Alex Herbert wrote: > > On Wed, 20 Dec 2023 at 13:19, sebb wrote: > > > > On Tue, 19 Dec 2023 at 16:08, Alex Herbert wrote: > > > > > > Thanks Sebb, > > > > > > Note that previously the GH action was running the default goal: > > > 'clean verify javadoc:javadoc'. > > > > > > Since we now need to specify the 'deploy' goal as well the above > > > defaults can be switched in for your additions when Infra have created > > > the credentials. > > > > I added javadoc:javadoc to the goals, but I left out the verify goal > > as it should be part of deploy. > > > > The build mostly succeeded, but the BOM module failed, as it requires > > a GPG secret key. > > Is that needed for SNAPSHOT builds? > > TLDR; No. Try '-Dgpg.skip'. Thanks, now builds OK. > The BOM module is a bit of a fudge to create a minimal BOM. It would > be nice if this has a dedicated plugin to build a bom with some more > control over build and deploy. As it is I had to do a lot of Maven > config to get it to work. > > It looks like the GPG profiles are being activated by presence/absence > of the gpg.skip property. Since this is for a snapshot deployment it > should work if you update the maven goal to include '-Dgpg.skip'. > > Alex > > > > > > > Alex > > > > > > On Tue, 19 Dec 2023 at 14:29, sebb wrote: > > > > > > > > Created https://issues.apache.org/jira/browse/INFRA-25297 to get > > > > access to credentials > > > > > > > > Added code to maven.yml to deploy the snapshot (needs to be enabled > > > > when creds are granted) > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [NUMBERS] GH deploy snapshot test
On Wed, 20 Dec 2023 at 13:19, sebb wrote: > > On Tue, 19 Dec 2023 at 16:08, Alex Herbert wrote: > > > > Thanks Sebb, > > > > Note that previously the GH action was running the default goal: > > 'clean verify javadoc:javadoc'. > > > > Since we now need to specify the 'deploy' goal as well the above > > defaults can be switched in for your additions when Infra have created > > the credentials. > > I added javadoc:javadoc to the goals, but I left out the verify goal > as it should be part of deploy. > > The build mostly succeeded, but the BOM module failed, as it requires > a GPG secret key. > Is that needed for SNAPSHOT builds? TLDR; No. Try '-Dgpg.skip'. The BOM module is a bit of a fudge to create a minimal BOM. It would be nice if this has a dedicated plugin to build a bom with some more control over build and deploy. As it is I had to do a lot of Maven config to get it to work. It looks like the GPG profiles are being activated by presence/absence of the gpg.skip property. Since this is for a snapshot deployment it should work if you update the maven goal to include '-Dgpg.skip'. Alex > > > Alex > > > > On Tue, 19 Dec 2023 at 14:29, sebb wrote: > > > > > > Created https://issues.apache.org/jira/browse/INFRA-25297 to get > > > access to credentials > > > > > > Added code to maven.yml to deploy the snapshot (needs to be enabled > > > when creds are granted) > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Deploying SNAPSHOTS from GH workflows
Also FYI, over at Log4j, we (Volkan and Piotr are the drivers) have been creating releases from GitHub. I'm not sure we need to go this far here, but there might be tidbits there that may prove useful. Gary On Wed, Dec 20, 2023, 8:25 AM sebb wrote: > On Tue, 19 Dec 2023 at 16:03, Gary Gregory wrote: > > > > I think it would be a nice-to-have feature for all active components, > > allowing us to achieve parity with what used to happen with Jenkins > (which > > I never used and rarely pay attention to). When can then drop all Jenkins > > build and free up those resources. > > Agreed. > > Infra would be OK with a single Jira for all the components that need > access to the secrets. > There was an issue with the deploy for Numbers - the BOM module failed > because it needs a GPG secret key. > I think we should resolve that before going ahead with any other requests. > > > Gary > > > > On Tue, Dec 19, 2023, 5:41 AM sebb wrote: > > > > > Crypto now has a workflow [4] that deploys a SNAPSHOT version. > > > > > > I don't know if we want to do this for all components, but if so, the > > > process is: > > > - raise INFRA Jira to request access to the secrets that hold the > > > credentials [1] > > > - use the java-settings action to create a settings.xml which > > > references the variables holding the credentials [2] > > > - pass the secrets as environment variables in the job-step that needs > > > them [3] (Note:: we don't need the GPG variable) > > > > > > The Crypto workflow is rather complicated because it needs to build > > > the code on several different OSes and then piece the bits together. > > > Other components will be much simpler. > > > > > > Are there any other components that would benefit from/need snapshots? > > > > > > Sebb > > > [1] e.g. https://issues.apache.org/jira/browse/INFRA-25296 > > > [2] https://github.com/actions/setup-java#maven-options > > > [3] > > > > https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#yaml-example > > > [4] > > > > https://github.com/apache/commons-crypto/blob/master/.github/workflows/maven_crosstest.yml > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [ALL] Deploying SNAPSHOTS from GH workflows
On Tue, 19 Dec 2023 at 16:03, Gary Gregory wrote: > > I think it would be a nice-to-have feature for all active components, > allowing us to achieve parity with what used to happen with Jenkins (which > I never used and rarely pay attention to). When can then drop all Jenkins > build and free up those resources. Agreed. Infra would be OK with a single Jira for all the components that need access to the secrets. There was an issue with the deploy for Numbers - the BOM module failed because it needs a GPG secret key. I think we should resolve that before going ahead with any other requests. > Gary > > On Tue, Dec 19, 2023, 5:41 AM sebb wrote: > > > Crypto now has a workflow [4] that deploys a SNAPSHOT version. > > > > I don't know if we want to do this for all components, but if so, the > > process is: > > - raise INFRA Jira to request access to the secrets that hold the > > credentials [1] > > - use the java-settings action to create a settings.xml which > > references the variables holding the credentials [2] > > - pass the secrets as environment variables in the job-step that needs > > them [3] (Note:: we don't need the GPG variable) > > > > The Crypto workflow is rather complicated because it needs to build > > the code on several different OSes and then piece the bits together. > > Other components will be much simpler. > > > > Are there any other components that would benefit from/need snapshots? > > > > Sebb > > [1] e.g. https://issues.apache.org/jira/browse/INFRA-25296 > > [2] https://github.com/actions/setup-java#maven-options > > [3] > > https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#yaml-example > > [4] > > https://github.com/apache/commons-crypto/blob/master/.github/workflows/maven_crosstest.yml > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [NUMBERS] GH deploy snapshot test
On Tue, 19 Dec 2023 at 16:08, Alex Herbert wrote: > > Thanks Sebb, > > Note that previously the GH action was running the default goal: > 'clean verify javadoc:javadoc'. > > Since we now need to specify the 'deploy' goal as well the above > defaults can be switched in for your additions when Infra have created > the credentials. I added javadoc:javadoc to the goals, but I left out the verify goal as it should be part of deploy. The build mostly succeeded, but the BOM module failed, as it requires a GPG secret key. Is that needed for SNAPSHOT builds? > Alex > > On Tue, 19 Dec 2023 at 14:29, sebb wrote: > > > > Created https://issues.apache.org/jira/browse/INFRA-25297 to get > > access to credentials > > > > Added code to maven.yml to deploy the snapshot (needs to be enabled > > when creds are granted) > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
