Bump version to 1.0.2 and update JUnit dependency to 6.1.2

[haroon-sheikh]

This pull request updates the Java plugin for Gauge to a new minor version and bumps a JUnit dependency. The changes are primarily focused on version management to ensure compatibility and access to the latest features and fixes.

Version updates:

• Updated the plugin version from 1.0.1 to 1.1.0 in both java.json and pom.xml to reflect a new release. [1] [2]

Dependency updates:

• Upgraded the junit-bom dependency version from 6.1.1 to 6.1.2 in pom.xml for improved stability and bug fixes.

[gaugebot]

@haroon-sheikh Thank you for contributing to gauge-java. Your pull request has been labeled as a release candidate 🎉🎉.

Merging this PR will trigger a release.

Please bump up the version as part of this PR.

Instructions to bump the version can found at CONTRIBUTING.md

If the CONTRIBUTING.md file does not exist or does not include instructions about bumping up the version, please looks previous commits in git history to see what changes need to be done.

[chadlwilson]

There's only dependency bumps right, so 1.1.0 would be misleading? 1.0.2 more appropriate?

v1.0.1...master

[haroon-sheikh]

There's only dependency bumps right, so 1.1.0 would be misleading? 1.0.2 more appropriate?

v1.0.1...master

I'll update 1.0.2 for now. There's been a lot of dependency bumps and changes in master over the last 8 months. From now on, lets try to cut a release every quarter at least.

[chadlwilson]

Not disagreeing with releasing quarterly, but most changes are test dependencies and don't think any runtime deps were for security. Not really any substantial change in there.

The bigger problem than these deps with gauge, I feel, is goiang in most repos (including this one) which basically means security noise demands monthly releases to clear even govulncheck scans due to the static compiles - just to get rid of noise.

Seems its not sustainable as it is without better automation than we have here already. Having to manually bump a version number, add a label and raise a PR across dozens of repos quarterly is not something that I'm able to do personally. And that many repos don't have the automation working (probably due to migration issues from other orgs) so require their own manual API calls. I'd prefer we had version auto-bumps somehow (like release-please) but don't have the time/energy to set that up. The whole gaugebot and label approach is a complex custom version of what release-please (and probably others) can do.

[chadlwilson]

If you do feel enthusiastic (and we get a bit of input from others) I do have owner perms on the main org (not gauge-contrib I don't think) so do have a bit more ability to support improving things than before, if one of us gets enthusiastic.

My main interest would be to improve supply chain security practices by removing long lived tokens (like gaugebot uses) as much as possible, make releases immutable etc.

[zabil]

Created a new issue getgauge/taiko#2788 to try out a better release process in one repo and hopefully roll it out across gauge.