Checkstyle 10.0, Java 11, Maven Checkstyle Plugin, and toolchain support
Devs, I'm researching the possibility of committing a patch to the Maven Checkstyle Plugn to support toolchains. This support would be critical with Checkstyle 10.0 now requiring Java 11. I did not see any work pending on this in the JIRA board, yet. I'm not aware of any pending work from the Checkstyle team. Any awareness of work would be appreciated, before I begin. Thanks! Tim -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitHub | Linked In | MeWe | PGP OpenPGP_signature Description: OpenPGP digital signature
Re: Using .git-blame-ignore-revs with reordered lines
On 1/24/24 6:31 AM, Konrad Windszus wrote: Ping, does anyone have any input on this? Would be much appreciated, Thanks, Konrad On 8. Jan 2024, at 19:16, Konrad Windszus wrote: Hi, According to https://maven.apache.org/pom/maven/#the-format-profile the git commits created through applying the spotless formatting should be ignored via a .git-blame-ignore-revs file. This file is automatically evaluated by GitHub blame view. This doesn’t work well if the formatting also does some reordering of lines (most prominently through https://github.com/diffplug/spotless/tree/main/plugin-maven#sortpom). An example can be found in https://github.com/apache/sling-parent/blame/master/sling-parent/pom.xml#L270 which obviously shows a non-related commit in line 270 due to the ignored reordering commit (this is a different ASF projects but follows the same approach as Maven). The same may happen with reordering of lines in Java. I am wondering if there is a better approach, or we should rather not generally recommend to add those reformatting commits to .git-blame-ignore-revs. WDYT? Konrad Konrad, I don't think I ever paid attention to this Maven workflow and tooling, deferring mostly to Checkstyle and pipeline tooling for Java. Editing a file with SHAs adds friction: Who edits it? If it's not edited, what is the need/requirement to edit it after the fact? I see a separate file that needs manual action as process friction subject to all sorts of user issues. IMHO. I'm aware that 'git blame' has "detect copy-move" switches, for example: -C[] In addition to -M, detect lines moved or copied from other files that were modified in the same commit. This is useful when you reorganize your program and move code around across files. When this option is given twice, the command additionally looks for copies from other files in the commit that creates the file. When this option is given three times, the command additionally looks for copies from other files in any commit. is optional but it is the lower bound on the number of alphanumeric characters that Git must detect as moving/copying between files for it to associate those lines with the parent commit. And the default value is 40. If there are more than one -C options given, the argument of the last -C will take effect. Is it possible that this could be leveraged somehow? Certainly, pipelines could be scripted to use these features of Git. -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
Re: User friendly release notes
On 3/13/24 7:05 PM, Andres Almiray wrote: First, I’d suggest following a commit message convention. You may define your own or follow an existing one such as https://www.conventionalcommits.org/en/v1.0.0/ +1 Next, use a tool that can read, parse, and format commit messages. You’ll find plenty of options out there. I can pitch https://jreleaser.org/ 😉 Not familiar with jreleaser. I will say that mixed technology pipelines have worked well for us, with Node managing many aspects of versioning and providing previous/next versions to the Maven Release Plugin via the pipeline environment. Cheers Andres Sent from my primitive tricorder On 13 Mar 2024, at 23:58, Slawomir Jaranowski wrote: Hi, Today's facts: - We manage our issues in jira and all officala release notes are also in jira. - We sent an email in text format to announce mailing list. - In project documentation we don't have a release notes But as we see in: https://lists.apache.org/thread/pzd36lo6rtfn7c5s0x60xbj296xt1mvf today it is not a user-friendly way. ... snip Any other propositions, ideas ? -- Sławomir Jaranowski -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
maven.repo.local cf. localRepository
I help maintain Maven tooling for To Be Continuous, a GitLab CI/CD catalog of pluggable pipeline configurations. There is some discussion on the use of the JVM property, `-Dmaven.repo.local=path' and the note on "Configuring your Local Repository" (see [1]). Initially I was going to post to the user list, but being a development question against the internals of Maven, I thought this a better forum. There is an admonition on the referenced page: /Note: The local repository _must_ be an absolute path./ (emphasis mine) Is this specifically noted for the use of the settings.localRepository only or does the note extend to the use of the JVM property? I searched the GitHub repo for a examples and found numerous uses of relative paths, e.g., `../.repository` and others. Seeking clarification as I could not immediately determine the internal use of `maven.repo.local' property when set. Thanks! Tim [1] https://maven.apache.org/guides/mini/guide-configuring-maven.html#configuring-your-local-repository -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
Re: maven.repo.local cf. localRepository
On 7/14/24 10:04 AM, Romain Manni-Bucau wrote: Hi Agree it should be absolute but there is no technical constraint - ultimately it must be known how it resolves. I know on ci it is common to use a relative path to avoid ci specific internal path issues accross os/workers. I concur. But as I note below, I think most CI environments can address this. Le dim. 14 juil. 2024 à 09:52, Tamás Cservenák a écrit : ... snip ... As it is evaluated at maven boot and relative would be calculated against CWD based on invocation (plus, -f modifies it). As Manni-Bucau noted above, CI workers/runners add some context to consider. In the case of GitLab, the CI context is populated with many variables that can aid in easily resolving or creating an absolute path. For example, GitLab's CI_* variables are populated and include the CI_PROJECT_DIR variable that can be used to "pin" the absolute path. I think this is enough to provide the team more information as we drive a path forward. Thanks for the detailed answer Tamás, and the additional context clarity Manni-Bacau. Hth T On Sun, Jul 14, 2024, 03:10 Timothy Stone wrote: I help maintain Maven tooling for To Be Continuous, a GitLab CI/CD catalog of pluggable pipeline configurations. There is some discussion on the use of the JVM property, `-Dmaven.repo.local=path' and the note on "Configuring your Local Repository" (see [1]). Initially I was going to post to the user list, but being a development question against the internals of Maven, I thought this a better forum. There is an admonition on the referenced page: /Note: The local repository _must_ be an absolute path./ (emphasis mine) Is this specifically noted for the use of the settings.localRepository only or does the note extend to the use of the JVM property? I searched the GitHub repo for a examples and found numerous uses of relative paths, e.g., `../.repository` and others. Seeking clarification as I could not immediately determine the internal use of `maven.repo.local' property when set. Thanks! Tim [1] https://maven.apache.org/guides/mini/guide-configuring-maven.html#configuring-your-local-repository -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
Proxy and Aether resolver configuration guide
Devs, Reaching out here as a contributor to To Be Continuous's Maven CI/CD templates. An issue was opened more than a year ago about the changes in Maven 3.9.x and the "configuration of proxy settings via System Properties" being "no longer supported." See https://gitlab.com/to-be-continuous/maven/-/issues/39 In the user list, something adjacent was raised, and I think there is something about the documentation that is creating confusion. Specifically, `aether.transport.apache.useSystemProperties' suggests that a) using `http.proxy` JVM settings is no longer supported, or b) not recommended over the "documented ways of configuration": If enabled, underlying Apache HttpClient will use system properties as well to configure itself (typically used to set up HTTP Proxy via Java system properties). See HttpClientBuilder for used properties. This mode is not recommended, better use documented ways of configuration instead. But the "documented ways of configuration" are then just assumed to be known by the reader. So a) what are the "documented ways of configuration"? or b) are `http.proxy' settings indeed disabled in "auto"/"native" mode or is this all just a misreading of the documentation and the assumption here is settings:proxies configuration. Thanks! Tim -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Proxy and Aether resolver configuration guide
On 8/28/24 5:42 AM, Tamás Cservenák wrote: Howdy, the "documented ways" are assumed to be as you say: settings.xml https://maven.apache.org/settings.html The properties are not recommended as that assumes per JVM configuration and may cause issues like unexpected behaviour (the message is simply "be explicit in settings.xml instead..."). For the list of supported properties (this is ASF httpClient specific, and WHEN ENABLED) are these: https://javadoc.io/static/org.apache.httpcomponents/httpclient/4.5.14/org/apache/http/impl/client/HttpClientBuilder.html So a) "documented way of [maven] configuration is settings.xml" b) yes, sensing Java System Properties are by default disabled, you must explicitly enable that if you need it Thanks T Thank you! for the clarification. I take this back to the TBC team. Tim On Wed, Aug 28, 2024 at 3:06 AM Timothy Stone wrote: Devs, Reaching out here as a contributor to To Be Continuous's Maven CI/CD templates. An issue was opened more than a year ago about the changes in Maven 3.9.x and the "configuration of proxy settings via System Properties" being "no longer supported." See https://gitlab.com/to-be-continuous/maven/-/issues/39 In the user list, something adjacent was raised, and I think there is something about the documentation that is creating confusion. Specifically, `aether.transport.apache.useSystemProperties' suggests that a) using `http.proxy` JVM settings is no longer supported, or b) not recommended over the "documented ways of configuration": If enabled, underlying Apache HttpClient will use system properties as well to configure itself (typically used to set up HTTP Proxy via Java system properties). See HttpClientBuilder for used properties. This mode is not recommended, better use documented ways of configuration instead. But the "documented ways of configuration" are then just assumed to be known by the reader. So a) what are the "documented ways of configuration"? or b) are `http.proxy' settings indeed disabled in "auto"/"native" mode or is this all just a misreading of the documentation and the assumption here is settings:proxies configuration. Thanks! Tim -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Proxy and Aether resolver configuration guide
Tangentially related: Is there a CLI method of activating a proxy by id, i.e., similar to `-P|--activate-profiles` in a POM? Thanks! Tim On 8/28/24 8:04 AM, Timothy Stone wrote: On 8/28/24 5:42 AM, Tamás Cservenák wrote: Howdy, the "documented ways" are assumed to be as you say: settings.xml https://maven.apache.org/settings.html The properties are not recommended as that assumes per JVM configuration and may cause issues like unexpected behaviour (the message is simply "be explicit in settings.xml instead..."). For the list of supported properties (this is ASF httpClient specific, and WHEN ENABLED) are these: https://javadoc.io/static/org.apache.httpcomponents/httpclient/4.5.14/ org/apache/http/impl/client/HttpClientBuilder.html So a) "documented way of [maven] configuration is settings.xml" b) yes, sensing Java System Properties are by default disabled, you must explicitly enable that if you need it Thanks T Thank you! for the clarification. I take this back to the TBC team. Tim On Wed, Aug 28, 2024 at 3:06 AM Timothy Stone wrote: Devs, Reaching out here as a contributor to To Be Continuous's Maven CI/CD templates. An issue was opened more than a year ago about the changes in Maven 3.9.x and the "configuration of proxy settings via System Properties" being "no longer supported." See https://gitlab.com/to-be-continuous/maven/-/issues/39 In the user list, something adjacent was raised, and I think there is something about the documentation that is creating confusion. Specifically, `aether.transport.apache.useSystemProperties' suggests that a) using `http.proxy` JVM settings is no longer supported, or b) not recommended over the "documented ways of configuration": If enabled, underlying Apache HttpClient will use system properties as well to configure itself (typically used to set up HTTP Proxy via Java system properties). See HttpClientBuilder for used properties. This mode is not recommended, better use documented ways of configuration instead. But the "documented ways of configuration" are then just assumed to be known by the reader. So a) what are the "documented ways of configuration"? or b) are `http.proxy' settings indeed disabled in "auto"/"native" mode or is this all just a misreading of the documentation and the assumption here is settings:proxies configuration. Thanks! Tim -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D&D Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [DISCUSS] Enable GitHub issues and GitHub discussions
On 10/24/24 11:10 AM, Giovanni van der Schelde wrote: ...snip... 0 / -1 While I'm not most familiar with ticket management on bigger open source projects on GitHub, I can imagine it might be a bit more tricky to relate issues like you can with tools like Jira. Features like 'related to', 'duplicate off', 'depends on' are harder to track. You might need to use the 'Projects' feature for that, but that seems somewhat limited. You'd have to scroll through an issue to notice other issues or PR's reference a specific (especially older) issue you are working on. GitLab supports this level of issue management. 🙂 Sorry, just a HUGE fan of GitLab and a contributor to its Maven support. (Apologies to Giovanni, I sent my reply to you and not the list.) -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Architect, Wargamer, Home Brewer, and 🤓 Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [DISCUSS] Enable GitHub issues and GitHub discussions
On 10/22/24 2:44 PM, Delany wrote: There was mention of GitHub's terms of service. Its not the only game in town though - what about Gitlab or even Gitea? I'm sure they'd appreciate being able to host project code like Maven. Just a thought. +1 I'm a HUGE fan of GitLab (and "Notable Hero" having contributed to GitLab's work on pipeline vulnerability scanning for Maven). GitLab Ultimate is free to OSS projects as well. I don't work for GitLab, but lest this reply become a sales pitch for GitLab, I'll only add that GitLab can mirror to GitHub very easily. (see down thread). I also find that the platform has many features of JIRA for project milestones, sprints, labels, and much more, including an integrated robust CI/CD platform (and tooling projects like To Be Continuous). Thanks! Tim -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Architect, Wargamer, Home Brewer, and 🤓 Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Time to ditch Slack?
On 1/7/25 8:25 AM, Elliotte Rusty Harold wrote: All third party proprietary systems not owned by the Apache Project come with risks, Github and Jira included. However Slack strikes me as particularly bad. I'll weigh in as a lurker (largely a contributor to Maven through third party integration tooling and support). 1. It breaks the web architecture with unstable URLs. Concur. I have found this to be surprising at times. > 2. The privacy practices are unclear, unstable, and user hostile. ... snip ... Where I've worked and Slack was introduced, it was brought on-prem and hosted. All comms never left the "enterprise." It's such that after a 5 year absence one employer's Slack still had all my comms, my account was reactivated and every comm, some almost nine years old, was there. Many ancillary issues come with this kind of Slack hosting, I'll enumerate if anyone wants them, but most are common sense. 3. Slack is just ugly and hard to use compared to email or Jira. OK, #3 is IMHO but #1 is bad and and #2 is awful. It's also painful to have to check multiple locations to figure out what's going on. IMHO, Slack is just IRC with a polished client (originally Electron as I recall). IFAIK, Slack even directly provides gateways to the big IRC networks... or did. I still harbor some fire about how IRC got overshadowed by a slick client that hides the more esoteric operations of IRC from the masses. I've used Slack when I'm paid to, but otherwise I avoid it these days, including in open source development. It's just too painful and it's been getting worse over time. Concur. I'd like to propose that we simply stop using Slack for project wide communications. Discussion about Maven related things can take place in the mailing list or the issue tracker. Between that, communication is well covered. Thoughts? See above. But concur. GitHub, GitLab, et al., have some powerful tools for communications inline with merge requests like Reviews and Suggestions (that can be applied directly in the MR) and all tied to the originating Issue. I like this because it keeps the record of the development thread to merge. ...snip... -- Timothy Stone = Some call me ... Tim. Husband, Father, Blogger, OSS, Architect, Wargamer, Home Brewer, and 🤓 Find me on GitLab | GitHub | Linked In | MeWe | GnuPG OpenPGP_signature.asc Description: OpenPGP digital signature
