Hi 2 makes sense until we create a dedicated v4 version of help plugin IMHO
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 <https://javaccino.dev/> founder (Java/.NET service - contact via linkedin) Le mar. 28 juil. 2026 à 18:42, Neil Tomar <[email protected]> a écrit : > Context: maven-help-plugin issue #378 - help:list-dependency-types prints > an empty list on Maven 4 (works on Maven 3). > > Cause: the goal injects Map<String, ArtifactHandler> and iterates it. On > Maven 3 that map holds the registered types (jar, war, test-jar, ...). On > Maven 4 it is empty - there are no individual @Named ArtifactHandler beans > anymore; DefaultArtifactHandlerManager resolves handlers lazily from a > TypeRegistry, so the map injection has nothing to collect. > > Listing all types on Maven 4 alone is possible via > lookup.lookupList(TypeProvider.class) (this is how DefaultTypeRegistry > builds itself). But Type/TypeProvider are Maven 4-only API, and the plugin > must keep supporting Maven 3 - adding the Maven 4 API trips > enforceBytecodeVersion. ArtifactHandlerManager and TypeRegistry otherwise > only expose lookup by id, not "get all". > > So the real problem: there is no way for a plugin to enumerate all > dependency types that works on BOTH Maven 3 and 4. Is this loss considered > a regression that should be addressed, or is the expectation that plugins > work around it (or drop Maven 3 support)? > > Options I can see: > 1. Fix Maven 4 core so an existing cross-version method (e.g. > DefaultArtifactHandlerManager#getHandlerTypes) returns the registered types > via TypeProviders - then the plugin keeps using the old API and works on > both. (Open question: whether Maven 4's extensible type model makes "all > types" always well-defined.) > 2. Plugin-side reflection: on Maven 4, reach TypeProvider/Type reflectively > (no compile-time Maven 4 dependency); fall back to the current map on Maven > 3. > 3. Make a future maven-help-plugin version require Maven 4. > > Is option 1 something the Maven team would consider, or is there a > supported > API I've missed? >
