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

Follow-up on help:list-dependency-types (#378).

To list all dependency types on Maven 4 I need the TypeProviders, but the
maven-help-plugin has to keep working on Maven 3, so I can't add the Maven 4
API as a compile-time dependency (enforceBytecodeVersion). That means I can
only get org.apache.maven.api.spi.TypeProvider as a Class at runtime
(classLoader.loadClass(...)), never as a type I can name in the constructor.

What I tried in the mojo:

- @Inject Provider<T> works on both Maven 3 and 4, but needs T named at
  compile time.
- @Named("...") Provider<Object> resolves to a PlaceholderBeanProvider and
  get() returns null (on both Maven 3 and 4).
- Injecting com.google.inject.Injector - which would allow
  getInstance(Class) - fails on Maven 4 with
  NoClassDefFoundError: com/google/inject/Injector (not visible in the
  plugin realm).
- PlexusContainer.lookupList("org.apache.maven.api.spi.TypeProvider")
  returns an empty list on Maven 4.

Is there a supported way for a plugin to look up a component by Class (or by
role string) at runtime that works on both Maven 3 and Maven 4?

On Tue, Jul 28, 2026 at 11:35 PM Romain Manni-Bucau <[email protected]>
wrote:

> 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?
> >
>