Unable to exclude a dependency from a needed plugin

I think it's by design that the plugin writer would know better what should be used. If it doesn't affect your project classpaths, why do you care? (just curious)

Brian: ok, but Why are you allowed to add new dependencies to a plugin via dependencyManager? and why you can do exclusions for standard dependencies? If we trust third party authors and original dependencies then we wouldn't need the depependency/exclusion system at all.

About the specific issue one of our PMC members is concerned about security and would like to build the project fully offline and without using artifact previously downloaded to the repository. We do this by declaring a "stage" repository that have a "file://${basedir}/stage" url and placing there every dependency we have.

Unfortunately some plugin have plenty of dependencies and sometimes they forgot to declare that a dependency is only needed at compile time, so the list of jars needed is almost double that the jars actually being used.

Ok I see. The first question: Why can you add a dependency? That is used for some plugins like checkstyle where you need to add something to the classpath of the plugin (like a jar with custom rules). The exclusions of standard dependencies are normally used to exclude things that should have been optional in the first place (or cause conflicts for whatever reason)

Specifically to plexus utils, if it really is a compile time dependency, then it would also be a runtime one. Because of previous behavior, maven "provided" a fixed version of plexus utils. This was removed but because some plugins actually where dependent on it and didn't declare it, maven will provide a minimum version (I forget the exact version now). I wouldn't rely on this functionality forever and excluding plexus from a plugin (if it where possible) would be very dangerous and subject to breaking a build on a maven upgrade.

Currently after I built the project I end up with 5 different version of plexus-utils in my repository: 1.0.4, 1.0.5, 1.1, 1.2, 1.3.
It would be cool if I could override the default dependency and define what exactly will be used (by limiting jar prolification). But the main issue is with "non-marked-as-optional" dependencies. I think this is the same as for transitive dependencies for standard/non-plugin dependencies (the same considerations applies).

E.g: plexus-utils 1.0.4 has only junit in test scope. 1.0.5 has classwordls,1.1+ have no dependencies.

I think it would be cool to have a clear overview about why I have a specific plugin dependency (like I have for standard dependencies) and to be able to tune it up: this is also true because I may want to "replace" a plugin dependency with a "trusted" jar, instead of using the declared dependency.

One solution to me is to change the pom for the plugin files I place in the "stage" repository, but I bet this will create much more problem than solving them. our "custom" poms will end up in the user's m2 repository and may conflict/brake other builds.

The reason I have been interested in excluding/overriding a plugin dependency stems from the issue described in MOJO-687. The short explanation is that the xmlbeans-maven-plugin v2.0.0 has a transitive dependency (xmlbeans-jsr173-api) which does not exist anywhere. This makes the plugin unusable without local modification to the plugin POM. So in that case, one could argue that the plugin writer unfortunately did not know better It would be nice to quickly work around this by being able to exclude the non-existent transitive dependency.