You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently it is impossible to tell in advance which transporter implementation is used for which kind of (remote) repository resolver/upload request. In order to ease debugging, this should be exposed via API (without the need for having a concrete RemoteRepository).
Problem right now is that TransporterFactory.newInstance always takes a RemoteRepository to check if it should be used. It fails with an exception if it doesn't support the given repository url. Probably this should be refactored so that a more targeted lookup can be performed (also in
LOGGER.debug("Could not obtain transporter factory for {}", repository, e);
).
Maybe adding another method boolean canHandle(String protocol) (by default always returning true) to TransporterFactory in combination with something like String getDescription() (returning some explanation on which library is used etc). would be reasonable.
Activity
kwin commentedon Jan 28, 2026
Problem right now is that
TransporterFactory.newInstancealways takes aRemoteRepositoryto check if it should be used. It fails with an exception if it doesn't support the given repository url. Probably this should be refactored so that a more targeted lookup can be performed (also inmaven-resolver/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTransporterProvider.java
Line 104 in ec52693
Maybe adding another method
boolean canHandle(String protocol)(by default always returning true) toTransporterFactoryin combination with something likeString getDescription()(returning some explanation on which library is used etc). would be reasonable.Expose transporter details per protocol
Expose transporter details per protocol
Expose transporter details per protocol