The last time I looked into this my personal conclusion was that everything was now working as intended, and we don't want or need more flags. It feels like epicycles on epicycles. My current opinion is:
1. The latest version of the plugin correctly identifies needed and unneeded dependencies, including dependencies that could have overly broad scope. 2. All these checks are completely optional. If a project doesn't find these helpful, it doesn't have to use the dependencies plugin. Unless I am factually wrong about one of these claims (certainly possible, if so please describe exactly how with a reproducible example) I don't see any reason to revisit this now, and I think adding further flags is a bad idea. It's not only more complex. It's actively wrong. What developers who choose to turn on this check want is simple: warn about any unnecessary dependency, including dependencies whose scope is too broad. That's what the plugin should do, and I *think* that's what it currently does. On Sun, May 1, 2022 at 8:59 PM Henning Schmiedehausen <henn...@schmiedehausen.org> wrote: > > Hi, > > [I discussed this on slack with @sjaranowski, he suggested to bring this > conversation here ] > > The latest releases of the maven dependency plugin (3.2.0, 3.3.0) > introduced some changes in the way test dependencies are handled and > potentially flagged. Especially the "Non-test scoped test only dependencies > found" warning/error has turned into quite a problem for larger projects > that worked fine with the 3.1.x versions of the dependency plugin. > > 3.3.0 introduced the "ignoredNonTestScopedDependencies" exclusion list in > the configuration which helps to work around those problems by allowing > flagged dependencies to be ignored. > > The challenge with this is that retrofitting on larger projects with a lot > of dependencies now flagged either leads to a lot of very brittle > per-module configuration work or adding a blanket exclusion to a base pom > with no recourse within modules. > > I proposed therefore adding another flag to the plugin in MDEP-804. Flags > are useful because they can be driven out of properties which in turn can > be overridden on a per-module base. This e.g. allows me to set a blanket > policy of ignoring these problems by default and then turn that blanket > policy off on a per-module base and add finer grained exclusions. This > solves both by problems and also the issues described in MDEP-791. > > @sjaranowski pushed back a bit in the PR, questioning whether we want more > flags. What is important to me is that flags are much more useful than > exclusion lists, because I can drive them out of properties. > > It would be good to get some more opinions. The PR ( > https://github.com/apache/maven-dependency-plugin/pull/211) is ready to go > in (it has integration tests). Technically, I still have my commit bit (and > I assume Maven is still CTR) but I haven't comitted to that code base for a > long time and I don't want to step on any toes. > > -h > > (Wow, this may be my first post to dev@maven in six+ years. Feels good. :-) > ) -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
