[MDEP-804] Allow auto-ignore of all non-test scoped dependencies used only in test scope

[jira-importer]

Henning Schmiedehausen opened MDEP-804 and commented

Pre-3.2.0, dependencies that were used only in test scope but not declared in test scope (most likely declared in compile scope) were accepted by the plugin and not flagged as a problem.

Starting with 3.2.0 (and the current 3.3.0), these are reported with "Non-test scoped test only dependencies found". If the scope of the dependencies can not be changed (there are many reasons for that in large projects), the old behavior can be restored by adding each flagged dependency to the "ignoredNonTestScopedDependencies" configuration option in the respective project.

This is, especially in large projects, cumbersome and brittle.

There should be a boolean flag, "ignoreAllNonTestScoped" that, when set, allows ignoring non-test scoped dependencies if they are used only in test scope. This flag restores the pre-3.2.0 behavior.

---

Affects: 3.3.0

Remote Links:

• GitHub Pull Request #211
  

[jira-importer]

Slawomir Jaranowski commented

Why not use:

<ignoredNonTestScopedDependencies>
 <ignoredNonTestScopedDependency>*</ignoredNonTestScopedDependency>
</ignoredNonTestScopedDependencies>

your PR do exactly the same.

I prefer to not add next options if we can achieve the same result by existing ones.

We can extends documentation about such case.

And of course thanks for PR and involvement.

 

[jira-importer]

Henning Schmiedehausen commented

You are correct, this would be equivalent. However, the normal use case for a flag is something like this:

<configuration>

< ignoreAllNonTestScoped>${some.property.used.by.the.build.system></ignoreAllNonTestScoped>
</configuration>

We have massive build configurations with dozens of modules and multiple projects. I can add the block that you suggested to our master pom and as a result, I can not use the option anywhere, because now I would need to undo that global setting and add my explicit excludes. This is a very brittle and complicated way to do this. With a flag, I can set the flag in the projects where I want to ignore all deps and unset it in all the others (and there I can add the explicit excludes).

As the original author of quite a bit of these excludes (yeah, look it up; I was as surprised as you. Back in 2015. :-) ), I have done a lot of workarounds before adding flags. For large scale systems, flags are a life-saver because they allow property driven enabling/disabling of features in a way that the lists do not.

(Technically I should still be a committer on Apache Maven; I don't think my commit bit ever lapsed. I very much prefer to have a discussion about this, but I don't feel that a blanket "There is a workaround that does it in isolation" statement is the best answer).

[jira-importer]

Henning Schmiedehausen commented

Yeah, according to https://people.apache.org/phonebook.html?unix=maven, I am still an Apache Maven committer. Can I get that bit for github as well please? ;-)

[jira-importer]

Slawomir Jaranowski commented

Nevermind if you are or not committed I prefer discus new feature in projects.

I see that many projects have many (some time too many) options and the result is code is complicated and nobody happy to maintain it.

First I want to understand your needs, maybe someone else want to add his opinions.

PS.
You have access to github - go to selfserve, check your github username, and synchronize git ...

[jira-importer]

Henning Schmiedehausen commented

Very much agreed. That is why I opened a PR and a ticket. I feel that discussing use cases is valuable. This PR is mostly a reaction to the behavior changes from 3.1.x -> 3.2.0. A flag allows us to transition to the newer plugin versions with much less pain than using excludes.

I hope you understand the use case (flags can be driven out of properties, lists can not) and why this is still beneficial.

Personally, I don't mind lots of flags; the problem is that they often could be documented better and their interaction is sometimes undefined. I hope I documented this new flag sufficiently.