Howdy, For start, let me apologize for my harsh email on the vote thread addressing David.
And let me explain: when I said "spam", I did not mean the "unsolicited" (bug-report) side, but the "volume side", as in copy paste of the fancied/formatted LLM output to a text-only ML is just that. Instead of saying (maybe not on a vote thread, but by starting a new one) "my local LLM found 15 bugs", then pasting verbatim all the markdown, without some "preprocessing", editing, cleaning, is really annoying. And finally, this is regularly happening with Elliotte, even before LLMs. Voting -1 on releases, derailing threads, that ended up setting up enforcer rules on several projects (to prevent users assuming what "fairly recent" means). Here is my personal favorite: https://lists.apache.org/thread/k8fv1r5dzo6f6l8w3d233n7w7rnnscd6 This was a vote thread that received -1, as he was unable to build Resolver with "fairly up to date" Maven and Java, just to turn out, both versions he used were from 2018, while this vote happened in 2023. Ironically, the vote was canceled, but for totally different reasons. T On Thu, 2 Jul 2026 at 07:08, Romain Manni-Bucau <[email protected]> wrote: > > Hi, > > think there are multiple sides of the comments: > > * this is a vote thread not a review thread, means that if you do care you > should have reviewed it before. There I do also read that using slack to > announce release is wrong at ASF and it is worth a mail instead where such > discussions should happen. > * When using a LLM - in particular a coder agent like opencode > ** you can get fixes for all findings > ** you should also ask the LLM if what he found is right (sometimes he > realises he is wrong when guided a bit) > * Think before posting an ultra verbose comment is to review it - run sonar > full profile rules on any maven project and send the report on the list, > not sure it would be welcomed ;) > > So overall nothing is strictly wrong except the fact it was done in a vote > thread and was just "give a random ball to others" IMHO, we're still > learning how to integrate these convenient tools so we'll make it better > next time :). > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | > Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> > Javaccino founder (Java/.NET service - contact via linkedin) > > > ---------- Forwarded message --------- > De : David Jencks <[email protected]> > Date: jeu. 2 juil. 2026 à 05:05 > Subject: Re: [VOTE] Release Maven Resolver 2.0.20 > To: Maven Developers List <[email protected]> > > > I looked at the bugs filed from LLM, and although I can’t judge several of > them since I don’t know anything about maven code, I can say with > confidence that I wish this tool had been available when I was actually > working on software. I spent enormous amounts of time finding problems like > these and fixing them. This would have made my life much pleasanter. > > I don’t see where anyone said the list Elliotte posted in this thread is > mostly spam. It looks to me that Guillaume said 3 out of 15 were invalid. > > I’ll shut up now. > David Jencks > Sent from my iPhone > > > On Jul 1, 2026, at 1:12 PM, Tamás Cservenák <[email protected]> wrote: > > > > I'm sorry David, but you are wrong on several points. > > > > Eliotte maybe has no infinite amount of time to work on Maven, but > > whatever "triggers" him, he could find a more appropriate time and > > place to expose what he found while "looking around" than a voting > > thread, like for example a new thread on ML. > > Second, I neither have an infinite amount of time to work on Maven, > > but he just started spamming, seeing repositories having A LOT of > > issues created by him... I certainly will not triage these, as others > > said on this list, this is _mostly spam_. > > > > https://github.com/apache/maven-help-plugin/issues > > https://github.com/apache/maven-shared-utils/issues > > > > Is this familiar to you from somewhere? > > > > Thanks > > T > > > >> On Tue, 30 Jun 2026 at 23:18, David Jencks <[email protected]> > wrote: > >> > >> I don’t actually work on maven, so feel free to discount my opinion. I > don’t really understand your point of view. I doubt Elliotte has an > infinite amount of time to work on maven, so I think he takes vote threads > as a trigger to look around for possible problems and improvements in the > release candidate and generally asks, “are any of these important enough to > redo the release?” While this might seem annoying or distracting, upon > reflection I think this is a valuable contribution. While I think this is > the first time he’s used AI to look for problems, I think it’s conceptually > similar to many of his past posts on vote threads. > >> > >> David Jencks > >> Sent from my iPhone > >> > >>>> On Jun 30, 2026, at 1:33 PM, Hervé Boutemy <[email protected]> wrote: > >>> > >>> one day, you'll have to learn what voting means: such work is useful > for next release, not in a vote thread > >>> > >>>> On 2026/06/30 13:00:20 Elliotte Rusty Harold wrote: > >>>> Another grab bag of bugs the LLM found. At first glance, none of these > >>>> look too serious though: > >>>> > >>>> # Bug Analysis: maven-resolver > >>>> > >>>> Generated by code analysis of `/Users/elharo/maven-resolver` > (v2.0.21-SNAPSHOT). > >>>> > >>>> --- > >>>> > >>>> ## HIGH Severity > >>>> > >>>> ### 1. NPE — `getClassLoader().getResource()` returns null > >>>> **File:** > `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:265` > >>>> > >>>> ```java > >>>> String url = clazz.getClassLoader().getResource(className).toString(); > >>>> ``` > >>>> > >>>> `ClassLoader.getResource()` returns `null` when the resource is not > >>>> found, and `getClassLoader()` returns `null` for classes loaded by the > >>>> bootstrap class loader. Either condition causes an NPE on > >>>> `.toString()`. The method `getJarPath()` is called during client > >>>> initialization to build the classpath for forking a child process. > >>>> > >>>> ### 2. NPE — `receive()` reads volatile `input` without synchronization > >>>> **File:** > `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:288-311` > >>>> > >>>> ```java > >>>> void receive() { > >>>> try { > >>>> while (true) { > >>>> int id = input.readInt(); // NPE here if input null > >>>> ``` > >>>> > >>>> `input` is a volatile field (line 86). `receive()` reads it without > >>>> holding the `IpcClient` monitor. Meanwhile, `close(Throwable)` (line > >>>> 351, `synchronized`) sets `input = null` (line 360). Between the > >>>> volatile read at line 291 and the `input.readInt()` call, another > >>>> thread can call `close()`, nulling `input`. The same pattern applies > >>>> to `send()` at line 316 with `output`. > >>>> > >>>> ### 3. NPE — `getAddress()` can NPE on `socket.getLocalAddress()` > >>>> **File:** > `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:447-453` > >>>> > >>>> ```java > >>>> private String getAddress() { > >>>> try { > >>>> return SocketFamily.toString(socket.getLocalAddress()); > >>>> } catch (IOException e) { > >>>> return "[not bound]"; > >>>> } > >>>> } > >>>> ``` > >>>> > >>>> `socket` is volatile (line 84) and set to `null` in `close()` (line > >>>> 359). If `close()` runs concurrently with `toString()` (which calls > >>>> `getAddress()`), `socket` is null and `socket.getLocalAddress()` > >>>> throws NPE, which is **not** an `IOException` and is thus uncaught. > >>>> > >>>> ### 4. Resource leak — `BufferedReader` never closed in > `parseMultiResource()` > >>>> **File:** > `maven-resolver-test-util/src/main/java/org/eclipse/aether/internal/test/util/DependencyGraphParser.java:161` > >>>> > >>>> ```java > >>>> BufferedReader reader = new BufferedReader(new > >>>> InputStreamReader(res.openStream(), StandardCharsets.UTF_8)); > >>>> ``` > >>>> > >>>> The `BufferedReader` (and its underlying `InputStream`) is **never > >>>> closed**. If `parse(reader)` throws an IOException, the stream leaks. > >>>> Compare with the correctly-implemented `parse(URL)` method at line > >>>> 174-188 which uses try-finally. > >>>> > >>>> --- > >>>> > >>>> ## MEDIUM Severity > >>>> > >>>> ### 5. Catching `Throwable` in non-framework code > >>>> **File:** > `maven-resolver-transport-jetty/src/main/java/org/eclipse/aether/transport/jetty/PutTaskRequestContent.java:246, > >>>> 298` > >>>> > >>>> ```java > >>>> } catch (Throwable t) { > >>>> lockedSetTerminal(Content.Chunk.from(t, true)); > >>>> } > >>>> ``` > >>>> > >>>> Catches `OutOfMemoryError`, `StackOverflowError`, `InternalError`, > >>>> etc. These should propagate. Wrapping them as terminal chunks converts > >>>> fatal JVM errors into regular failure conditions, making them > >>>> invisible to diagnostics. > >>>> > >>>> ### 6. Production error logging to `System.out` > >>>> **File:** > `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcServer.java:196` > >>>> > >>>> ```java > >>>> private static void error(String msg, Throwable t) { > >>>> System.out.println("[ipc] [error] " + msg); > >>>> t.printStackTrace(System.out); > >>>> } > >>>> ``` > >>>> > >>>> All errors in the IPC server go to stdout instead of a proper logging > >>>> framework (SLF4J). In a production Maven build, these messages are > >>>> invisible or interleaved with build output. Same issue for `debug()` > >>>> (line 184) and `info()` (line 190) in the same file. > >>>> > >>>> ### 7. Listener RuntimeException silently swallowed by default > >>>> **Files:** > >>>> - > `maven-resolver-util/src/main/java/org/eclipse/aether/util/listener/ChainedRepositoryListener.java:117` > >>>> - > `maven-resolver-util/src/main/java/org/eclipse/aether/util/listener/ChainedTransferListener.java:118` > >>>> > >>>> ```java > >>>> @SuppressWarnings("EmptyMethod") > >>>> protected void handleError(...) { > >>>> // default just swallows errors > >>>> } > >>>> ``` > >>>> > >>>> All `RuntimeException`s thrown by any chained listener (NPEs, > >>>> `IndexOutOfBoundsException`, etc.) are silently swallowed unless the > >>>> user subclasses and overrides `handleError`. This makes listener bugs > >>>> invisible. > >>>> > >>>> ### 8. Volatile fields with inconsistent synchronization > >>>> **File:** > `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:78-87` > >>>> > >>>> Fields `initialized`, `socket`, `output`, `input`, `receiver` are > >>>> `volatile` but their compound use (read + method call) lacks > >>>> synchronization. `send()` reads `output` into a local variable at line > >>>> 316 without holding the monitor, then synchronizes on the local > >>>> reference at line 323, but `close()` nulls `output` under > >>>> `synchronized(this)` at line 361. `receive()` has the same pattern > >>>> with `input`. > >>>> > >>>> ### 9. SyncContext double-close risk > >>>> **Files:** > >>>> - > `maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultArtifactResolver.java:189-190, > >>>> 393-397, 430-432` > >>>> - > `maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultMetadataResolver.java:142-143, > >>>> 302-373` > >>>> > >>>> Two `SyncContext` instances (`shared` and `exclusive`) are created in > >>>> try-with-resources. Inside `resolve()`, `current` starts as `shared`, > >>>> and when switching to `exclusive` (line 393-396), `current.close()` is > >>>> called, then `current = exclusive`. The outer try-with-resources also > >>>> closes both on exit (line 202 for try-with-resources, and line 431 for > >>>> the inner `current.close()`). While `SyncContext.close()` is > >>>> documented as idempotent, any implementation that violates this > >>>> contract would cause issues. > >>>> > >>>> ### 10. InterruptedException causes task to be silently dropped > >>>> **File:** > `maven-resolver-util/src/main/java/org/eclipse/aether/util/concurrency/SmartExecutor.java:177-179` > >>>> > >>>> ```java > >>>> } catch (InterruptedException e) { > >>>> Thread.currentThread().interrupt(); > >>>> } > >>>> ``` > >>>> > >>>> In `Limited.submit(Runnable)` (line 155), if `semaphore.acquire()` > >>>> throws `InterruptedException`, the interrupt flag is restored but the > >>>> caller's task is never executed. The method simply returns. The > >>>> `submit(Callable)` variant (line 183-213) correctly handles this by > >>>> returning a failed `CompletableFuture`. The `Runnable` overload should > >>>> do something analogous (e.g., run the task inline or throw). > >>>> > >>>> --- > >>>> > >>>> ## LOW Severity > >>>> > >>>> ### 11. Minor resource leak in `parseLiteral()` > >>>> **File:** > `maven-resolver-test-util/src/main/java/org/eclipse/aether/internal/test/util/DependencyGraphParser.java:134-138` > >>>> > >>>> ```java > >>>> BufferedReader reader = new BufferedReader(new > StringReader(dependencyGraph)); > >>>> DependencyNode node = parse(reader); > >>>> reader.close(); // never reached if parse() throws > >>>> ``` > >>>> > >>>> While `StringReader.close()` is a no-op, the pattern is inconsistent > >>>> with the rest of the codebase and represents a latent bug if the > >>>> implementation changes. > >>>> > >>>> ### 12. Empty catch swallows exceptions in `tryUnlock()` > >>>> **File:** > `maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcNamedLock.java:108-115` > >>>> > >>>> ```java > >>>> private void tryUnlock(String contextId) { > >>>> try { > >>>> client.unlock(contextId); > >>>> } catch (Exception e) { > >>>> // Best-effort cleanup > >>>> } > >>>> } > >>>> ``` > >>>> > >>>> All exceptions from `unlock()` during timeout cleanup are silently > >>>> discarded. While documented as intentional, this can mask real > >>>> IO/connectivity issues. > >>>> > >>>> ### 13. Non-thread-safe access in synchronized `Results` class > >>>> **File:** > `maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegate.java:571-598` > >>>> > >>>> `addException()` and `addCycle()` are `synchronized` on `Results`, but > >>>> they call `result.getExceptions()` and `result.getCycles()` on a > >>>> `CollectResult` that may not be thread-safe. If `CollectResult`'s > >>>> internal collections are not synchronized or safely published, > >>>> concurrent modifications may not be visible. > >>>> > >>>> ### 14. `putIfAbsent()` fast-path race > >>>> **File:** > `maven-resolver-util/src/main/java/org/eclipse/aether/util/concurrency/ConcurrentWeakCache.java:124-146` > >>>> > >>>> ```java > >>>> V existing = get(key); // fast path > >>>> if (existing != null) { > >>>> return existing; > >>>> } > >>>> ``` > >>>> > >>>> The fast-path `get()` uses a ThreadLocal `LookupKey`. Between `get()` > >>>> returning null and `merge()` at line 135, another thread can insert a > >>>> new value. The merge correctly handles this, but if `get()` returns a > >>>> non-null reference to a key that gets GC'd immediately after, we > >>>> return a stale reference. This is a correct-by-accident pattern — the > >>>> merge would fix it, but we return early. > >>>> > >>>> ### 15. Pre-Java-7 stream handling in test utilities > >>>> **Files:** > >>>> - > `maven-resolver-test-util/src/main/java/org/eclipse/aether/internal/test/util/TestFileUtils.java:172-325` > >>>> - > `maven-resolver-test-util/src/main/java/org/eclipse/aether/internal/test/util/TestFileProcessor.java:63-151` > >>>> > >>>> Methods manually close streams in try-catch-finally blocks instead of > >>>> using try-with-resources. If an explicit `close()` call throws before > >>>> the finally block, open resources are leaked. Functionally correct in > >>>> happy-path but fragile. > >>>> > >>>> ### 16. `printStackTrace()` used instead of logging in tests > >>>> Multiple test files use `e.printStackTrace()` instead of proper > >>>> assertions or test framework logging, making test failures harder to > >>>> diagnose. Affected files include: > >>>> - > `maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/DefaultArtifactResolverTest.java:740, > >>>> 752, 805, 874, 975, 987` > >>>> - `maven-resolver-demos/src/main/java/.../Booter.java:111` > >>>> - > `maven-resolver-api/src/test/java/org/eclipse/aether/DefaultSessionDataTest.java:118` > >>>> - > `maven-resolver-api/src/test/java/org/eclipse/aether/DefaultRepositoryCacheTest.java:82` > >>>> > >>>> --- > >>>> > >>>> ## Summary > >>>> > >>>> | Severity | Count | Key Areas | > >>>> |----------|-------|-----------| > >>>> | HIGH | 4 | IpcClient (3 NPEs), DependencyGraphParser > (resource leak) | > >>>> | MEDIUM | 6 | PutTaskRequestContent (Throwable catch), > >>>> IpcServer (stdout logging), ChainedListener (silent swallow), > >>>> IpcClient (sync), SyncContext double-close, SmartExecutor (dropped > >>>> task) | > >>>> | LOW | 6 | Minor resource leak, swallowed exception, thread > >>>> safety in Results, ConcurrentWeakCache race, old stream handling, > >>>> printStackTrace | > >>>> > >>>> The **IPC named-locks module** (`maven-resolver-named-locks-ipc`) > >>>> accounts for the majority of HIGH-severity issues — it has multiple > >>>> NPEs from unsynchronized volatile field access. > >>>> > >>>>> On Tue, Jun 30, 2026 at 8:09 AM <[email protected]> wrote: > >>>>> > >>>>> Hello Maven, > >>>>> > >>>>> I'd like to call a vote on releasing the following artifacts as > >>>>> Apache Maven Resolver 2.0.20. This vote is being conducted using an > >>>>> Alpha version of the Apache Trusted Releases (ATR) platform. > >>>>> Please report any bugs or issues to the ASF Tooling team. > >>>>> > >>>>> The release candidate page, including downloads, can be found at: > >>>>> > >>>>> https://release-test.apache.org/vote/maven-resolver/2.0.20 > >>>>> > >>>>> The release artifacts are signed with one or more OpenPGP keys from: > >>>>> > >>>>> https://dist.apache.org/repos/dist/release/maven/KEYS > >>>>> > >>>>> Maven staging repository: > >>>>> > >>>>> https://repository.apache.org/content/repositories/maven-2440/ > >>>>> > >>>>> Release notes (draft): > >>>>> > >>>>> https://gist.github.com/cstamas/1a20ff11105992bf90a982cbae34036e > >>>>> > >>>>> Changes since the last release: > >>>>> > >>>>> > https://github.com/apache/maven-resolver/compare/maven-resolver-2.0.18...maven-resolver-2.0.20 > >>>>> > >>>>> Staging site: > >>>>> > >>>>> https://maven.apache.org/resolver-archives/resolver-LATEST/ > >>>>> > >>>>> Site deployed to SVN; sync pending; SVN site source: > >>>>> > >>>>> > https://svn.apache.org/repos/asf/maven/website/components/resolver-archives/resolver-LATEST/index.html > >>>>> > >>>>> Please review the release candidate and vote accordingly. > >>>>> > >>>>> [ ] +1 Release this package > >>>>> [ ] +0 Abstain > >>>>> [ ] -1 Do not release this package (please provide specific comments) > >>>>> > >>>>> You can vote on ATR at the URL above, or manually by replying to this > email. > >>>>> > >>>>> The vote is open for 72 hours. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Tamas Cservenak (cstamas) > >>>>> > >>>>> This email was sent by [email protected] on the Apache Trusted > Releases platform > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>> > >>>> > >>>> -- > >>>> Elliotte Rusty Harold > >>>> [email protected] > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
