Re: [Help]: Plugins can no longer list all dependency types across Maven 3 and 4 (help-plugin #378)

Romain Manni-Bucau <[email protected]> Tue, 28 Jul 2026 20:03:37 +0200
Newsgroups gmane.comp.jakarta.turbine.maven.devel
Message-ID <CACLE=7M7mJy8eQTaim4-U_MdVosEVXkLCLMe=6ZGt+-pQ8TjBw@mail.gmail.com>
--0000000000001c64130657afa9d0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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-97817884=
73064>
Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via
linkedin)


Le mar. 28 juil. 2026 =C3=A0 18:42, Neil Tomar <[email protected]> a =
=C3=A9crit :

> 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 bean=
s
> 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 plugi=
n
> 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 considere=
d
> 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 typ=
es
> 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 reflective=
ly
> (no compile-time Maven 4 dependency); fall back to the current map on Mav=
en
> 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?
>

--0000000000001c64130657afa9d0--