I have another question. How do you make a decision for the "+1" vote (especially binding votes)? I'm nb and validating several scenarios (e.g. full and empty .m2), module subsets, we have test distribution - compile separately and then only surefire:test in CI, custom builders (some of you know the TurboBuilder), a lot of custom plugins, code generation etc. To run all these I have to make my own custom build of Maven 3.10.x, as no option is suggested in this vote. I'm confused
On Thu, Jul 2, 2026 at 5:05 AM David Jencks <[email protected]> wrote: > 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] > >
