Nope, 3.5 isn't dead
Maybe it should be, but I wanted to drop a note that about a month after December's decision to require Maven 3.6.3, I shifted onto an open source project that's been around for 10+ years, is actively backed by two large tech companies, and still depends on Maven 3.5.x in the continuous integration build. Bleah. I've been trying to upgrade it, but so far without success. 3.5 seems baked pretty deeply into the Docker images or some other part of the CI infrastructure that isn't easy to change. This project could well be using Maven 3.5 for years to come. It's even possible we will rewrite the whole codebase in C++ before we manage to get past Maven 3.5. (I wish that was hyperbole. It's not.) I think we tend to overestimate how fast the installed base updates, whether it's JDKs (I got a bug report from someone still using Java 7 yesterday), Maven versions, operating systems, or pretty much anything else. None of us see more than a small fraction of the projects out there. It is very easy to look at that small fraction and draw conclusions that are falsified with a larger or different sample. I didn't know about this dependence on Maven 3.5 until I changed projects in January. I haven't seen 3.3 lately, but I wouldn't be surprised if it's still in use in multiple organizations, perhaps because it's what's installed by default in some old Linux distro that should also be retired but isn't. Absence of evidence is not evidence of absence, including when considering which Maven versions developers actively use. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Like a couple of other folks 90% of my usage is dependency:analyze and dependency:tree. Other goals I barely notice. On Thu, Mar 21, 2024 at 12:06 PM Tamás Cservenák wrote: > > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: User friendly release notes
On Wed, Mar 13, 2024 at 7:07 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/ > Please don't. I've seen this on too many projects, and it's a huge hassle for very little benefit. It would take significantly less time to manually write release notes for each release than to micro-format each and every commit message. Conventional commits is a huge time sink and way too much added friction. It discourages developers and decreases velocity with endless nit picking over formatting details that just don't matter. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release maven-filtering-3.3.2 and maven-remote-resources-plugin-3.2.0
I don't see any blockers with either of these. However, the maven-remote-resources-plugin repo is currently broken because it depends on the new maven-filtering. I would prefer to vote on and release maven-filtering-3.3.2 and only then vote on and release maven-remote-resources-plugin- 3.2.0. On Sat, Mar 2, 2024 at 9:48 AM Guillaume Nodet wrote: > > I've staged release candidates for maven-filtering-3.3.2 and > maven-remote-resources-plugin-3.2.0 at > https://repository.apache.org/content/repositories/maven-2067 > > JIRA release notes: > https://issues.apache.org/jira/projects/MSHARED/versions/12353084 > https://issues.apache.org/jira/projects/MRRESOURCES/versions/12353591 > > Note that m-remote-resources-p depends on the release of > maven-filtering, hence the single vote. > > Please review and vote ! > > -- > > Guillaume Nodet > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Require Java 17 for Maven 4
On Wed, Feb 28, 2024 at 2:31 AM Benjamin Marwell wrote: > Please refrain from starting discussions in this thread, but do > include a reasoning on downvotes and feel free to start a new > discussion on the mailing list, or comment on the existing ones. -1 Requiring reasons for downvotes but not upvotes puts a finger on the scale. :-) -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
On Mon, Feb 26, 2024 at 7:24 PM Benjamin Marwell wrote: > > > 1. The Java version required by the project being built. That is, the > byte code and API level of the project. > > 2. The Java version used to compile the project. > > 3. The Java version used to run Maven. > > 4. The Java version used to compile and build Maven itself. > > > For #1, it is mandatory to support Java 8. > > You can compile Java 8 bytecode with a Java 8 JDK from a Maven running > Java 17+ using toolchains > or with the -release flag from any version 9+. > > > For #2, reproducible builds mean we have to be able to support what > > customers are using and that can be anything from Java 8 - 21. It is > > not sufficient to say Java 21 can compile to Java 8 since that does > > not produce the same byte code as compiling with Java 8. > > That is the point. > If you built the project with JDK 21 using the -release=8, you can get > the same (reproducible) output with a similar OS and JDK 21. > No, that's not the point. You are claiming that #1 and #2 are the same. I do not believe they are the same. Compiling for Java 8 with Java 17 -release 8 is not the same as compiling with javac from JDK 8. They do not produce the same byte code. There is a need to compile *with* JDK 8, not just compile *for* JDK 8. Toolchains support using JDK 8 to compile even though JDK 17 is executing Maven, which does handle this. Unfortunately toolchains are poorly designed, badly documented, and not widely understood within the community. I'm trying to improve some of the docs for toolchains, but that only goes so far. There's a fundamental problem that toolchains are incompatible with a hermetic, one click build. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
d as LTS, and "supported" for up to 3 or > 5 years (depending on needs) with only security or critical bug fixes, this > means that any new feature won't be backported to the 3.10.x branch, > something like supporting a new JDK version (like Java 25) will be added to > Maven 4. > > Why Java 17 and not Java 21? To be conservative and have a wider audience, > this should not be taken as a set-in-stone version, and if in 2 or 3 years > the Java ecosystem has moved fast enough, then a Maven version that targets > Java 21 or Java 25 should be possible in something like Maven 4.2 (or > whatever version is released to that date), and when the current 3.10.x > version "expires" in 3 or 5 years, mark a new LTS version rinse, and repeat. > > *Advantages of Maven 3.10.x (Targeting Java 8):* > >1. > >*Stability and Compatibility:* Maven 3.10.x will provide stability and >compatibility for projects still reliant on Java 8. Many enterprises and >legacy projects continue to utilize Java 8 due to its stability and >extensive support. By maintaining a Maven version specifically for Java 8, >these projects can benefit from ongoing support without being forced to >migrate to newer Java versions prematurely. >2. > >*Extended Support Period:* As an LTS version, Maven 3.10.x will receive >extended support and bug fixes, ensuring reliability for projects in >production environments. This extended support period is crucial for >enterprises with long-term projects that require stability and minimal >disruption. >3. > >*Security Patches:* Security vulnerabilities are a significant concern >for software projects. With an LTS version like Maven 3.10.x, users can >expect timely security patches to address any potential vulnerabilities, >thus enhancing the overall security posture of their projects. >4. > >*Maintaining Legacy Codebases:* Many organizations have substantial >investments in legacy codebases built on Java 8. Maven 3.10.x enables these >organizations to continue maintaining and evolving their existing projects >without the need for an immediate migration to newer Java versions, >reducing migration overheads and risks. > > *Advantages of Maven 4.0 (Targeting Java 17):* > >1. > >*Compatibility with Latest Java Features:* Maven 4.0 targeting Java 17 >will empower developers to leverage the latest features and enhancements >introduced in newer Java versions. This compatibility fosters innovation >and enables developers to build modern, high-performance applications. >2. > >*Performance Improvements:* Newer Java versions often come with >performance optimizations and improvements. By targeting Java 17, Maven 4.0 >can take advantage of these enhancements, resulting in faster builds and >improved developer productivity. >3. > >*Support for Modern Development Practices:* Maven 4.0 can incorporate >support for modern development practices, tools, and frameworks that are >aligned with Java 17 and beyond. This includes improved support for >modularization, enhanced APIs, and better integration with contemporary >development ecosystems. >4. > >*Community Engagement and Contribution:* Introducing Maven 4.0 targeting >Java 17 will attract developers interested in exploring the latest >technologies and contributing to the Maven ecosystem. This increased >community engagement can lead to faster innovation, broader platform >support, and overall ecosystem growth. > > *Conclusion:* In conclusion, the proposal is to introduce LTS versions of > Maven, namely Maven 3.10.x targeting Java 8 and Maven 4.0 targeting Java > 17, presents a balanced approach to cater to the diverse needs of the Java > development community. By providing stability, compatibility, and extended > support for legacy projects with Maven 3.10.x, and enabling compatibility > with the latest Java features and development practices with Maven 4.0, > this versioning strategy ensures that both current and future projects can > thrive within the Maven ecosystem. > > > Please, maintain a constructive argument, since we need to move forward. > Thank you! > > > Best regards. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Hand ups - new releases in next week
Thanks. This is helpful. On Sat, Feb 24, 2024 at 1:44 PM Slawomir Jaranowski wrote: > > Hi, > > I'm going to release at the end of next week: > > 1. maven-assembly-plugin > > issues for next release: > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317220%20AND%20fixVersion%20%3D%2012353243%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC > open issues: https://issues.apache.org/jira/projects/MASSEMBLY > open PRs: https://github.com/apache/maven-compiler-plugin/pulls > > 2. plexus-compiler > > fixes: > https://github.com/codehaus-plexus/plexus-compiler/compare/plexus-compiler-2.14.2...refs/heads/master > open issues: https://github.com/codehaus-plexus/plexus-compiler/issues > open PRs in: https://github.com/codehaus-plexus/plexus-compiler/pulls > > 2. maven-compiler-plugin > > issues for next release: > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317225%20AND%20fixVersion%20%3D%2012354079%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC > open issues: https://issues.apache.org/jira/projects/MCOMPILER > open PRs: https://github.com/apache/maven-compiler-plugin/pulls > > 3. maven-jar-plugin > > issues for next release: > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317526%20AND%20fixVersion%20%3D%2012352303%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC > open issues: https://issues.apache.org/jira/projects/MJAR > open PRs: https://github.com/apache/maven-jar-plugin/pulls > > So any help will be appreciated with: > > - check or comments opened issues - maybe some more can be fixed > - review opened PR - many times review from contributors and users are very > valuable > - check documentation - sometime we can fix a simple misspells, broken > links, clarify a more bit and so on > > All contributors are welcome - old and new ones with helping on preparing > the new release. > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
Yes, with var you still get type checks, unlike in Python. But I have wasted so much time debugging Python code simply because the type of a local variable wasn't right there in the declaration that I remain unconvinced var was ever a good idea. I have been convinced by experience that implicitly typed local variables dramatically reduce debugging speed. This isn't something I believed two years ago. Back then I mostly didn't think about it. But since then I have worked a lot with implicit typing, and it is painful. IDEs are not a full solution. They're better in Java than Python, I admit, but I spend more time reading code in tools like Github and Critique than in IDEs. I don't think banning var goes against the community in any way. It's simply another style choice for improved readability and maintainability, like everything spotless and checkstyle currently do. On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau wrote: > > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold a > écrit : > > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau > > wrote: > > > > > > @Elliotte while you are pretty right in terms of *compile* features but > > it > > > ignores the biggest criteria for any ASF project : the community. Even if > > > silly, attracting people with Java 8 is born dead today (to illustrate it > > > just ask somebody to no more use "var" to do a PR for ex, he will start > > to > > > "pf" ;)). > > > > Going off on a tangent but I would reject any PR that showed up in my > > code review queue that used "var", regardless of JDK version. It's an > > abomination that should never have been added to Java. It prioritizes > > a trivial speed up in writing code at the cost of a significant slow > > down in reading and debugging code. Working in Python for the last > > couple of years has thoroughly convinced me that strong, explicit > > compile time types are the right way to go. I've seen what happens > > when you don't have them, and it's not fun. > > > > I assume you never used it to write that cause you don't loose compile > checks, you are not slower to read nor debug but generally faster cause > readability is increased and if you miss the 35 char long type your > preferred IDE will compensate that easily. > It is literally similar to streams or even plain old java, it depends the > habit of the coder but if we consider that we would also prevent foreach > usage. > You can also reverse it and write the exact same sentence on "not using > var", how slow it is to read such a code where half of the chars don't > bring any useful data or encourage palantir formatting to break on multiple > lines a single statement. > So IMHO this is not something right to think nor even consider. > > Ultimately the point is not "do we think it is good or not", it is > literally that if we go against the move then we go against the community - > keep in mind we should probably not be the primary citizens there - and > therefore I'm not sure the point to be at Apache if we don't care about our > community. > I'm clearly to stay there and enable people to join rather than staying > alone 10 years ago (happy anniversary java 8 ;)). > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau wrote: > > @Elliotte while you are pretty right in terms of *compile* features but it > ignores the biggest criteria for any ASF project : the community. Even if > silly, attracting people with Java 8 is born dead today (to illustrate it > just ask somebody to no more use "var" to do a PR for ex, he will start to > "pf" ;)). Going off on a tangent but I would reject any PR that showed up in my code review queue that used "var", regardless of JDK version. It's an abomination that should never have been added to Java. It prioritizes a trivial speed up in writing code at the cost of a significant slow down in reading and debugging code. Working in Python for the last couple of years has thoroughly convinced me that strong, explicit compile time types are the right way to go. I've seen what happens when you don't have them, and it's not fun. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
On Fri, Feb 23, 2024 at 12:20 AM Robert Dean wrote: > That being said, if retiring Java 8 and lower output support allows > Maven to shed technical debt and deliver improvements faster, I'd get > over my disappointment. :) Given the amount of tech debt still in Maven from Maven 2 and earlier, I don't think shifting the JDK version is likely to have any positive impact or let improvements arise any faster. In fact, the opposite is likely true. This is a variant of the xkcd 927 problem. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
; >> > I might be wrong but I understood that shipping the JRE/JVM > >> required a > >> >> > license and this is why most people don't ship with a JVM bundled. > >> But > >> >> > perhaps that has changed since the Oracle v Google/Alphabet trial. > >> >> > Hunter > >> >> > > >> >> >On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin > >> Marwell > >> >> < > >> >> > bmarw...@apache.org> wrote: > >> >> > > >> >> > FWIW, bazel changed its runtime requirement to Java 21. > >> >> > But they are shipping their own Java Runtime, so their users won't > >> >> notice. > >> >> > [1] > >> >> > > >> >> > I think they are the first build tool to do that. > >> >> > > >> >> > I say this as a FYI fact only, not implying anything. > >> >> > Make of it what you want. > >> >> > > >> >> > - Ben > >> >> > > >> >> > Am Di., 20. Feb. 2024 um 21:50 Uhr schrieb Tamás Cservenák > >> >> > : > >> >> > > > >> >> > > Howdy, > >> >> > > > >> >> > > I intentionally used "Maven" here, and not "Maven 4" as I am sure > >> the > >> >> > > majority of Maven users do not run Maven on the same Java version > >> they > >> >> > > target with their build. We do not do that either. > >> >> > > > >> >> > > Some snippets from Herve (who is the ONLY one doing reproducible > >> >> checks, > >> >> > > kudos for that) votes: > >> >> > > > >> >> > > Sun, Feb 18, 2024, 9:38 AM > >> >> > > [VOTE] Release Apache Maven Shade Plugin version 3.5.2 > >> >> > > Reproducible Build ok: reference build done with JDK 11 on *nix > >> >> > > > >> >> > > Wed, Jan 31, 2024, 5:06 AM > >> >> > > [VOTE] Release Apache Maven JLink Plugin version 3.2.0 > >> >> > > Reproducible Builds ok: reference build done on *nix with JDK 21 > >> and > >> >> > umask > >> >> > > 022 > >> >> > > > >> >> > > Mon, Jan 8, 2024, 8:29 AM > >> >> > > [VOTE] Release Maven Plugin Tools version 3.11.0 > >> >> > > Reproducible Builds ok: reference build done with JDK 8 on Windows > >> >> with > >> >> > > umask > >> >> > > > >> >> > > Mon, Dec 18, 2023, 8:59 AM > >> >> > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > >> >> > > Reproducible Builds ok: reference build done on *nix with JDK 21 > >> and > >> >> > umask > >> >> > > 022 > >> >> > > > >> >> > > Mon, Dec 18, 2023, 8:59 AM > >> >> > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > >> >> > > Reproducible Builds ok: reference build done on *nix with JDK 21 > >> and > >> >> > umask > >> >> > > 022 > >> >> > > > >> >> > > Wed, Nov 29, 2023, 8:16 AM > >> >> > > [VOTE] Apache Maven Build Cache Extension 1.1.0 > >> >> > > Reproducible Build ok: reference build done on *nix with JDK 11 > >> >> > > > >> >> > > Sun, Nov 19, 2023, 5:17 PM > >> >> > > [VOTE] Release Maven Resolver 1.9.17 > >> >> > > Reproducible Build ok: reference build done with JDK 21 on *nix > >> with > >> >> > umask > >> >> > > 022 > >> >> > > > >> >> > > Sat, Oct 21, 2023, 4:34 PM > >> >> > > VOTE] Apache Maven 4.0.0-alpha-8 release > >> >> > > Reproducible Build ok: reference build done with JDK 21 on *nix > >> with > >> >> > umask > >> >> > > 022 > >> >> > > > >> >> > > Mon, Oct 2, 2023, 9:11 AM > >> >> > > [VOTE] Release Apache Maven 3.9.5 > >> >> > > Reproducible not fully ok: reference build done with JDK 17 on *nix > >> >> and > >> >> > > umask 022 > >> >> > > > >> >> > > > >> >> > > > >> >> > > This CLEARLY shows the tendency: > >> >> > > - Michael does releases on Java 8 (on windows!), he is a known > >> >> "aligner" > >> >> > > and windows person :) > >> >> > > - Olivier used the "minimum" required Java version (for build > >> cache). > >> >> > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he > >> >> could > >> >> > > use 21 but also 8, but he shot for 11 that was EOL at the moment of > >> >> > release. > >> >> > > - The rest is 21. > >> >> > > > >> >> > > > >> >> > > > >> >> > > So, the question for those refusing anything other than Java 8 to > >> >> _run_ > >> >> > > Maven (or to revert: for those refusing to run Maven on "latest > >> LTS", > >> >> > that > >> >> > > is currently 21): > >> >> > > WHY? > >> >> > > > >> >> > > > >> >> > > Thanks > >> >> > > T > >> >> > > >> >> > - > >> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> >> > For additional commands, e-mail: dev-h...@maven.apache.org > >> >> > > >> >> > > >> >> > >> > > >> > > >> > - > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > For additional commands, e-mail: dev-h...@maven.apache.org > >> > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
On Wed, Feb 21, 2024 at 7:40 AM Hervé Boutemy wrote: > > for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have to > update our plans https://maven.apache.org/developers/compatibility-plan.html > Not sure where this comes from. There's no one EOL date for any version. It depends on the vendor. The dates on that page I spot checked don't seem to match up with Oracle's announced dates, or that of any other vendor I looked at. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.2
On Sun, Feb 18, 2024 at 8:43 AM Romain Manni-Bucau wrote: > > Hi Eliotte, > > Is the -1 only motivated by the fact there is a PR opened? That there is an unaddressed PR that looks worthy of review and has been open for months without a reply. 13 others are open. One of them is not ready for review. I haven't looked at the other 12 since, IMHO, one unreviewed PR is sufficient reason to delay a cut. > If so please consider two things: > * it is always the case for most releases (maven, asf, living projects ;)) > so not sure when it became a hard criteria but if so we should probably > think to be more open if we want to release a day It isn't necessary to finish and merge all PRs before a release, but a review is not much to ask when someone has volunteered effort to fix something. Rarely, there's an emergency push for a critical bug. Short of that, it doesn't take all that long to scan the Github queue and see if there's anything useful that got missed. In practice though I often find even simple dependabot PRs unmerged after a release is cut. I would like to get in the habit of tidying up the queue prior to a release cut. > * If you take time to review the PR you mention you will also see it just > revert a fix and that the final code should be more complex if it lands in > shade plugin a day - there are always workarounds there - so don't think we > can make it in the week so can await another round and way more time to > make it right (long story sort shade has an old bug where it mixes the same > config for different kind of rewritten sources, while it often works and > stays simple, it also makes it insanely hard to be right since you don't > know what you rewrite - a variable, a package, a class name, ...) > That's all fine, but please say this on the PR so the new contributor can address these points. It's not good for PRs to sit in limbo for years. Commenting on PRs also helps to avoid someone else who doesn't have the context you do (e.g. me) from coming along and simply merging the PR because I don't happen to notice the problems you do. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.2
-1 https://github.com/apache/maven-shade-plugin/pull/193 from an external contributor is open and unreviewed, although it seems to meet the criteria for merging if it's correct. It's helpful to triage open PRs and issues before cutting a release. On Sat, Feb 17, 2024 at 1:01 PM Hervé Boutemy wrote: > > Hi, > > We solved 6 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12352505=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-2065/ > https://repository.apache.org/content/repositories/maven-2065/org/apache/maven/plugins/maven-shade-plugin/3.5.2/maven-shade-plugin-3.5.2-source-release.zip > > Source release checksum(s): > maven-shade-plugin-3.5.2-source-release.zip sha512: > 23fcd21e6b915114efa133b1c4e46fa0b3d77874ff9d974e4bdb24940ea0ed9b7ffaf7f3d1e8a8549837cfe1de7ff2fc8ae7fc68bfc0477ea7a4b8b53e42f6f7% > > Staging site: > https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Use of jspecify in Maven
I'd prefer not. Every additional dependency we add is a liability. It's not clear we need something like this and even if we do, JSpecify is only a few months old. This is only the latest of many efforts to establish a standard for nullness annotations. I don't see why JSpecify will be the one ring to rule them all. XKCD 927 applies: https://xkcd.com/927/ Really what needs to happen here is someone needs to reboot the JSR 305 work in the JCP. I'm not sure why it failed the first time, but perhaps it can be fixed. On Sun, Feb 11, 2024 at 9:28 PM Benjamin Marwell wrote: > > Hello devs and plugin maintainers! > > Since JSR 305 (Nullable annotations etc.) did not get implemented > officially, and Maven allows `null` in a lot of locations, I wanted to > ask about your opinions about using jspecify: https://jspecify.dev/ > > JSpecify was created by the Java community (i.e. Java decs but also > larger corporations like Google, if I am not mistaken. It was seen as > needed since JSR 305 never materialized and probably never will. > Google hat a Guava Situation [1] and decided to do something about it. > > JSpecify says it is safe to adopt it [2]. Although the current version > is 0.3, it is more like 0.9. > > I honestly think that Maven would benefit from those annotations, as > many recent libraries try to avoid `null` as best as they can. Younger > developers may not be used to seeing nullable parameters, and even > some of us don't know which parameters can be nulled (or not). > > Let me know what you think about this idea. > > My personal opinion: I am pretty confident jspecify will displace > checker-qual as the "top dog" of nullness annotations in the future. I > also want to give plugin authors a way to use null in their plugins, > too, although we could make it an optional dependency (just > annotations...). > > Looking forward to reading your opinions! > > - Ben > > 1: https://github.com/google/guava/issues/2960 > 2: https://github.com/jspecify/jspecify/wiki/adoption > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Java version for Maven 4?
On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell wrote: > > Besides that, most big (tech) companies do not allow unmaintained or > unsupported software. How I wish that were true. Unmaintained and unsupported software is all over the place, in big tech, little tech, enterprise, and my mother's MacBook. I doubt you can install a Linux distro that doesn't depend critically on some unmaintained library no one is paying attention to. What big tech mono-repo companies do differently that most other companies don't is build everything from source themselves, kernel and build tools included, so that when some critical bug surfaces they can dig into the code and fix it. They are mostly not dependent on binaries shipped by third parties. It's a feasible option for companies in the hundreds of billions of dollars range. For the rest of us, not so much. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Java version for Maven 4?
On Tue, Feb 6, 2024 at 12:00 PM Tamás Cservenák wrote: > > Howdy, > > For start, I think Martin assumed the "build time Java requirement for > Maven4"? > > If so, my "vote" would be like: > * build time: "latest LTS" (fixed at the moment when 4.0.0 GA happens, > until then we just follow LTS), post GA "we adjust to latest LTS on each > minor release (so 4.1, 4.2, etc)" > * run time: this is the fun part: with Java 21 we already get a warning > that `release=8` is deprecated. So, basically that above introduces a hard > minimum limit (as given LTS allows). But I think we are with that, as it > really makes sense that a Java build (and comprehension bla bla) tool > _follow_ Java lifecycle, as things and new features are just flying past us > (think JPMS support in Maven), etc. > That sounds like the tail is wagging the dog. I'd start with the minimum version of Java we need to be able to build for. Right now I'd say that's Java **1.7** as I can point to major open source projects sitting underneath a lot of other projects and products that require that. E.g. google-http-java-client Given that, I wouldn't go higher for Maven itself than what can generate jars for that version, ideally without warnings. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Java version for Maven 4?
On Tue, Feb 6, 2024 at 10:50 AM Kévin Buntrock wrote: > > From my modest point of view : glued to old stack projects do not move at > all. Why move to a new maven version if the one used works? > Security issues. LTS support is a thing, and not just for JDKs. Customers really, really want versions of tools and libraries they don't have to upgrade, but that are supported when something does come up. And when a security issue does come up, they want a drop in replacement that fixes that one bug **and nothing else**. They want a patch on the old release, not a new release that deprecates 32 methods and classes, changes the behavior of 5 other methods, and requires them to recompile their code and update seven other dependencies. Customers hate being pushed into new versions when they're not ready to migrate or don't see any personal benefit from the "improvements". -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Java version for Maven 4?
On Tue, Feb 6, 2024 at 8:01 AM Benjamin Marwell wrote: > > > we need to think about companies > that pay for old JDK support > > There was a suggestion on slack that companies could provide "dev and > release manager" for Maven 3 and manage the JDK 8 Maven 3 until they lose > interest. This already works well for other projects. > Perhaps, but we'd need to modify the release process. Today Maven and plugins can pretty much only be released by a PMC member. If you expect some other company to take it up, they'd need to be able to do so without individual PMC members and without necessarily having the same human being do the job every time. Employees move on even when the job role stays the same. Furthermore, one of the unforeseen problems Maven introduced to the Java ecosystem was that, unlike with the JDK itself, Maven artifacts can't be effectively forked because a third party can't publish under the same group ID. It is no longer feasible for someone other than the originator to release a drop-in replacement that fixes a bug. Consequently any such maintainer would need to be able to release org.apache.maven artifacts like the compiler plugin, the javadoc plugin, etc. I'm not sure Apache is willing to grant that much authority to a third party. There are alternatives from the perspective of a big tech company that has the resources to maintain their own JDK. They can switch to Gradle or even maintain and release their own idiosyncratic build tool. Or all of the above. Whether that matters here, I don't know. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Java version for Maven 4?
On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau wrote: > > Hi Elliotte, > Java 11 support is already EOL for most vendor until you go "premium" > flavor which will likely be very few people and most of them will be able > to pay somebody to backport the needed stuff in custom distro of their work > if needed anyday so not sure we should consider it. At least three big tech companies I know of build their own JDKs. At least one, possibly two, ship and support older JDKs for their customers. None of them are tied to Oracle and what Oracle is willing to support. If Oracle and all its data went to the great bit bucket in the sky tomorrow, they'd keep right on rolling. It would not even be a speed bump. They don't pay for premium support. They compete to provide premium support.* * There are some caveats here I won't go into for confidentiality reasons, but I can say that Azul's business model works. > On the other side most libraries tend to move forward faster and if you > like big ones, i'll take Spring or JakartaEE as an example - big user base > rather than big company$ ;) - and they don't even support Java 11 anymore. Used by big tech customers. Not so much used by big tech companies themselves, that tend to run on stacks developed in house over more than a decade. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Java version for Maven 4?
On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell wrote: > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely > no advantage of going to 11: > The advantage of going with 11 instead of 17 is that at least 2 really big tech companies I could name (and who you can probably guess from my linked in) have only recently completed their own migration to Java 11. At least one of those two companies might still employ a PMC member (though I haven't checked post-layoffs), maybe more than one. Both have actively supported Maven development over the years, though that support ebbs and flows depending on corporate priorities. I get the impression that folks who haven't worked in such large mono-repos aren't aware of just how big a multi-year effort it is to move a repo like that onto a new JDK version. And that's just the VM, even before you allow devs to change the language level and start using the new features and libraries. That's just the two really big mono-repos I have personally worked in. I'm willing to bet that some other big Java shops are in similar positions. Switching back and forth between JDKs for open source development is doable but an unnecessary hassle. I've done it before, but even switching from JDK 8 to 11 is an extra paper cut. It kills time every time spotless fails simply because I'm using Java 8 instead of 11. Most importantly, it will be even harder to sell management on the benefit of spending developer time on Maven 4 development, if it isn't suitable for that company's own open source projects which, last I checked, were still on Java 8. (OK, I just spot checked and the first one I looked at is in fact still compiling for Java *1.7*, probably because that's where their customers are). I'm thinking back to the projects I had to justify to management a few years and one company back, and it definitely would have been harder then if I had to tell them what we were contributing would only work on Java 11 or later. Maybe today I could sell them on Java 11 (or maybe not, if they aren't paying attention to Maven at all any more) but Java 17 would be a non-starter. They might prefer to spend their resources on a build tool they own, or maybe just not spend the dev hours at all. tldr: every uptick in version requirements bleeds that many more contributors out of the pool. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Java version for Maven 4?
If we're actually voting +1 for Java 8 -1 for Java 17 or any later version. I can live with Java 11 if I have to, though I really don't see the point. Anything past Java 11 ranges from a major hassle to blocker for corporate developers, including those at big tech companies like Meta and Google, who are stuck on older versions as a matter of policy and internal support. On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux wrote: > > Hello > > From the replies in this thread, it seems to me that there is a > consensus for moving Maven 4 to some Java version after 8. I see: > > * 0 in favour of Java 11 > * 1.5 in favour of Java 17 (the .5 is because I split a vote between > Java 17 and 21) > * 2.5 in favour of Java 21 > * 4 seem neutral (including myself) > > Do we take that as an agreement to require Java 21 for building Maven 4? > > On a related question, what should be the minimal Java version for > *running* Maven 4? Keeping in mind that if Java 21 (for example) was > required, users would still be able to compile for an older Java version > using the --release option. > > Martin > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-javadoc-plugin CI is borked
If anyone has a minute to take a look. I see various failures on different dependabot PRs that have nothing to do with their content. E.g. Error: Internal server error occurred while resolving "actions/checkout@v4". Internal server error occurred while resolving "actions/setup-java@v4". Internal server error occurred while resolving "actions/upload-artifact@v4" https://github.com/apache/maven-javadoc-plugin/pull/263 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Plugin Tools version 3.11.0
+1 On Sun, Jan 7, 2024 at 12:19 PM Michael Osipov wrote: > > Hi, > > we solved 10 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12353824 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-2057/ > https://repository.apache.org/content/repositories/maven-2057/org/apache/maven/plugin-tools/maven-plugin-tools/3.11.0/maven-plugin-tools-3.11.0-source-release.zip > > Source release checksum(s): > maven-plugin-tools-3.11.0-source-release.zip > sha512: > 448dba8495c9f4859563cc418cb24113ec209119e8d53e82dae9c76f3c6fc917b14bac609e1978692eea5c88c3f89d60759c2193372e3d6c1bc640fb0afd7b6b > > Staging site: > https://maven.apache.org/plugin-tools-archives/plugin-tools-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: please do a release of maven-archetypes so wider audience can benefit from minimal jdk of 1.8
Is https://issues.apache.org/jira/browse/MARCHETYPES-78 done? That is, are all the archetypes now updated, or are there still some left? On Wed, Jan 3, 2024 at 8:54 AM Jiri Vanek wrote: > > Hello! > > There was couple of PRs which made maven-archetypes jdk21 friendly. Can you > consider a reelase so more people can benefit from those changes? > > TYVM! > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
Quick check of the repo shows two PRs from an external contributor that have been open and unaddressed since June: https://github.com/apache/maven-compiler-plugin/pull/192 https://github.com/apache/maven-compiler-plugin/pull/191 I haven't reviewed it yet — no one has — but at first glance it passes the CI and meets the bureaucratic requirements — JIRA issue, CLA, etc. — for acceptance so I think it's a serious contribution and worth a look. I'll review them now, but to support external contributors, it's helpful if PRs can be reviewed and good ones merged in advance of a release cut. On Fri, Dec 15, 2023 at 9:05 PM Slawomir Jaranowski wrote: > > Hi, > > We solved 22 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317225=12353748 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCOMPILER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-2049/ > https://repository.apache.org/content/repositories/maven-2049/org/apache/maven/plugins/maven-compiler-plugin/3.12.0/maven-compiler-plugin-3.12.0-source-release.zip > > Source release checksum(s): > maven-compiler-plugin-3.12.0-source-release.zip - SHA-512 : > 026e4affea10983e11c0b951ecc75b45deae32b9938d03f962174416f79c0bf75f31985e7add2e5312ae1d2c6a9b26f1f7bb54da7a214a0c3db275e0f41bf572 > > Staging site: > https://maven.apache.org/plugins-archives/maven-compiler-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire version 3.2.3
A few minor nits in the repo, but nothing serious or release blocking. +1 On Sat, Dec 9, 2023 at 8:53 PM Michael Osipov wrote: > > Hi, > > we solved 7 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12353823 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-2043/ > https://repository.apache.org/content/repositories/maven-2043/org/apache/maven/surefire/surefire/3.2.3/surefire-3.2.3-source-release.zip > > Source release checksum(s): > surefire-3.2.3-source-release.zip > sha512: > 024ebecddfebd05af7fb1c812333930b9277a321882a52cdd41758d45a6af3e0f1b1dc5e8f7d14acf4e593046e74750cab154cac7eb658d89bf8198a11b72369 > > Staging site: > https://maven.apache.org/surefire-archives/surefire-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Javadoc Plugin version 3.6.3
+1 On Thu, Nov 30, 2023 at 4:41 PM Michael Osipov wrote: > > Hi, > > we solved 5 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12353857 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MJAVADOC/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-2041/ > https://repository.apache.org/content/repositories/maven-2041/org/apache/maven/plugins/maven-javadoc-plugin/3.6.3/maven-javadoc-plugin-3.6.3-source-release.zip > > Source release checksum(s): > maven-javadoc-plugin-3.6.3-source-release.zip > sha512: > 724078534531971f9b2a616fe4493f103311686275a495fd7dcdfe019ec0eec5f0f9a85b3329584a68ffcddd244840245ee9265c4aa512b94201701076c70a68 > > Staging site: > https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Changing Minimum Build Requirements for plugins to JDK11
I'm OK with Java 11 required to build Maven in 2023, but I'll play my
broken record: it is not yet OK to require Java 11 to run Maven or
plugins.
There are still a lot of developers out there who are using JDK 8
toolchains. and contrary to common claims, it is still a supported
version by many JDK vendors.
On Mon, Nov 13, 2023 at 2:38 PM Karl Heinz Marbaise wrote:
>
> Hi,
>
> currently we have already the build requirements for Maven Core at JDK11+
>
> So in consequence I would suggest to lift the minimum requirement for
> building plugins to JDK11.
>
> That means also we can use "--release 8" option
> (8) instead of
> source/target which is not correct based on the warnings we get like:
> "[WARNING] bootstrap class path not set in conjunction with -source 8"
> which we get in all plugins based on the configuration in maven parent
> using this:
>
> 8
> 1.${javaVersion}
> 1.${javaVersion}
>
> which is not correct because we don't use animalsniffer anymore.
>
> So my suggestion is to lift the JDK build requirements to JDK11...
> and use the 8 which
> will prevent the warning. Also brings us back the safety net which
> animal-sniffer was before.
>
>
> Later on version of maven-parent (v42?) should change the whole
> configuration (there are some related parts like maven-pmd-plugin,
> maven-enforcer-plugin (enforce-byte-code max)..also toolchain-plugin...
>
> Furthermore we could get rid of the profile for JDK11+ related to
> spotless-maven-plugin ...
>
> Based on the upgrade to maven-parent v41 we could also enhance the build
> pipelines to build on JDK21
>
> WDYT?
>
> Kind regards
> Karl Heinz Marbaise
>
> -----
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 2.0.0-alpha-1
Looking at 1.9.16 it seems the maven-resolver-api artifact is org.eclipse.aether. That's an...interesting...design and a little surprising. I'm not sure what to think about that yet, but at least it's not a new issue. So I'll upgrade to +0 for now. On Mon, Nov 6, 2023 at 9:00 AM Elliotte Rusty Harold wrote: > > On Mon, Nov 6, 2023 at 7:18 AM Konrad Windszus wrote: > > > > The resolver API is only containing classes below org.eclipse.aether for > > historical reasons: > > https://github.com/apache/maven-resolver/tree/master/maven-resolver-api/src > > > > Is this still necessary? It seems likely to cause dependency conflicts > and split package issues. > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 2.0.0-alpha-1
On Mon, Nov 6, 2023 at 7:18 AM Konrad Windszus wrote: > > The resolver API is only containing classes below org.eclipse.aether for > historical reasons: > https://github.com/apache/maven-resolver/tree/master/maven-resolver-api/src > Is this still necessary? It seems likely to cause dependency conflicts and split package issues. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 2.0.0-alpha-1
-1 I see at least one issue that should be resolved before alpha 1. The API docs at https://maven.apache.org/resolver-archives/resolver-LATEST/apidocs/index.html contains docs for aether and for resolver examples but not for the resolver API itself. Possibly a misconfig in the javadoc generation somewhere. Also, why do the Javadocs contain all those oerg.eclipse.aether packages? I don't see them in the source repo. On Mon, Nov 6, 2023 at 9:32 AM Tamás Cservenák wrote: > > +1 > > On Thu, Nov 2, 2023, 12:23 Tamás Cservenák wrote: > > > Howdy, > > > > Note: This is a preview release of Resolver 2.0.0, that would allow any > > downstream consumers to try it out and adapt. Most of the major issues were > > fixed, almost all of the functionality is there (compare JIRA "2.0.0" and > > "2.0.0-alpha-1" versions). > > > > IF the vote is successful, the staging site will NOT be moved to > > https://maven.apache.org/resolver/ but instead will be made reachable > > from https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-1/ > > only. > > > > The 1.9.16 is still the "latest stable" release of Maven Resolver. > > > > === > > > > We solved 18 issues: > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353805 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-2021 > > > > Source release SHA512: > > > > afe0796c9ea833a21a536dd53a5406013df9c92ada20a2ca2f05eb7c5582258ee04622bbaf6a19716d0736a0768735423529283e1aaa81e028cd00087228b452 > > > > Staging site: > > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Heads Up] Maven3 is not Maven2, and whoever assumes so, is wrong
Very interesting and informative. Thanks. A couple of thoughts: On Mon, Oct 30, 2023 at 1:46 PM Tamás Cservenák wrote: > Out of this misconception is > derived another misconception, that one graph can contain multiple > classpaths, and by proper partitioning of the graph you can derive this or > that (usually "runtime" or "test" classpath). I'm not sure what you mean here. Graphs don't "contain" classpaths. Classpaths are linear lists of jar files (and occasionally a few other things like zips or directories, but mostly jars). Constructing a classpath from a dependency graph is an important operation in its own right. Furthermore, different tools like Maven and Gradle can construct two different classpaths from the same dependency graph in the same scope. This issue also leads to a lot of problems for users. > > Maybe Maven4 plugins > (using Maven4 API) is the time to really "redo" the plugins correctly, and > not "port them" to new APIs, as it will port these wrong assumptions as > well. I worry that we simply don't have the developer bandwidth to undertake that. It feels like less work to fix what we have. After all, although problems undoubtedly exist, it mostly works most of the time for most developers. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JDK 21 in CI
JDK 21 is now the both the latest and latest LTS release of Java so it's worth adding it to our build matrices in place of JDK 20. Worth noting: I've seen multiple other open source projects have new test failures on JDK 21 so there could be some fixup worth to do in some plugins before this is merged. I filed https://github.com/apache/maven-dependency-plugin/pull/346 to switch one project from JDK 20 to JDK 21 but there are a few doxzen others. I don't know if anyone has any tooling for search and replace and filing PRs across all the repos. If not, I should probably write some. It's just a one character change (20 --> 21) in .github/workflows/maven-verify.yml -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Dependency Plugin version 3.6.1
I see a couple of open dependabot PRs that should probably go in. I'll merge them, but you'll need to recut to pick them up. On Fri, Oct 20, 2023 at 5:28 PM Michael Osipov wrote: > > Hi, > > we solved 7 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12353360 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MDEP/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-2013/ > https://repository.apache.org/content/repositories/maven-2013/org/apache/maven/plugins/maven-dependency-plugin/3.6.1/maven-dependency-plugin-3.6.1-source-release.zip > > Source release checksum(s): > maven-dependency-plugin-3.6.1-source-release.zip > sha512: > 6bdbd4cf4ff355d4e087ee5a7eef24b8812963c4372a6ba5116c8ea8dfdc5291c34edc262fe19eb2fc97a8e77d60c91d9ec843512729b862609f28689f396bd9 > > Staging site: > https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Dependency Plugin version 3.6.1
https://issues.apache.org/jira/projects/MDEP/issues/MDEP-812?filter=allopenissues is prioritized as a blocker. That's probably overstating that one — it smells like user error or an old version — but please do downgrade its priority before releasing. On Fri, Oct 20, 2023 at 5:28 PM Michael Osipov wrote: > > Hi, > > we solved 7 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12353360 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MDEP/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-2013/ > https://repository.apache.org/content/repositories/maven-2013/org/apache/maven/plugins/maven-dependency-plugin/3.6.1/maven-dependency-plugin-3.6.1-source-release.zip > > Source release checksum(s): > maven-dependency-plugin-3.6.1-source-release.zip > sha512: > 6bdbd4cf4ff355d4e087ee5a7eef24b8812963c4372a6ba5116c8ea8dfdc5291c34edc262fe19eb2fc97a8e77d60c91d9ec843512729b862609f28689f396bd9 > > Staging site: > https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: verifying signatures, PGP or ... (was Re: [VOTE] Release Apache Maven Artifact Plugin version 3.5.0)
1. I suspect dependabot doesn't work with this. Does it? Is this worth giving up dependabot for? 2. What's the threat model? As best I can make out, someone would have to compromise the dependencies in the local .m2/repo since anything downloaded comes over https and is already signature checked. 3. Suppose someone does succeed in compromising this. What's the impact? I suppose if someone changed junit.jar (for one example) they could make maven test exfiltrate local data or run a crypto miner. but I don't think we should be in the business of protecting against local compromises. How does this signature check prevent someone from doing something bad? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Artifact Plugin version 3.5.0
Not a blocker but I did take a quick look at the dependencies. I noticed that maven-shared-utils was out of date, but when I tried to update it, it failed on verification of the PGP signature of commons-io which was now 2.13.0 instead of 2.11.0. This comes from the Verify PGP signatures plugin, which I haven't seen before. Is this a helpful check? I haven't seen it before, and it definitely adds extra work to updating dependencies. If it makes dependencies less likely to be kept up to date, that's likely to be a net security negative. Is there a string reason to check PGP signatures at build time? And if there is, why are we doing this with a fixed map instead of looking them up in Maven Central? On Fri, Sep 29, 2023 at 2:00 AM Hervé Boutemy wrote: > > Hi, > > We solved 6 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12324322=12353118=Text > > Staging repo: > https://repository.apache.org/content/repositories/maven-1992/ > https://repository.apache.org/content/repositories/maven-1992/org/apache/maven/plugins/maven-artifact-plugin/3.5.0/maven-artifact-plugin-3.5.0-source-release.zip > > Source release checksum(s): > maven-artifact-plugin-3.5.0-source-release.zip sha512: > 3155f2e3da07752473fe5a2deb5b32f108c2fb1d8cd786718852f18242afad515fafcf55710f03c136fff9f343702e8e0152d53d51f69f6c043ecc397ce818e1% > > Staging site: > https://maven.apache.org/plugins-archives/maven-artifact-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Javadoc Plugin version 3.6.0
MJAVADOC-747 and MJAVADOC-764 are listed as blockers. Please reclassify these if they're not truly release blockers. On Tue, Sep 12, 2023 at 2:23 AM Henning Schmiedehausen wrote: > > Hi, > > We solved 16 > issues:https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12352956 > > There are still a couple of issues left in > JIRA:https://issues.apache.org/jira/projects/MJAVADOC?filter=allopenissues > > Staging > repo:https://repository.apache.org/content/repositories/maven-1989/https://repository.apache.org/service/local/repositories/maven-1989/content/org/apache/maven/plugins/maven-javadoc-plugin/3.6.0/maven-javadoc-plugin-3.6.0-source-release.zip > > Source release checksum(s): > maven-javadoc-plugin-3.6.0-source-release.zip sha512: > 82fa3e3685b90225749ae884fd9ea2cb72385524e76df299c5176baed983f39a433fa29e93554e207d8ed9aaa10bb6e7b148409a865ecce1b3f40ef0cf9032d4 > > Staging > site:https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/ > > Guide to testing staged > releases:https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Coming soon: Maven 3.9.5
Was this intentional? [ERROR] Rule 0: org.apache.maven.enforcer.rules.version.RequireJavaVersion failed with message: [ERROR] Detected JDK version 1.8.0-181 (JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre) is not in the allowed range [1.8.0-362,). If so, we should note it in the docs. I vaguely recall something about this before, but can't immediately find it in the archives On Thu, Sep 7, 2023 at 10:18 AM Tamás Cservenák wrote: > > Howdy, > > Just a heads up, that am targeting following releases: > > Maven Resolver 1.9.16: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.16 > > Maven 3.9.5: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.5 > > So if anyone has anything more to add, bring it up! > > TIA > T -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
On Fri, Jun 9, 2023 at 4:20 PM Guillaume Nodet wrote: > > I'd really like to > * use JEP 442 to get rid of the JNI and native libs in jline, jansi and > mvnd (but that's for JDK 21) JEP 442 won't be ready for I'm not sure how many JDKs yet. I wouldn't expect Maven to depend on it this decade. JAnsi we could simply remove though. jline and mvnd I know nothing about. > * use JEP 380 (unix domain sockets) to be able to cleanly implement > https://github.com/apache/maven-resolver/pull/269 No opinion > * use some helper methods that have been added: List.of(), > Stream.toList(), Files.readString() to name just a few > * have syntactic sugar with text blocks, enhanced switches... > Not worth the pain we'd cause users. We haven't finished updating to utility methods available in Java **7** yet. In general, before we talk about new JDK versions I'd like to make sure we're taking advantage of the JDK version we have. Moving random files and methods to java 20+ is just confusing and makes little difference in code cleanliness or execution speed. There's plenty of much more important maintenance work in the queue. Some of our plugins still aren't on parent POM 39. We have code written to support entire operating systems that have been sold or supported for years. Netware. Let's deal with that cruft first. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Enforcer version 3.4.1
MENFORCER-490 is improved but not yet fixed or finished. There are at least a couple of PRs to go. On Thu, Sep 7, 2023 at 1:41 PM Slawomir Jaranowski wrote: > > Hi, > > We solved 2 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317520=12353576 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MENFORCER%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1987/ > https://repository.apache.org/content/repositories/maven-1987/org/apache/maven/enforcer/enforcer/3.4.1/enforcer-3.4.1-source-release.zip > > Source release checksum(s): > enforcer-3.4.1-source-release.zip - SHA-512 : > 64fcd4a97487ae50976426da63f3ba58cb0fe47a72235afa8f05e5d6e8118ad09dbc8269c5ff106ab1e274dd54e439c737585df1232b85be7ea202aee6ac5864 > > Staging site: > https://maven.apache.org/enforcer-archives/enforcer-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?
On Mon, Aug 28, 2023 at 12:25 PM Martin Desruisseaux wrote: > > > Meta-point: it's easier to keep long term track of discussions like > > this if they're in the issue tracker instead of the mailing list. > > We have https://issues.apache.org/jira/browse/MNG-7855. Should it be a > wiki or a GitHub discussion page instead? (whatever is more convenient > for developers involved in those parts of Maven). > The JIRA is the right place. I'm simply suggesting that this discussion about transitive dependencies etc. take place there instead of in the mailing list. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to fix MNG-7855 (dependencies wrongly put on class-path rather than module-path)?
On Mon, Aug 28, 2023 at 8:49 AM Martin Desruisseaux wrote: > > Hello again > > What about the following proposal for addressing MNG-7855? > > * Long term solution would be to change the POM model by expanding the > section for controlling on an individual basis how to > handle each dependency. How would this work with transitive dependencies? Meta-point: it's easier to keep long term track of discussions like this if they're in the issue tracker instead of the mailing list. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Enforcer version 3.4.0
+0 There are some non-critical dependency issues in the various poms, one of which might point to a bug in the dependency analyzer. I'll see if I can clean some up but probably not worth holding the release for. On Mon, Aug 21, 2023 at 9:59 PM Herve Boutemy wrote: > > +1 > > Reproducible Build ok: reference build done with JDK 17 on *nix with umask 022 > > Regards, > > Hervé > > On 2023/08/19 16:54:40 Slawomir Jaranowski wrote: > > Hi, > > > > We solved 9 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317520=12353101 > > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MENFORCER%20AND%20resolution%20%3D%20Unresolved > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1986/ > > https://repository.apache.org/content/repositories/maven-1986/org/apache/maven/enforcer/enforcer/3.4.0/enforcer-3.4.0-source-release.zip > > > > Source release checksum(s): > > enforcer-3.4.0-source-release.zip - SHA-512 : > > b9acac178d095f32fbeed73b278c2dcb07081f1ef1e6a520f990f31217278edff05c19a7945bef99088e8e8e3d9a6212b6fb23bb5de1356bb849e5e0835a9651 > > > > Staging site: > > https://maven.apache.org/enforcer-archives/enforcer-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > -- > > Sławomir Jaranowski > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Major changed for 4.x
On Tue, Aug 22, 2023 at 10:33 AM Gary Gregory wrote: ="2.13.0" ... /> > > In general, I want the XML to more OO, where XML elements are objects and > attributes are, well, attributes. That dog won't hunt for reasons that are not specific to Maven. In OO attributes can be arbitrarily complex structured objects. In XML attributes are strings. There's a deep mismatch here that can't be bridged in any sane way. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Maven Resolver future
Tangential note: I dislike multi-digiti minor versions. 1.10 is just way too easy to confuse with 1.1.0. That is, when one reaches 1.9 it's time to move to 2.0, even if you don't plan to break the API in any way. So +1 for moving the next version to 2.0 On Thu, Jul 20, 2023 at 6:20 AM Tamás Cservenák wrote: > > Howdy, > > I'd like to pitch some discussion regarding Resolver near and longer term > future. > > If you look at the JIRA version "planned for" 1.10.0, there are quite some > (even partially done) code changes that are not trivial. Moreover, we want > to drop some deprecated baggage as well: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.10.0 > > My proposal is to move on to Resolver 2.0.0 instead. > > So, Resolver wise my proposal is: > - resolver 1.9.x branched off, goes into "bugfix" mode > - resolver master goes 2.0.0, with new features (already in JIRA or not yet) > - resolver 3.0.0 will also contain java package change (org.eclipse.aether > -> org.apache.maven.resolver), so package change becomes "shifted" from > 2.0.0 to 3.0.0 > > Maven wise, this happens: > - Maven 3.9.x remains on resolver 1.9.x (and will also slowly go into > "bugfix" mode) > - Maven 4.x moves to resolver 2.0.0 (still must support Maven 3 plugins > going directly for resolver) > - Maven 5.x moves to resolver 3.0.0 (when the resolver is sealed off > completely from plugins). > > WDYT? > > Thanks > T -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Gratuitous refactorings
It hadn't occurred to me that it might be a bot. Given that, I'm going to go ahead and close these when I see them. If an actual human being objects, it can be reopened. Thanks. On Thu, Jul 6, 2023 at 12:10 AM Henning Schmiedehausen wrote: > > This is most likely a bot "warming up" by contributing to some well-known > (high-reputation) repository. Merging those will allow them to build a > reputation for things like "sell stars for github repos". > > - https://the-guild.dev/blog/judging-open-source-by-github-stars > - https://dagster.io/blog/fake-stars > > Straight up "don't merge", ask the person to not send in PRs like this > (there are sometimes newbies but most likely it is a bot), if they keep > doing it, report them to GH, they actually take a dim view on this. > > This is the equivalent of "me too spam" in the end times of the usenet. > > -h > > > > On Wed, Jul 5, 2023 at 6:05 AM Elliotte Rusty Harold > wrote: > > > Lately I've noticed a few random PRs from first time contributors that > > use some automated refactoring tool on our code for no obvious reason. > > Here's an example: > > > > https://github.com/apache/maven-assembly-plugin/pull/131 > > > > These refactorings don't seem helpful and don't IMO improve the code in > > any way. > > > > I'm not sure what's going on here. Perhaps Maven is getting used as an > > example in a training course or class somewhere. Perhaps someone is > > evaluated on the number of Github PRs they create or get merged. > > > > I'm inclined to close these without further comment. Thoughts? > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > ----- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Gratuitous refactorings
Lately I've noticed a few random PRs from first time contributors that use some automated refactoring tool on our code for no obvious reason. Here's an example: https://github.com/apache/maven-assembly-plugin/pull/131 These refactorings don't seem helpful and don't IMO improve the code in any way. I'm not sure what's going on here. Perhaps Maven is getting used as an example in a training course or class somewhere. Perhaps someone is evaluated on the number of Github PRs they create or get merged. I'm inclined to close these without further comment. Thoughts? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Possible improvements on Maven
On Sat, Jul 1, 2023 at 6:11 AM #ZHAO LIDA# wrote: > > Dear Maven maintainers, > > > we are studying Maven dependency specifications and we would like to offer > several possible improvements for Maven. > > > (1) The scope management of Maven is complicated and hard to distinguish. > Maven maintained 6 scopes (i.e., compile, runtime, provided, system, test, > and import). Compare to newer package managers such as NPM, which only has > two scopes (i.e., dependencies, devdependencies), Maven has too many types of > scopes, which makes it more difficult for users to understand. We went over > all POMs on the Maven Central (around 8M artifacts, collected in March 2022) > and count the frequency of all types of scope. Some of the scopes are rarely > used. Only 0.35% of POMs in the Maven Center used system scope. Also, system > scope is similar to provided scope, and import scope can hardly be regarded > as a dependency scope. We suggest simplifying the types of scopes by merging > system into provided and removing import. This would probably be a good idea if we were starting from a green field, but backwards compatibility with a 20 year legacy trumps good design. IMHO this isn't feasible. > (2) In the documentation of Default Artifact Handlers > (https://maven.apache.org/ref/3.9.3/maven-core/artifact-handlers.html), type > and classifier should introduce more commonly used values as their default > value to provide better examples. We found that the default values are rarely > used and are not good examples for users to understand the use of the > settings. Setting commonly used values as default can help users understand > the usage of the settings. We went over all POMs on the Maven Central (around > 8M artifacts, collected in March 2022) and count the frequency of all > possible values of classifier and type. According to our research, in > classifier, the default values have low frequencies, including tests (1.05%), > javadoc (0.35%), sources (0.29%), and client(0.01%). More commonly used > values are features (1.20%), linux-x86_64 (0.34%), and osx-x86_64 (0.27%). As > for type, the top default values are pom (4.38%), test-jar (2.85%), war > (1.08%) and the rest of the values are all below 0.1%. Other common examples > are esa (2.53%), zip (1.88%), and xml (1.31%). Maven's documentation is... Well, it is. That's about all I can say for it. It's trivial to find parts that need work, anything from typo fixes to rewrites from a blank page. Feel free to assign me as reviewer on any PRs to improve this. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.9.3
It would also be nice to get https://issues.apache.org/jira/browse/MNG-7714 backported into 3.9.x assuming I'm correct that it's currently only fixed on the 4.x branch. On Fri, Jun 23, 2023 at 9:34 AM Tamás Cservenák wrote: > > Howdy, > > We solved 22 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353255 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1968/ > > Dev dist directory: > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.3/ > > Source release checksums: > apache-maven-3.9.3-src.zip sha512: > a56a9e47e70ba8e3e83ff627b76a712c7b5bda59245d23bcbc541b2358b859f699d4916b7e715c45a5c336676b8b2ab0ab472dffc045ae4db635b21f7ddcc0c2 > apache-maven-3.9.3-src.tar.gz sha512: > 5511b20c36fd09a8ba7260bfa78d29bb683a04828c56e93d176768eb61cb07ab91f29db745460ce9784c84561f359497158f4c800142716d3e590ac2c333e8fb > > Binary release checksums: > apache-maven-3.9.3-bin.zip sha512: > fba80f4bb0429052d558959b1bfbc99984f8cb8ff59a53baae0a0874b71a2601e2805c5e557b7b59d81716a0b4b35d1b2eeccb566c40b23cc575331a4984ef6c > apache-maven-3.9.3-bin.tar.gz sha512: > 400fc5b6d000c158d5ee7937543faa06b6bda8408caa2444a9c947c21472fde0f0b64ac452b8cec8855d528c0335522ed5b6c8f77085811c7e29e1bedbb5daa2 > > Staged site: > https://maven.apache.org/ref/3-LATEST/ > > Draft for release notes: > https://github.com/apache/maven-site/pull/424 > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72h > > [ ] +1 > [ ] +0 > [ ] -1 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.9.3
There seems to be a recent security fix in Guava in 32.0.0 which broke other things, so 32.0.1 is recommended. I'm not sure if any of this affects Maven, but it's probably good to get this in. On Fri, Jun 23, 2023 at 9:34 AM Tamás Cservenák wrote: > > Howdy, > > We solved 22 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353255 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1968/ > > Dev dist directory: > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.3/ > > Source release checksums: > apache-maven-3.9.3-src.zip sha512: > a56a9e47e70ba8e3e83ff627b76a712c7b5bda59245d23bcbc541b2358b859f699d4916b7e715c45a5c336676b8b2ab0ab472dffc045ae4db635b21f7ddcc0c2 > apache-maven-3.9.3-src.tar.gz sha512: > 5511b20c36fd09a8ba7260bfa78d29bb683a04828c56e93d176768eb61cb07ab91f29db745460ce9784c84561f359497158f4c800142716d3e590ac2c333e8fb > > Binary release checksums: > apache-maven-3.9.3-bin.zip sha512: > fba80f4bb0429052d558959b1bfbc99984f8cb8ff59a53baae0a0874b71a2601e2805c5e557b7b59d81716a0b4b35d1b2eeccb566c40b23cc575331a4984ef6c > apache-maven-3.9.3-bin.tar.gz sha512: > 400fc5b6d000c158d5ee7937543faa06b6bda8408caa2444a9c947c21472fde0f0b64ac452b8cec8855d528c0335522ed5b6c8f77085811c7e29e1bedbb5daa2 > > Staged site: > https://maven.apache.org/ref/3-LATEST/ > > Draft for release notes: > https://github.com/apache/maven-site/pull/424 > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72h > > [ ] +1 > [ ] +0 > [ ] -1 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Clean Plugin version 3.3.1
This might not be blocking but there are some dependency issues: [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-clean-plugin --- [WARNING] Used undeclared dependencies found: [WARNING]commons-io:commons-io:jar:2.2:test [WARNING]org.eclipse.aether:aether-api:jar:1.0.0.v20140518:provided [WARNING] Unused declared dependencies found: [WARNING]org.codehaus.plexus:plexus-xml:jar:4.0.0:provided [WARNING]org.apache.maven:maven-compat:jar:3.2.5:test [WARNING]junit:junit:jar:4.13.2:test The plexus-xml one is particularly interesting. Removing it from the pom.xml breaks the build like this: [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.04 s <<< FAILURE! - in org.apache.maven.plugins.clean.CleanMojoTest [ERROR] org.apache.maven.plugins.clean.CleanMojoTest.initializationError Time elapsed: 0.013 s <<< ERROR! java.lang.NoClassDefFoundError: org/codehaus/plexus/util/xml/XmlStreamReader This seems to come from the superclass AbstractMojoTestCase. This might be an error in the dependency declarations for maven-pluign-testing. Or it might be an issue because AbstractMojoTestCase expects to find XmlStreamReader in plexus-utils, but it's no longer present in plexus-utils 4.0.0. Instead it comes from plexus-xml. The more I look at it, the more likely this seems. So there are two issues here: 1. maven-dependency-analyzer is reporting a new false negative. In general, analysis of dependencies gets much trickier when classes belong to different artifacts in different versions. 2. The presence of plexus-utils 4.0.0 means that maven-plugin-testing no longer correctly declares its dependencies. On Wed, Jun 14, 2023 at 6:58 PM Guillaume Nodet wrote: > > Hi, > > Fwiw, I've burned the 3.3.0 release, hence 3.3.1... > > we solved 5 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12351541 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MCLEAN/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1961/ > https://repository.apache.org/content/repositories/maven-1961/org/apache/maven/plugins/maven-clean-plugin/3.3.1/maven-clean-plugin-3.3.1-source-release.zip > > Source release checksum(s): > maven-clean-plugin-3.3.1-source-release.zip > sha512: > a195d19de931800d243aed24fa4eb86ac0961ed0a487ff88e513bccb183176b4dd401f870ad970f630ed72a86b5826b8b0e0bd50afecbae5ba7fb2d65a0eb9af > > Staging site: > https://maven.apache.org/plugins-archives/maven-clean-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > -- > > Guillaume Nodet -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven parent 40
It's not that these problems are unsolvable. They're not. But splitting the packages like this means that a lot of projects are going to burn a lot of hours working around unexpected breakages. It's annoying for someone who's well-versed in BOMs, dependency management, classpath loaders, exclusions, and the Maven dependency resolution algorithm. It's much worse for anyone who isn't hip deep in this muck on a day-to-day basis. I worry this is going to cause a lot of tsuris for no particular benefit. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven parent 40
-1 https://github.com/apache/maven-parent/pull/123/files seems likely to break projects that update to parent pom 40 without adding an extra dependency on plexus-xml 4.0.0, and this breakage might be several levels deep in the dependency tree so there's no guarantee it will be caught in the project that pulls it in. On Mon, Jun 12, 2023 at 6:08 PM Slawomir Jaranowski wrote: > > Hi, > > For testing you need ASF parent 30 from the staging repository. > > We solved 15 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12352681 > > Commits: > https://github.com/apache/maven-parent/compare/maven-parent-39...maven-parent-40 > > Staging repo: > https://repository.apache.org/content/repositories/maven-1956/ > https://repository.apache.org/content/repositories/maven-1956/org/apache/maven/maven-parent/40/maven-parent-40-source-release.zip > > Source release checksum(s): > maven-parent-40-source-release.zip - SHA-512 : > 8014f1b5b15b6e60d7d17077a3c853c40eff54385ab658ea102398129ad96fb1fc329c8b0130f52d7d05aff7a258e7d5cce0e02c9dfae40ed9427a8cb3ea7da1 > > Staging site: > https://maven.apache.org/pom-archives/maven-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE} Maven Build Cache Extension 1.0.1
The dependencies could use a little work. The Guava problem is a true positive. I haven't checked the others yet, but Guava could almost certainly be removed from the build. Only one class that is no longer needed in Java 8+ seems to be used. Also, seeing two variants of plexus-utils in the list is a tad concerning. I'm not sure what's up with that. I haven't noticed that issue before so I'll have to dig in to see what's happening there. Also, JUnit and SLF4J versions seem to be mixed up. [WARNING] Used undeclared dependencies found: [WARNING]org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.5:provided [WARNING]org.apache.maven:maven-plugin-api:jar:4.0.0-alpha-5:provided [WARNING]javax.inject:javax.inject:jar:1:provided [WARNING]org.apache.maven:maven-model:jar:4.0.0-alpha-5:provided [WARNING]org.junit.jupiter:junit-jupiter-api:jar:5.9.3:test [WARNING]junit:junit:jar:4.13.2:test [WARNING]org.jetbrains:annotations:jar:17.0.0:test [WARNING]org.slf4j:slf4j-api:jar:1.7.36:compile [WARNING]org.apache.maven:maven-artifact:jar:4.0.0-alpha-5:provided [WARNING]org.apache.maven.resolver:maven-resolver-spi:jar:1.9.7:provided [WARNING]com.google.guava:guava:jar:30.1-jre:provided [WARNING]org.apache.maven.resolver:maven-resolver-api:jar:1.9.7:provided [WARNING]org.apache.maven:plexus-utils:jar:4.0.0-alpha-5:provided [WARNING] Unused declared dependencies found: [WARNING] org.apache.maven.resolver:maven-resolver-transport-http:jar:1.9.7:provided [WARNING]org.codehaus.plexus:plexus-utils:jar:3.5.1:compile [WARNING]org.apache.maven.wagon:wagon-webdav-jackrabbit:jar:3.5.3:compile [WARNING]org.junit.jupiter:junit-jupiter-engine:jar:5.9.3:test [WARNING]org.apache.maven:maven-embedder:jar:4.0.0-alpha-5:test [WARNING]ch.qos.logback:logback-classic:jar:1.3.7:test [WARNING]org.slf4j:log4j-over-slf4j:jar:1.7.36:test [WARNING]org.slf4j:jcl-over-slf4j:jar:1.7.35:test [WARNING]org.slf4j:jul-to-slf4j:jar:1.7.35:test On Tue, Jun 6, 2023 at 7:51 AM Olivier Lamy wrote: > > Hi, > I'd like to release Maven Build Cache Extension 1.0.1 > We fixed 13 issues > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352469=Text=12324820=Create > > Staging repo: https://repository.apache.org/content/repositories/maven-1953/ > source zip: > https://repository.apache.org/content/repositories/maven-1953/org/apache/maven/extensions/maven-build-cache-extension/1.0.1/maven-build-cache-extension-1.0.1-source-release.zip > > stages site: > https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/ > > Vote open 72h > > +1 > 0 > -1 > > cheers > Olivier > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE} Maven Build Cache Extension 1.0.1
There are three open PRs in the repo. At a quick glance, one looks like it perhaps should be closed unmerged, and the other needs to rebase onto master and be merged. On Tue, Jun 6, 2023 at 7:51 AM Olivier Lamy wrote: > > Hi, > I'd like to release Maven Build Cache Extension 1.0.1 > We fixed 13 issues > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352469=Text=12324820=Create > > Staging repo: https://repository.apache.org/content/repositories/maven-1953/ > source zip: > https://repository.apache.org/content/repositories/maven-1953/org/apache/maven/extensions/maven-build-cache-extension/1.0.1/maven-build-cache-extension-1.0.1-source-release.zip > > stages site: > https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/ > > Vote open 72h > > +1 > 0 > -1 > > cheers > Olivier > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
On Sun, Jun 4, 2023 at 10:59 AM Delany wrote: > > I think the point I'm making is no-one wants to write in an older version > of the language they started writing in. Its tedious. Anyone who started > writing java11 code is going to have a hard time accepting they need to > write in java8, just as a java8 will bulk at writing in java5. Of course > for the oldies it just feels nostalgic. > Strongly disagree. I personally would strongly prefer to stick to Java *7*, although these days I use mostly 8 and 11. IMHO Java 8 and Java 11 were significant downgrades for clarity of code and ease of use. While there were some nice improvements in libraries and VM in those versions, they are completely swamped by the truly awful lambda syntax and the useless pain of the Java Platform Module System. Nor is it like we've finished the work of migrating onto Java 8. Just this past week I replaced some code that hasn't been needed since Java *1.4*. Migrating to still newer Java versions is a distraction from far more important work. We haven't even moved all the plugins off Java 7 yet. The burden of proof is on people who want to migrate to Java 17 to show how that will improve the project. That burden has not been met. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
On Thu, Jun 1, 2023 at 10:47 AM Romain Manni-Bucau wrote: > Yep but this is also something an OSS product don't want to rely on (ie > particular vendor specificities which can change), so we should probably > stick to the global dates and align on these ones consistently. > Yes, but that principle implies the opposite. We should not rely on the particular vendor specificities of Oracle's commercial release, including when they decide to stop supporting JDK 8. The open source release of JDK 8 is available and will continue to be so for years. It is supported and maintained by multiple companies, organizations, and individuals, not just Oracle. It is an active project with quarterly releases and many active committers: https://wiki.openjdk.org/display/jdk8u/Main -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet wrote: > > JDK 8 active support ended 15 months ago, so I think that's definitely fine > to require a newer version. This is a common misconception. JDK 8 is fully supported by multiple companies including Azul. It also seems supported by Oracle: "For Java SE 8, Oracle will continue to release new updates on its public websites for personal/individual users or for non-production, development/testing purposes. However, commercial/business use of those public releases in production is restricted and requires a commercial license." -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
On Wed, May 31, 2023 at 10:37 AM Guillaume Nodet wrote: > > Who said so ? If there's a need and will to maintain the 3.x branch, so be > it. No one is forbidden to work on those branches. That's not really true. Short of a complete fork, new versions can't go out without effort from PMC members. Users cannot effectively self-serve here. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Question - JDK Minimum of future Apache Maven 4.0.0
On Wed, May 31, 2023 at 8:30 AM Guillaume Nodet wrote: > I think with those improvements, requiring JDK 17 for master should be > doable. Any concerns of suggestions ? Hard no from me. JDK 8 is still very much in use, and is my day-to-day VM. I switch to 11 when I have to, and I don't anticipate switching to 17 for years unless I decide to write another book. When I left Google and GCP about a year ago, we still had customer requirements for quite old versions. From the public docs it looks like they still support Java 8 and sometimes Java 7. I know of multiple companies where the migration to Java 11 is still in progress. Some companies are also sticking to Java 8 for likely the remainder of my career. JPMS in Java 9 caused a lot of problems for weakly supported libraries and many devs can't or won't upgrade past Java 8 for that reason. Slow and steady wins the race. Java 8 is a perfectly fine VM, and Maven really doesn't need anything more right now. I think we'll get to Java 11 eventually. but that's still a few years down the road and there's a lot of cleanup work to be done first. Just today I sent a PR to replace some utility methods we haven't needed since Java *1.4*. When there's some improvement we really can't make without updating to Java 11 is when we should consider switching. So far I don't see any critical need for it though. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Release Plugin version 3.0.1
FYI, there seem to be some issues with dependabot configs. It's useful when it fires, but it doesn't always, and sometimes it closes update PRs for no valid reason I can discern. And of course there are the more complex updates that can require more than a simple number change in a pom.xml like https://github.com/apache/maven-surefire/pull/652 which I still haven't fully debugged On Wed, May 31, 2023 at 11:25 AM Jeremy Landis wrote: > > Common thread I keep seeing. Update all the libraries! ...the common > thread.. No concern on this one but maven does still release vulnerable > plugin usage especially around transient commons collections. We keep > patching so it's also frustrating the speed of plugin releases that are not > accounting for already available pull requests only to see core team make > this argument each release recently... > > I think in general, same I tell my devs. Review the bot pull requests and > incorporate all the ones possible before any release. > > Sent from my Verizon, Samsung Galaxy smartphone > Get Outlook for Android<https://aka.ms/AAb9ysg> > ________ > From: Elliotte Rusty Harold > Sent: Wednesday, May 31, 2023 7:09:22 AM > To: Maven Developers List > Subject: Re: [VOTE] Release Apache Maven Release Plugin version 3.0.1 > > One minor dependency update to maven-scm: > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fmaven-release%2Fpull%2F192=05%7C01%7C%7Cd62172d30703417bea4008db61c7aba5%7C84df9e7fe9f640afb435%7C1%7C0%7C638211282439154797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=N%2B3ESphp2RdNQUw0Lmr1s41MrdDcFVth7rpvJJCVxjM%3D=0<https://github.com/apache/maven-release/pull/192> > > Otherwise, looks good. > > On Tue, May 30, 2023 at 9:35 PM Slawomir Jaranowski > wrote: > > > > Hi, > > > > We solved 8 issues: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2FReleaseNote.jspa%3FprojectId%3D12317824%26version%3D12353136=05%7C01%7C%7Cd62172d30703417bea4008db61c7aba5%7C84df9e7fe9f640afb435%7C1%7C0%7C638211282439154797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=K0PqT3u1i%2BnCyjtXTFaeS5B%2Bf%2FkYtZbCuQGaZLHIANY%3D=0<https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824=12353136> > > > > There are still a couple of issues left in JIRA: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fissues%2F%3Fjql%3Dproject%2520%253D%2520MRELEASE%2520AND%2520resolution%2520%253D%2520Unresolved=05%7C01%7C%7Cd62172d30703417bea4008db61c7aba5%7C84df9e7fe9f640afb435%7C1%7C0%7C638211282439154797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=oWlIcdjMAesuCqZJji1g38cVL8mo8rTo47TjNZrdzQw%3D=0<https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRELEASE%20AND%20resolution%20%3D%20Unresolved> > > > > > > Staging repo: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Fmaven-1950%2F=05%7C01%7C%7Cd62172d30703417bea4008db61c7aba5%7C84df9e7fe9f640afb435%7C1%7C0%7C638211282439154797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=lvgqlqCAjzalGHn96QSFkchLbh5MyTU9c8Cyo4B%2BN08%3D=0<https://repository.apache.org/content/repositories/maven-1950/> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Fmaven-1950%2Forg%2Fapache%2Fmaven%2Frelease%2Fmaven-release%2F3.0.1%2Fmaven-release-3.0.1-source-release.zip=05%7C01%7C%7Cd62172d30703417bea4008db61c7aba5%7C84df9e7fe9f640afb435%7C1%7C0%7C638211282439154797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=YTkPBYdoTpceNk8Zxy296APUndozmceHfzQ7NwzcThg%3D=0<https://repository.apache.org/content/repositories/maven-1950/org/apache/maven/release/maven-release/3.0.1/maven-release-3.0.1-source-release.zip> > > > > Source release checksum(s): > > maven-release-3.0.1-source-release.zip - SHA-512: > > e59018a70e67f8af38f4d02bc28703f54ec01d032bd9d21972d087bb196ed8997040da0600a687d5604ebed794ab444d67b697ae17f793f0e8908a4ca0a37f69 > > > > > > Staging site: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fcomponents%2Fmaven-release-archives%2Fmaven-release-LATEST=05%7C01%7C%7Cd62172d30703417bea4008db61c7aba5%7C84df9e7fe9f640afb435%7C1%7C0%7C638211282439154797%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
Re: [VOTE] Release Apache Maven Release Plugin version 3.0.1
One minor dependency update to maven-scm: https://github.com/apache/maven-release/pull/192 Otherwise, looks good. On Tue, May 30, 2023 at 9:35 PM Slawomir Jaranowski wrote: > > Hi, > > We solved 8 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824=12353136 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRELEASE%20AND%20resolution%20%3D%20Unresolved > > > Staging repo: > https://repository.apache.org/content/repositories/maven-1950/ > https://repository.apache.org/content/repositories/maven-1950/org/apache/maven/release/maven-release/3.0.1/maven-release-3.0.1-source-release.zip > > Source release checksum(s): > maven-release-3.0.1-source-release.zip - SHA-512: > e59018a70e67f8af38f4d02bc28703f54ec01d032bd9d21972d087bb196ed8997040da0600a687d5604ebed794ab444d67b697ae17f793f0e8908a4ca0a37f69 > > > Staging site: > https://maven.apache.org/components/maven-release-archives/maven-release-LATEST > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Surefire version 3.1.1
1. There are 42 open PRs including some dependabot ones. Can any of these be resolved quickly? 2. At least a few assorted dependencies are not up to date. The dependencies that are declared seem out of sync with what is and isn't used. I'll send some PRs. 3, On my JDK 8 Mac 11.7.5 system `mvn -Prun-its verify` fails like so: [INFO] SureFire JUnit Runner .. SUCCESS [ 2.020 s] [INFO] SureFire JUnit4 Runner . SUCCESS [ 1.934 s] [INFO] Maven Surefire Common .. FAILURE [ 3.248 s] [INFO] SureFire JUnitCore Runner .. SKIPPED [INFO] SureFire JUnit Platform Runner . SKIPPED [INFO] SureFire TestNG Utils .. SKIPPED [INFO] SureFire TestNG Runner . SKIPPED [INFO] ShadeFire JUnit3 Provider .. SKIPPED [INFO] Surefire Report Parser . SKIPPED [INFO] Maven Surefire Plugin .. SKIPPED [INFO] Maven Failsafe Plugin .. SKIPPED [INFO] Maven Surefire Report Plugin ... SKIPPED [INFO] Maven Surefire Integration Tests ... SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 58.608 s [INFO] Finished at: 2023-05-29T12:19:17-04:00 [INFO] [ERROR] Failed to execute goal org.jacoco:jacoco-maven-plugin:0.8.8:instrument (jacoco-instrumentation) on project maven-surefire-common: Unable to instrument file.: Error while instrumenting /Users/elharo/maven-surefire/maven-surefire-common/target/classes/org/apache/maven/plugin/surefire/SurefireDependencyResolver$RuntimeArtifactFilter.class with JaCoCo 0.8.8.202204050719/5dcf34a. -> [Help 1] [ERROR] This might be another case where a build can't run twice in a row. Running mvn clean first and then running the tests again shows different failures: [ERROR] - [ERROR] [INFO] - [INFO] Build Summary: [INFO] Passed: 1, Failed: 4, Errors: 0, Skipped: 0 [INFO] - [ERROR] The following builds failed: [ERROR] * jetty-war-test-failing/pom.xml [ERROR] * working-directory/pom.xml [ERROR] * jetty-war-test-passing/pom.xml [ERROR] * multiple-summaries/pom.xml On Sun, May 28, 2023 at 9:24 PM Michael Osipov wrote: > > Hi, > > we solved 9 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12353266 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1949/ > https://repository.apache.org/content/repositories/maven-1949/org/apache/maven/surefire/surefire/3.1.1/surefire-3.1.1-source-release.zip > > Source release checksum(s): > surefire-3.1.1-source-release.zip > sha512: > deb15c554f2c86814cc834de016e9c4559ab33233ed02fd1291bf5119e23bfd27b862f6876b6e0914f950f92e1893f62a41027a802d4df11cc30d146a91060d0 > > Staging site: > https://maven.apache.org/surefire-archives/surefire-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: GH issues and GH discussions
On Sat, May 27, 2023 at 6:11 AM Tamás Cservenák wrote: > In general, my intention with bringing up this on Slack was motivated by > following reasons: > - we do have ML (signup needed), > - we do have JIRA (ask + approval + signup needed), > Good points all around. It occurs to me that not that long ago, Jira used to be open signup. is there a specific reason it changed? Does that reason still apply? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Project Info Reports Plugin version 3.4.4
There's some dependency cleanup that could be done in this project. a couple of artifacts should be test scope and also updated to the latest versions, perhaps a few other things On Fri, May 26, 2023 at 3:29 PM Michael Osipov wrote: > > Hi, > > we solved 6 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12353222 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/projects/MPIR/issues > > Staging repo: > https://repository.apache.org/content/repositories/maven-1948/ > https://repository.apache.org/content/repositories/maven-1948/org/apache/maven/plugins/maven-project-info-reports-plugin/3.4.4/maven-project-info-reports-plugin-3.4.4-source-release.zip > > Source release checksum(s): > maven-project-info-reports-plugin-3.4.4-source-release.zip > sha512: > c5803f9c7165ca1277e2952bc04eb0b30d9d2b1972e89bb90ac0611ddf3c1062aaea964f4484ba45ecf7780a77ae141f7cd9773edd402c48ff19b8fc25e5344b > > Staging site: > https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is it okay to deploy additional artifacts for an identical POM? (as in MDEPLOY-118)
On Fri, May 26, 2023 at 4:18 AM Kemal Soysal wrote: > > Hi Mathias, > > I commented on the pull request. > For me it is crucial to be able to upload additional artifacts to a > coordinate. > It has various reasons. > When you work in an agile mind set, you do not need every artifact in the > very beginning. > You do approach agile and deliver first the most needed part. > In case you have a heterogenous development environment that you want to > provide with a native library > you deliver first your own machines native library…. > And then when needed the other machines will follow… That's fine, but it in no way implies the new artifacts have to be in the same version. New code --> new version. Each version should have fixed and immutable artifacts. > Another much forgotten usage of this additional artifact attachment is, when > for example a CVE to a coordinate comes up. > At the moment, there is a hard work to maintain the CVEs and related > coordinates. > It would be great to put a CVE where it belongs… to the coordinate itself > I don't understand what you're asking for here. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
maven-gpg-plugin CI broken
See https://github.com/apache/maven-gpg-plugin/pull/51 Verify / Verify / windows-latest jdk-8-temurin 3.9.2 (push) is broken Perhaps someone with relevant permissions can figure this one out. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Checkstyle Plugin version 3.3.0
On Sat, May 20, 2023 at 3:33 PM Gary Gregory wrote: > > Please don't change the default behavior to exclude test sources! > Non-binding -1 from me. > If you're referring to #76, that's not what it does. Test sources are still checked. What changes is that **generated code**, test and non-test alike, is not checked by default. An example would be Java code created when protoc compiles a .proto file. In this case the Java code is not hand-written and often doesn't follow other project conventions like line length. Furthermore it can't be fixed aside from changing the tool that generates the Java code. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Checkstyle Plugin version 3.3.0
https://github.com/apache/maven-checkstyle-plugin/pull/76 is in progress from an external developer and is, IMHO, a quite nice improvement. Might be worth waiting for this to be finished up. Otherwise, I found some minor issues in dependencies and the tests, but nothing blocking. On Fri, May 19, 2023 at 1:49 PM Michael Osipov wrote: > > Hi, > > we solved 4 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223=12353164 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project+%3D+MCHECKSTYLE+AND+resolution+%3D+Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1946/ > https://repository.apache.org/content/repositories/maven-1946/org/apache/maven/plugins/maven-checkstyle-plugin/3.3.0/maven-checkstyle-plugin-3.3.0-source-release.zip > > Source release checksum(s): > maven-checkstyle-plugin-3.3.0-source-release.zip > sha512: > c27aa2dbc287764e097ab044a2780fc52e1afcf4a00a93793156df285f6595ed327fca1638a566c7673b3221dd2b98ee4d6ff54d1e93c5963f95ea0f58018067 > > Staging site: > https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Shared Utils 3.4.2
+1 On Sat, May 13, 2023 at 2:15 AM Herve Boutemy wrote: > > +1 > > Reproducible Build ok: reference done with JDK 17 on *nix > > Regards, > > Hervé > > On 2023/05/11 21:01:02 Slawomir Jaranowski wrote: > > Hi, > > > > We solved 2 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12353197 > > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-utils > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1940/ > > https://repository.apache.org/content/repositories/maven-1940/org/apache/maven/shared/maven-shared-utils/3.4.2/maven-shared-utils-3.4.2-source-release.zip > > > > Source release checksum(s): > > maven-shared-utils-3.4.2-source-release.zip - SHA-512 : > > 9cd7e2d3cc4409644394acfb200d0a3f022f0890f2bd2bb814591624e5d2d481b308ba96f3903c2a8c02c4a805e6b85b903dd98d51e21768b1cf8b44d5c4b4b6 > > > > Staging site: > > https://maven.apache.org/shared-archives/maven-shared-utils-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > -- > > Sławomir Jaranowski > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven PMD Plugin version 3.21.0
An external developer contributed a patch for MPMD-371 a few days ago that seems worth a look before the next release is cut: https://github.com/apache/maven-pmd-plugin/pull/127 On Fri, May 12, 2023 at 4:30 PM Michael Osipov wrote: > > Hi, > > we solved 7 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12352863 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1942/ > https://repository.apache.org/content/repositories/maven-1942/org/apache/maven/plugins/maven-pmd-plugin/3.21.0/maven-pmd-plugin-3.21.0-source-release.zip > > Source release checksum(s): > maven-pmd-plugin-3.21.0-source-release.zip > sha512: > 05cf8bf31dd96485f7dc8473e0bc02387c1ec7e39fdbace04bb82167286f6ca1cff14a2623792eb3ef8c426050151244d6d03a3c43fffd9f41024677d4297edf > > Staging site: > https://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Change to the voting process
Honestly 72 hours is a little too little, especially if a weekend is involved, but 30 days feels way too much, especially if critical bug fixes or security issues are in play. (Hopefully rare but it does happen.) Sometimes we have more than one release in 30 days. Maybe 7 days, with some sort of emergency rip cord for critical issues? -1 on 30 days On Fri, May 12, 2023 at 5:33 AM Tamás Cservenák wrote: > > Howdy, > > I'd like to propose a change to the ASF Maven voting process (in line with > ASF guidelines): > CHANGE the current "vote open for at least 72h" window to "vote open for at > least 30 days, or more". > > Reasoning: > According to paperwork (ASF stats) we have more than 90 voters available > (PMCs + committers). > Still, multiple release votes recently were able to pass the "doorstep" > only by "hunting down" voters and pulling their sleeves (apologies and > thanks to them). This makes it clear that ONLY 72h is totally > anti-community and disrespectful. Nobody's sleeve should be pulled. That's > disrespectful for sleeves as well (except if you wear a T-shirt). We must > serve our project community in the best manner, and let our voters be able > to cast well thought votes in a timely manner, hence increasing the > irrationally short window of opportunity for casting votes IS A MUST. And > leave the sleeves alone. > > Sorry, but the vote is open for at least 72 hours ONLY. > > [ ] +1 > [ ] +0 > [ ] -1 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
another issue in Maven Resolver 1.9.9
This note got missed in discussion of other points, but digging in it's looking like at least two, possibly three different bugs: Also, does this really require exactly 3.8.4 (which would be a bug in resolver) or does it require 3.8.4 or later (which would be a bug in the RequireMavenVersion enforcer rule)? The two bugs I'm sure of are not in resolver, but the third might be. Still digging... -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Shared Utils 3.4.0
Dependencies look good in this release, but I do have several open PRs in this repo waiting for review. https://github.com/apache/maven-shared-utils/pull/133 is approved but waiting for @michael-o https://github.com/apache/maven-shared-utils/pull/136 is ready for review. It deprecates a couple of methods that should never have been public and which are arguably buggy. This PR should go out in this release to give any dependents (I hope there aren't any but there always are) maximum notice before we eventually remove them. https://github.com/apache/maven-shared-utils/pull/124 is one approach to addressing the bug in MSHARED-953 https://github.com/apache/maven-shared-utils/pull/125 is an alternate approach to addressing the bug in MSHARED-953 that comes closer to preserving the intended non-buggy behavior so it's worth considering these two together and picking one. They can't both go in. On Thu, Apr 27, 2023 at 8:03 PM Slawomir Jaranowski wrote: > > Hi, > > We solved 20 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12350135 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-utils > > Staging repo: > https://repository.apache.org/content/repositories/maven-1928/ > https://repository.apache.org/content/repositories/maven-1928/org/apache/maven/shared/maven-shared-utils/3.4.0/maven-shared-utils-3.4.0-source-release.zip > > Source release checksum(s): > maven-shared-utils-3.4.0-source-release.zip - SHA-512 : > 10d6c025f91fbdb5a472f9f72336fc78c291c1a377f5f8a86e82944b2201e0ed24e7949b86ff5466d17f783de1ffbc209be8b0b4a91f1c535cefbbc41cc6d116 > > Staging site: > https://maven.apache.org/shared-archives/maven-shared-utils-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 1.9.9
On Thu, Apr 27, 2023 at 6:52 AM Tamás Cservenák wrote: > > Thanks Elliotte! > > But allow me a bit of a rant here: > - You explicitly reported "on my personal and slightly more up to date > MacBook [...] [the test fails, hence am -1 on release]". > - Then it turns out, you use Maven 3.5.0 (from 2018, unmaintained). 3.5.0 was the corp Macbook. My personal MacBook is 3.8.7 atm. > - Then it turns out, you use Java 8u172 (from 2018, obviously outdated as > current Java 8 is u300-ish). > > All this caused a huge pollution to the voting thread. > > Personally, I don't care what downstream developers use (outdated Maven > and/or Java and even OS) to build their stuff, > but "at the source", where we produce Maven and related libraries for > downstream consumption, > we should be REALLY up to date. This is in OUR favor, just to make sure all > the known issues from our > tools can be excluded (or if new issues found, easier to find them), as > much as possible. I think that's likely to produce far more weird, hard-to-debug breakages of Maven on end users' machines. IMHO we are already far too aggressive in what we consider supported. The enterprise and big tech world simply does not upgrade that fast. For instance, 3.5.0 is what I had on my day job machine because that's what the package manager installs in 2023, not because it's the version I picked. There is a clear distinction between Maven itself and the plugins and libraries pulled in via a pom.xml. Maven is a tool installed on end users machines and is years out of date in many cases. Libraries published for consumption by builds through declarations in the pom.xml, and this includes plugins, should not be tightly coupled to the versions of tools installed on end user systems such as mvn and the JDK. It's the robustness principle in action, be conservative in what you send, be liberal in what you accept. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 1.9.9
After updating to openjdk version "1.8.0_372" OpenJDK Runtime Environment (build 1.8.0_372-bre_2023_04_25_03_25-b00) OpenJDK 64-Bit Server VM (build 25.372-b00, mixed mode) the tests now pass, so it does seem this is an issue with the JDK that made the keystore being newish. Only an issue for tests, so I'll upgrade my vote to +0 on this release. It would be nice to use a more broadly compatible format for the keystore. Given that the password is in clear text in the source code on Github, I'm truly not concerned about a theoretically inferior crypto algorithm being used for this file, but it's not a release blocker. On Wed, Apr 26, 2023 at 11:17 PM Elliotte Rusty Harold wrote: > > On Wed, Apr 26, 2023 at 11:06 PM Jeremy Landis > wrote: > > > > Without knowing more details myself, couple of possibilities come to mind... > > > > - Was keystore made with newer jdk? See > > https://support.oracle.com/knowledge/More%20Applications%20and%20Technologies/2847060_1.html. > > - Was the keystore filtered? > > > > Gut tells me it’s the first issue given how old 1.8.0_172 is (2018-04-17). > > > > Sounds possible. On the same MacBook I see > > $ keytool -list -keystore > maven-resolver-transport-http/src/test/resources/ssl/server-store-selfsigned > Enter keystore password: > keytool error: java.io.IOException: Invalid keystore format > > -- > Elliotte Rusty Harold > elh...@ibiblio.org -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 1.9.9
On Wed, Apr 26, 2023 at 11:06 PM Jeremy Landis wrote: > > Without knowing more details myself, couple of possibilities come to mind... > > - Was keystore made with newer jdk? See > https://support.oracle.com/knowledge/More%20Applications%20and%20Technologies/2847060_1.html. > - Was the keystore filtered? > > Gut tells me it’s the first issue given how old 1.8.0_172 is (2018-04-17). > Sounds possible. On the same MacBook I see $ keytool -list -keystore maven-resolver-transport-http/src/test/resources/ssl/server-store-selfsigned Enter keystore password: keytool error: java.io.IOException: Invalid keystore format -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 1.9.9
Stack traces from both failing tests look similar, specifically failing in
at
org.eclipse.aether.transport.http.HttpServer.addSslConnector(HttpServer.java:165)
at
org.eclipse.aether.transport.http.HttpServer.addSelfSignedSslConnector(HttpServer.java:143)
That seems to be thrown from here when the server starts up:
try {
httpsConnector.start();
} catch (Exception e) {
throw new IllegalStateException(e);
}
However, the real problem seems likely to be a few lines earlier:
if (needClientAuth) {
ssl.setNeedClientAuth(true);
ssl.setKeyStorePath(new
File("src/test/resources/ssl/server-store").getAbsolutePath());
ssl.setKeyStorePassword("server-pwd");
ssl.setTrustStorePath(new
File("src/test/resources/ssl/client-store").getAbsolutePath());
ssl.setTrustStorePassword("client-pwd");
} else {
ssl.setNeedClientAuth(false);
ssl.setKeyStorePath(new
File("src/test/resources/ssl/server-store-selfsigned").getAbsolutePath());
ssl.setKeyStorePassword("server-pwd");
}
Likely the issue is in the file src/test/resources/ssl/server-store-selfsigned
[ERROR] Tests run: 72, Failures: 0, Errors: 2, Skipped: 0, Time
elapsed: 2.415 s <<< FAILURE! - in
org.eclipse.aether.transport.http.HttpTransporterTest
[ERROR]
org.eclipse.aether.transport.http.HttpTransporterTest.testGet_HTTPS_Insecure_SecurityMode
Time elapsed: 0.015 s <<< ERROR!
java.lang.IllegalStateException: java.io.IOException: Invalid keystore format
at
org.eclipse.aether.transport.http.HttpServer.addSslConnector(HttpServer.java:165)
at
org.eclipse.aether.transport.http.HttpServer.addSelfSignedSslConnector(HttpServer.java:143)
at
org.eclipse.aether.transport.http.HttpTransporterTest.testGet_HTTPS_Insecure_SecurityMode(HttpTransporterTest.java:416)
On Wed, Apr 26, 2023 at 10:45 PM Elliotte Rusty Harold
wrote:
>
> here's my environment:
>
> ~/maven-fluido-skin$ mvn -version
> Apache Maven 3.8.7 (b89d5959fcde851dcb1c8946a785a163f14e1e29)
> Maven home: /opt/java/apache-maven-3.8.7
> Java version: 1.8.0_172, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> (base) ~/maven-fluido-skin$ java -version
> java version "1.8.0_172"
> Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)
>
> On Wed, Apr 26, 2023 at 6:05 PM Slawomir Jaranowski
> wrote:
> >
> > +1
> >
> > Build ok on:
> >
> > Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> > Java version: 17.0.7, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@17/17.0.7/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "mac os x", version: "12.6.3", arch: "x86_64", family: "mac"
> >
> >
> > śr., 26 kwi 2023 o 12:21 Tamás Cservenák napisał(a):
> >
> > > Howdy,
> > >
> > > We solved 2 issues (1 bug + 1 doco task):
> > >
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353151
> > >
> > > There are still some issues in JIRA:
> > > https://issues.apache.org/jira/projects/MRESOLVER/issues
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/maven-1923/
> > >
> > > Source release SHA512:
> > >
> > > 133ee4abe463fefe05ecf2da3b1cf9ad94192d6a1744041e4e4664fa447118e84a3a017351e9ae6c629598ea8eb81802dd34f71c5cdd99a46e311cd3c277512c
> > >
> > > Staging site:
> > > https://maven.apache.org/resolver-archives/resolver-LATEST/
> > >
> > > Guide to testing staged releases:
> > > https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> >
> >
> > --
> > Sławomir Jaranowski
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 1.9.9
here's my environment: ~/maven-fluido-skin$ mvn -version Apache Maven 3.8.7 (b89d5959fcde851dcb1c8946a785a163f14e1e29) Maven home: /opt/java/apache-maven-3.8.7 Java version: 1.8.0_172, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" (base) ~/maven-fluido-skin$ java -version java version "1.8.0_172" Java(TM) SE Runtime Environment (build 1.8.0_172-b11) Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode) On Wed, Apr 26, 2023 at 6:05 PM Slawomir Jaranowski wrote: > > +1 > > Build ok on: > > Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8) > Java version: 17.0.7, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.7/libexec/openjdk.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "12.6.3", arch: "x86_64", family: "mac" > > > śr., 26 kwi 2023 o 12:21 Tamás Cservenák napisał(a): > > > Howdy, > > > > We solved 2 issues (1 bug + 1 doco task): > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353151 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-1923/ > > > > Source release SHA512: > > > > 133ee4abe463fefe05ecf2da3b1cf9ad94192d6a1744041e4e4664fa447118e84a3a017351e9ae6c629598ea8eb81802dd34f71c5cdd99a46e311cd3c277512c > > > > Staging site: > > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 1.9.9
On Wed, Apr 26, 2023 at 11:18 AM Tamás Cservenák wrote: d to read at Elliotte workstation. > > Unsure what he tried to build in the first place, as it is possible that > source ZIP is corrupted, I have no idea. > But one thing for sure, if this is the case, then 1.9.8, 1.9.7, 1.9.6 > releases should be -1 according to him, as there is no change in 1.9.9 > related to anything in this area. Possibly. :-) I don't have time to check every release. I do what I can when I notice something. If I have time to dig into the failures I will, but I can't promise that, especially since i have to use a personal machine to build that I often don't have with me. One reason these failures might not be caught in the CI is that I'm using a Mac. Does the test matrix include MacOS or or only on Linux+Windows? I have found IT failures in the past that were traced down to idiosyncrasies of Mac file systems and the like. I don't consider the dependency issues blocking for this release. They're all pretty well understood and mostly in test code.However there are definitely some true positives in the list I posted. Guava in particular is declared more often than it's used, if it's used at all. It might not be. I'll look into that when I get a minute unless someone gets there first. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 1.9.9
The dependencies could also use a little cleanup, though treu positives are mostly test dependencies so this isn't too critical: [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-resolver-util --- [WARNING] Used undeclared dependencies found: [WARNING]org.hamcrest:hamcrest:jar:2.2:test [WARNING] Unused declared dependencies found: [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [WARNING] Unused declared dependencies found: [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [WARNING]org.mockito:mockito-core:jar:4.8.1:test [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-resolver-impl --- [WARNING] Unused declared dependencies found: [WARNING]com.google.guava:guava:jar:30.1-jre:runtime [WARNING]com.google.guava:failureaccess:jar:1.0.1:runtime [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-resolver-named-locks-hazelcast --- [WARNING] Unused declared dependencies found: [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test [WARNING] Non-test scoped test only dependencies found: [WARNING] org.apache.maven.resolver:maven-resolver-api:jar:1.9.10-SNAPSHOT:compile [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-resolver-named-locks-redisson --- [WARNING] Unused declared dependencies found: [WARNING]junit:junit:jar:4.13.2:test [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [WARNING]org.mockito:mockito-core:jar:4.8.1:test [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test [INFO] [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-resolver-connector-basic --- [WARNING] Unused declared dependencies found: [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test [WARNING]com.google.inject:guice:jar:5.1.0:test [WARNING]com.google.guava:guava:jar:30.1-jre:test [WARNING]com.google.guava:failureaccess:jar:1.0.1:test [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [INFO] [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-resolver-transport-classpath --- [WARNING] Unused declared dependencies found: [WARNING]com.google.inject:guice:jar:5.1.0:test [WARNING]com.google.guava:guava:jar:30.1-jre:test [WARNING]com.google.guava:failureaccess:jar:1.0.1:test [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [INFO] [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-resolver-transport-file --- [WARNING] Unused declared dependencies found: [WARNING]com.google.inject:guice:jar:5.1.0:test [WARNING]com.google.guava:guava:jar:30.1-jre:test [WARNING]com.google.guava:failureaccess:jar:1.0.1:test [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test [INFO] [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-resolver-transport-http --- [WARNING] Used undeclared dependencies found: [WARNING]org.eclipse.jetty:jetty-io:jar:9.4.49.v20220914:test [WARNING] Unused declared dependencies found: [WARNING]org.slf4j:jcl-over-slf4j:jar:1.7.36:runtime [WARNING]com.google.inject:guice:jar:5.1.0:test [WARNING]com.google.guava:guava:jar:30.1-jre:test [WARNING]com.google.guava:failureaccess:jar:1.0.1:test [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test [INFO] [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-resolver-transport-wagon --- [WARNING] Unused declared dependencies found: [WARNING]com.google.inject:guice:jar:5.1.0:test [WARNING]com.google.guava:guava:jar:30.1-jre:test [WARNING]com.google.guava:failureaccess:jar:1.0.1:test [WARNING]org.hamcrest:hamcrest-core:jar:2.2:test [WARNING]org.slf4j:slf4j-simple:jar:1.7.36:test [INFO] On Wed, Apr 26, 2023 at 11:56 AM Elliotte Rusty Harold wrote: > > And on my personal and slightly more up to date MacBook mvn -Prun-its > test reveals: > > [ERROR] Errors: > [ERROR] HttpTransporterTest.testGet_HTTPS_Insecure_SecurityMode:416 > » IllegalState java.io.IOException: Invalid keystore format > [ERROR] HttpTransporterTest.testGet_HTTPS_Unknown_SecurityMode:401 » > IllegalState java.io.IOException: Invalid keystore format > [INFO] > > I don't have time to dig into this right now, but atm this is enough > for me to vote -1. > > > > On Wed, Apr 26, 2023 at 11:35 AM Elliotte Rusty Harold > wrote: > > > > The weekly reminder that the world is not nearly as up to date as we might > > like: > > > > [ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireMavenVersion > > failed with message: > > Detected Maven Version: 3.5.0 is not in the allowed range 3.8.4. > > > > This is from a f
Re: [VOTE] Release Maven Resolver 1.9.9
And on my personal and slightly more up to date MacBook mvn -Prun-its test reveals: [ERROR] Errors: [ERROR] HttpTransporterTest.testGet_HTTPS_Insecure_SecurityMode:416 » IllegalState java.io.IOException: Invalid keystore format [ERROR] HttpTransporterTest.testGet_HTTPS_Unknown_SecurityMode:401 » IllegalState java.io.IOException: Invalid keystore format [INFO] I don't have time to dig into this right now, but atm this is enough for me to vote -1. On Wed, Apr 26, 2023 at 11:35 AM Elliotte Rusty Harold wrote: > > The weekly reminder that the world is not nearly as up to date as we might > like: > > [ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireMavenVersion > failed with message: > Detected Maven Version: 3.5.0 is not in the allowed range 3.8.4. > > This is from a fully up-to-date corp managed MacBook with the version > of Maven installed by homebrew. > > Also, does this really require exactly 3.8.4 (which would be a bug in > resolver) or does it require 3.8.4 or later (which would be a bug in > the RequireMavenVersion enforcer rule)? > > > On Wed, Apr 26, 2023 at 6:21 AM Tamás Cservenák wrote: > > > > Howdy, > > > > We solved 2 issues (1 bug + 1 doco task): > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353151 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-1923/ > > > > Source release SHA512: > > 133ee4abe463fefe05ecf2da3b1cf9ad94192d6a1744041e4e4664fa447118e84a3a017351e9ae6c629598ea8eb81802dd34f71c5cdd99a46e311cd3c277512c > > > > Staging site: > > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver 1.9.9
The weekly reminder that the world is not nearly as up to date as we might like: [ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireMavenVersion failed with message: Detected Maven Version: 3.5.0 is not in the allowed range 3.8.4. This is from a fully up-to-date corp managed MacBook with the version of Maven installed by homebrew. Also, does this really require exactly 3.8.4 (which would be a bug in resolver) or does it require 3.8.4 or later (which would be a bug in the RequireMavenVersion enforcer rule)? On Wed, Apr 26, 2023 at 6:21 AM Tamás Cservenák wrote: > > Howdy, > > We solved 2 issues (1 bug + 1 doco task): > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353151 > > There are still some issues in JIRA: > https://issues.apache.org/jira/projects/MRESOLVER/issues > > Staging repository: > https://repository.apache.org/content/repositories/maven-1923/ > > Source release SHA512: > 133ee4abe463fefe05ecf2da3b1cf9ad94192d6a1744041e4e4664fa447118e84a3a017351e9ae6c629598ea8eb81802dd34f71c5cdd99a46e311cd3c277512c > > Staging site: > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Plugin Tools 3.8.2
The world won't burn down in fire if we wait to merge things, but generally before cutting a release it's nice to bring all the dependencies up to date and do a run through of outstanding pull requests and JIRA issues to see if any can be quickly addressed. Overall pre-release is a good Schelling point for doing necessary house cleaning, assuming there's no critical reason a release has to push today instead of next week. Indeed I can make an argument that right before a release is the best time for updating dependencies. Do it any earlier and you're likely to do unnecessary extra work as dependencies with faster release cycles get updated several times instead of just once. On Wed, Apr 19, 2023 at 1:14 PM Slawomir Jaranowski wrote: > > śr., 19 kwi 2023 o 13:57 Elliotte Rusty Harold > napisał(a): > > > -1 > > > > I suggest merging #207 and the just filed #208 first. > > > > > I can merge #208 and fix documentation in the current release as it is so > important - but I would prefer it for the next release. > We have had such text for a long time - so now it should not be the > reason to block release. > > What is so important in #207? > > > > > > On Tue, Apr 18, 2023 at 4:32 PM Slawomir Jaranowski > > wrote: > > > > > > Hi, > > > > > > We solved 10 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12352508 > > > > > > There are still a couple of issues left in JIRA: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20resolution%20%3D%20Unresolved > > > > > > Staging repo: > > > https://repository.apache.org/content/repositories/maven-1921/ > > > > > https://repository.apache.org/content/repositories/maven-1921/org/apache/maven/plugin-tools/maven-plugin-tools/3.8.2/maven-plugin-tools-3.8.2-source-release.zip > > > > > > Source release checksum(s): > > > maven-plugin-tools-3.8.2-source-release.zip - SHA-512 : > > > > > 96c0ec526bc1b8d87927d0b7945d7817f33e2c687548de679491f70ec87c61319ff226c18e008faafa8492cdb0711ba281465dbaf56ce056b23ee4874bf32685 > > > > > > Staging site: > > > > > https://maven.apache.org/components/plugin-tools-archives/plugin-tools-LATEST/ > > > > > > Guide to testing staged releases: > > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > > > Vote open for at least 72 hours. > > > > > > [ ] +1 > > > [ ] +0 > > > [ ] -1 > > > > > > -- > > > Sławomir Jaranowski > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Plugin Tools 3.8.2
[WARNING]org.apache.maven.reporting:maven-reporting-api:jar:3.1.1:compile [WARNING] Unused declared dependencies found: [WARNING] org.apache.maven.plugin-tools:maven-plugin-tools-java:jar:3.8.3-SNAPSHOT:runtime [WARNING] org.apache.maven.plugin-tools:maven-plugin-tools-annotations:jar:3.8.3-SNAPSHOT:runtime [WARNING] org.apache.maven.plugin-tools:maven-plugin-tools-ant:jar:3.8.3-SNAPSHOT:runtime [WARNING] org.apache.maven.plugin-tools:maven-plugin-tools-beanshell:jar:3.8.3-SNAPSHOT:runtime [WARNING]org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1:compile [WARNING]org.junit.jupiter:junit-jupiter:jar:5.9.2:test [WARNING] org.apache.maven.plugin-tools:maven-script-beanshell:jar:3.8.3-SNAPSHOT:test [WARNING] org.apache.maven.plugin-tools:maven-script-ant:jar:3.8.3-SNAPSHOT:test [INFO] --- maven-dependency-plugin:3.4.0:analyze (default-cli) @ maven-plugin-report-plugin --- [WARNING] Used undeclared dependencies found: [WARNING]org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.5:provided [WARNING] Unused declared dependencies found: [WARNING]org.apache.maven:maven-artifact:jar:3.2.5:provided [WARNING] org.apache.maven.plugins:maven-plugin-plugin:jar:3.8.3-SNAPSHOT:test On Wed, Apr 19, 2023 at 11:56 AM Elliotte Rusty Harold wrote: > > -1 > > I suggest merging #207 and the just filed #208 first. > > > > On Tue, Apr 18, 2023 at 4:32 PM Slawomir Jaranowski > wrote: > > > > Hi, > > > > We solved 10 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12352508 > > > > There are still a couple of issues left in JIRA: > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20resolution%20%3D%20Unresolved > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1921/ > > https://repository.apache.org/content/repositories/maven-1921/org/apache/maven/plugin-tools/maven-plugin-tools/3.8.2/maven-plugin-tools-3.8.2-source-release.zip > > > > Source release checksum(s): > > maven-plugin-tools-3.8.2-source-release.zip - SHA-512 : > > 96c0ec526bc1b8d87927d0b7945d7817f33e2c687548de679491f70ec87c61319ff226c18e008faafa8492cdb0711ba281465dbaf56ce056b23ee4874bf32685 > > > > Staging site: > > https://maven.apache.org/components/plugin-tools-archives/plugin-tools-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > -- > > Sławomir Jaranowski > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Plugin Tools 3.8.2
-1 I suggest merging #207 and the just filed #208 first. On Tue, Apr 18, 2023 at 4:32 PM Slawomir Jaranowski wrote: > > Hi, > > We solved 10 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317820=12352508 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPLUGIN%20AND%20resolution%20%3D%20Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1921/ > https://repository.apache.org/content/repositories/maven-1921/org/apache/maven/plugin-tools/maven-plugin-tools/3.8.2/maven-plugin-tools-3.8.2-source-release.zip > > Source release checksum(s): > maven-plugin-tools-3.8.2-source-release.zip - SHA-512 : > 96c0ec526bc1b8d87927d0b7945d7817f33e2c687548de679491f70ec87c61319ff226c18e008faafa8492cdb0711ba281465dbaf56ce056b23ee4874bf32685 > > Staging site: > https://maven.apache.org/components/plugin-tools-archives/plugin-tools-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Plugin Tools 3.8.2
On Tue, Apr 18, 2023 at 5:18 PM Delany wrote: > > "The Maven Plugin Tools contains the necessary tools to generate > rebarbative content like descriptor, help and documentation." > Rebarbative means unattractive and objectionable. Bleah: https://github.com/apache/maven-plugin-tools/pull/208 -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Checkstyle Plugin version 3.2.2
-1 dependabot has surfaced multiple easy dependency upgrades that should be merged first, and we really should move the parent pom to 39 On Tue, Apr 18, 2023 at 11:09 AM Michael Osipov wrote: > > Hi, > > We solved 3 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223=12352856 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project+%3D+MCHECKSTYLE+AND+resolution+%3D+Unresolved > > Staging repo: > https://repository.apache.org/content/repositories/maven-1920/ > https://repository.apache.org/content/repositories/maven-1920/org/apache/maven/plugins/maven-checkstyle-plugin/3.2.2/maven-checkstyle-plugin-3.2.2-source-release.zip > > Source release checksum(s): > maven-checkstyle-plugin-3.2.2-source-release.zip > sha512: > a8c41392ecd99f3fbbfb3dbb94b10c8ee2bcb13ee45720b0a921c8896091c369f66e1bcbad0e9b1605a847d2a67956d117caca2c33158271923c1cb490f49210 > > Staging site: > https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [HEADS UP] ASF/Maven parent poms
Several of these seem like small red flags to me and while individually each might be manageable, put them all together and I vote for staying on 39 for a while longer. I'd also prefer that we complete upgrading the ~80 projects we maintain to Java 8, Maven 3.2.5, and parent pom 39 before we start moving some projects beyond that. That is, finish the work at hand before committing to new work. Finally, I think we need to reduce the manual labor and bureaucracy associated with small upgrades. Nit picking commit history and JIRA issues dramatically slows progress. As currently conceived, we do not have the resources to do the upgrades we've already promised. We either have to take work off the table so this can move faster or find more resources to do the work. Two concrete proposals for speeding up progress: 1. Ignore the commit history. PRs are the source of truth. Configure all repos to allow squash merges only. Anything more granular than that is too rarely helpful in practice to be worth the lost time. 2. Stop filing and requiring JIRA issues for dependency updates. Instead use maven-dependency-analyzer tooling to directly compare poms between releases and insert that into release notes. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven Dependency Analyzer 1.13.1
+1 On Wed, Apr 12, 2023 at 2:14 PM Slawomir Jaranowski wrote: > > Hi, > > We solved 8 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12352232 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-dependency-analyzer > > Staging repo: > https://repository.apache.org/content/repositories/maven-1914/ > https://repository.apache.org/content/repositories/maven-1914/org/apache/maven/shared/maven-dependency-analyzer/1.13.1/maven-dependency-analyzer-1.13.1-source-release.zip > > Source release checksum(s): > maven-dependency-analyzer-1.13.1-source-release.zip - SHA-512 : > e36a2c54f67a546eb3ff214b6b369385b8d807130c6e1aff85df630575544fa75d6e48572fdf408a5a6c2677bdc9ea5a7500ea39e37d1fc2b6c239ad13c696df > > Staging site: > https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > -- > Sławomir Jaranowski -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Upcoming Maven Resolver 1.9.8
I think so, assuming there's a new cut On Wed, Apr 5, 2023 at 11:58 AM Tamás Cservenák wrote: > > Eliotte, > > I hope all your concerns are addressed. > Please approve PR if so, and with that, assume you "lifted" your -1 :) > > Thanks > T > > On Wed, Apr 5, 2023 at 1:35 PM Guillaume Nodet wrote: > > > I've raised a new PR to re-deprecate StringUtils and inline it's usages: > > > > https://github.com/apache/maven-resolver/pull/277 > > > > Le mer. 5 avr. 2023 à 13:30, Elliotte Rusty Harold a > > écrit : > > > > > That's still a halfway measure. And we shouldn't move the public > > > StringUtils package without a deprecation cycle anyway. This is public > > > API that can be used in projects that are not part of this repo or the > > > Apache Maven project. So I propose: > > > > > > 1. Keep StringUtils in deprecated form for now, to be removed later, > > > possibly in a major version update. > > > 2. Replace usages of StringUtils with JDK methods. > > > > > > On Wed, Apr 5, 2023 at 7:23 AM Tamás Cservenák > > > wrote: > > > > > > > > I agree with you regarding duplication, this really adds "yet another" > > > > StringUtils to classpath. > > > > > > > > OTOH, I do see a value to drop non trivial (by size) dependency for > > > sparse > > > > use. > > > > > > > > How about this proposal: > > > > given un-deprecated StringUtils is used ONLY in (and below) > > > > package org.eclipse.aether.internal.impl MOVE the StringUtils to this > > > > package. So to say, make it resolver "internal thing", and not "offer" > > it > > > > via org.eclipse.aether.util package to anyone. I know this would not > > > > prevent use of it outside of the resolver, but if anyone uses it, he > > > would > > > > clearly violate [1] and is left "on his own". > > > > > > > > [1] > > > > > > > > > https://maven.apache.org/resolver/api-compatibility.html#package-level-contracts > > > > > > > > T > > > > > > > > On Wed, Apr 5, 2023 at 1:13 PM Elliotte Rusty Harold < > > elh...@ibiblio.org > > > > > > > > wrote: > > > > > > > > > I'm -1 on this release. I specifically disagree with the > > undeprecation > > > > > of > > > > > > > > > > maven-resolver-util/src/main/java/org/eclipse/aether/util/StringUtils.java > > > > > in https://github.com/apache/maven-resolver/pull/275 > > > > > > > > > > We need fewer duplicate StringUtils classes in random packages, not > > > > > more of them. If we don't want to depend on commons-lang3 then the > > use > > > > > can be replaced with JDK methods rather than by introducing yet > > > > > another StringUtils class. > > > > > > > > > > > > > > > On Wed, Apr 5, 2023 at 7:05 AM Tamás Cservenák > > > > > wrote: > > > > > > > > > > > > Howdy, > > > > > > > > > > > > The Resolver 1.9.8 is done: > > > > > > > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.8 > > > > > > > > > > > > If anyone has/knows/feels there is more to be done in 1.9.8, yell > > > here > > > > > > please. > > > > > > > > > > > > Also, if anyone has free cycles, and this mail has no "more to be > > > done" > > > > > > response in 24h, feel free to release 1.9.8. Otherwise I will do it > > > in > > > > > the > > > > > > 2nd half of next week. > > > > > > > > > > > > The 1.9.8 release should solve last "known issues" for Maven 3.9.x > > > (azure > > > > > > and locking timeouts), so it will be followed by Maven 3.9.2 > > release. > > > > > > > > > > > > Thanks > > > > > > T > > > > > > > > > > > > > > > > > > > > -- > > > > > Elliotte Rusty Harold > > > > > elh...@ibiblio.org > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > -- > > > Elliotte Rusty Harold > > > elh...@ibiblio.org > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > -- > > > > Guillaume Nodet > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Upcoming Maven Resolver 1.9.8
That's still a halfway measure. And we shouldn't move the public StringUtils package without a deprecation cycle anyway. This is public API that can be used in projects that are not part of this repo or the Apache Maven project. So I propose: 1. Keep StringUtils in deprecated form for now, to be removed later, possibly in a major version update. 2. Replace usages of StringUtils with JDK methods. On Wed, Apr 5, 2023 at 7:23 AM Tamás Cservenák wrote: > > I agree with you regarding duplication, this really adds "yet another" > StringUtils to classpath. > > OTOH, I do see a value to drop non trivial (by size) dependency for sparse > use. > > How about this proposal: > given un-deprecated StringUtils is used ONLY in (and below) > package org.eclipse.aether.internal.impl MOVE the StringUtils to this > package. So to say, make it resolver "internal thing", and not "offer" it > via org.eclipse.aether.util package to anyone. I know this would not > prevent use of it outside of the resolver, but if anyone uses it, he would > clearly violate [1] and is left "on his own". > > [1] > https://maven.apache.org/resolver/api-compatibility.html#package-level-contracts > > T > > On Wed, Apr 5, 2023 at 1:13 PM Elliotte Rusty Harold > wrote: > > > I'm -1 on this release. I specifically disagree with the undeprecation > > of > > maven-resolver-util/src/main/java/org/eclipse/aether/util/StringUtils.java > > in https://github.com/apache/maven-resolver/pull/275 > > > > We need fewer duplicate StringUtils classes in random packages, not > > more of them. If we don't want to depend on commons-lang3 then the use > > can be replaced with JDK methods rather than by introducing yet > > another StringUtils class. > > > > > > On Wed, Apr 5, 2023 at 7:05 AM Tamás Cservenák > > wrote: > > > > > > Howdy, > > > > > > The Resolver 1.9.8 is done: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.8 > > > > > > If anyone has/knows/feels there is more to be done in 1.9.8, yell here > > > please. > > > > > > Also, if anyone has free cycles, and this mail has no "more to be done" > > > response in 24h, feel free to release 1.9.8. Otherwise I will do it in > > the > > > 2nd half of next week. > > > > > > The 1.9.8 release should solve last "known issues" for Maven 3.9.x (azure > > > and locking timeouts), so it will be followed by Maven 3.9.2 release. > > > > > > Thanks > > > T > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Upcoming Maven Resolver 1.9.8
I'm -1 on this release. I specifically disagree with the undeprecation of maven-resolver-util/src/main/java/org/eclipse/aether/util/StringUtils.java in https://github.com/apache/maven-resolver/pull/275 We need fewer duplicate StringUtils classes in random packages, not more of them. If we don't want to depend on commons-lang3 then the use can be replaced with JDK methods rather than by introducing yet another StringUtils class. On Wed, Apr 5, 2023 at 7:05 AM Tamás Cservenák wrote: > > Howdy, > > The Resolver 1.9.8 is done: > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.8 > > If anyone has/knows/feels there is more to be done in 1.9.8, yell here > please. > > Also, if anyone has free cycles, and this mail has no "more to be done" > response in 24h, feel free to release 1.9.8. Otherwise I will do it in the > 2nd half of next week. > > The 1.9.8 release should solve last "known issues" for Maven 3.9.x (azure > and locking timeouts), so it will be followed by Maven 3.9.2 release. > > Thanks > T -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Radical Fast Forward to 3.6.3
On Fri, Mar 31, 2023 at 3:17 AM Olivier Lamy wrote: > > LGTM > It should be linked to core version support. > Might need some update of https://maven.apache.org/docs/history.html > maybe we should write some policy such we support only last version of > 3 last main branches (e,g reached GA): > > - 3.6.x > - 3.8.x > - 3.9.x There's at least one plugin that's not at 3.2.5 minimum yet, maybe more. I haven't seen anything earlier than 3.3 in years, so I think we can safely move to 3.3 minimum, and *maybe* 3.5. However only the last three major versions is far too aggressive. There are still a lot of random package managers out there that don't update very fast, if at all. E.g. someone on Mac OS Catalina 10.15.7 will get no further updates unless they directly install Maven instead of using HomeBrew, and I have at least one Mac that's stuck on 10.14. I'm not sure what Maven version Homebrew installs there. Core developers and people who use Maven all day, every day will install it from Apache, but there are a lot of folks out there who just pull it out once or twice a year when they need it, or when some random package requires it. They're not necessarily even fulltime or professional programmers. The most recent version I've seen a package manager install is 3.6.3. We've heard on this list from people who can't upgrade past 3.7 or 3.8 due to unexpected behavior changes and bugs that impacted them. And what happens when there's the next critical security vulnerability in some logging framework or I/O package? Do we tell these users they have to upgrade everything all at once to fix it? 3.5.4 is advanced enough. The community isn't ready to move further. -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Partial breakage in maven-stage-plugin CI: No GitHub app credentials found
Not necessarily, but if so we need to clear it out, not waste people's attention on this. Who can archive the repo and the issue tracker? On Fri, Mar 31, 2023 at 9:07 AM Michael Osipov wrote: > > Am 2023-03-30 um 13:52 schrieb Elliotte Rusty Harold: > > The maven-stage-plugin Jenkins job has some apparently widespread > > failures that seem likely to be the result of some sort of > > misconfiguration on the Jenkins job. This happens on only some members > > of the test matrix, but it does appear to be consistent and > > repeatable, not flaky. > > This plugin is dead and not useful these days. I just requires a formal > retired vote. > Don't waste your cycles for this. > > Do you think otherwise? > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Partial breakage in maven-stage-plugin CI: No GitHub app credentials found
The maven-stage-plugin Jenkins job has some apparently widespread failures that seem likely to be the result of some sort of misconfiguration on the Jenkins job. This happens on only some members of the test matrix, but it does appear to be consistent and repeatable, not flaky. Recording test results [GitHub Checks] Causes for no suitable publisher found: [GitHub Checks] Trying to resolve checks parameters from GitHub SCM... [GitHub Checks] No GitHub app credentials found: '5f95d117-af3b-452a-9e5c-4bddb22a67f4' [GitHub Checks] See: https://github.com/jenkinsci/github-branch-source-plugin/blob/master/docs/github-app.adoc [GitHub Checks] Trying to resolve checks parameters from Git SCM... [GitHub Checks] Job does not use Git SCM [Checks API] No suitable checks publisher found. See, for one example, https://github.com/apache/maven-stage-plugin/pull/7 Does this look familiar to anyone? Anyone know how to fix this? -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Deprecate maven-shared-utils
I've been working on this, here and there as time permits, as have others. I think there are a number of issues already filed. I've deprecated a lot of individual methods. Indeed I have an open PR to deprecate a couple more that can be merged as soon as someone approves: https://github.com/apache/maven-shared-utils/pull/136 Some pieces are easier than others. The IO and StringUtils can pretty much all go at this point. A lot of that can be replaced by pure JDK methods in any Java 8+ VM. The CLI, introspection, and logging libraries are perhaps trickier. @timtebeek has recently started using some really interesting automated tooling to fix some of this in bulk without a lot of the manual grunt work normally required. E.g. https://github.com/apache/maven-doxia/pull/156/files Send more PRs my way. :-) On Tue, Mar 28, 2023 at 2:18 PM Konrad Windszus wrote: > > Hi, > The initial goal of maven-shared-utils from > https://maven.apache.org/shared/maven-shared-utils/ was never reached as > plexus-utils was never decommissioned but rather received most attention in > the past. > Lots of new bugfixes only ended up in plexus-utils and were never backported > to maven-shared-utils. > Given that I would propose to officially deprecated maven-shared-utils and > instead recommend using either plexus-utils or Apache Commons libraries (IO, > Lang3, …). > Afterwards we should get rid of all dependencies towards it from all Maven > Plugins and Core. > > Currently we have the unfortunate situation that the code is duplicated > without a clear way forward. > The only feature which is not found in plexus-utils is > https://maven.apache.org/shared/maven-shared-utils/apidocs/org/apache/maven/shared/utils/logging/package-summary.html > but that has been added to Maven 4 API meanwhile and potentially can be > easily added to plexus utils. > > WDYT? > > Konrad > -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
