Resolves #387: Provide an enforcer rule to specify the maximum number of allowed dependency updates

[jarmoniuk]

Please review @slawekjaranowski

[jarmoniuk]

One big difference is lack of segment controls like e.g. allowMinorUdates in the display dependency updates goal. I'm thinking of maybe adding such controls, i.e. ignoreMinorUpdates, ignoreIncrementalUpdates, and ignoreSubincrementalUpdates. What do you think?

-> Converting back to draft.

[jarmoniuk]

Implemented the three "ignore-" parameters. I think it's ready now.

I'll integrate the changes from #797 once it's merged in.

[jarmoniuk]

Oh and regarding this:

.filter( dep -> finalDependencyManagement.parallelStream()
        .noneMatch( depMan -> dependenciesMatch( dep, depMan ) ) )                       

The above filters out dependency management from dependencies. The code replaces a lengthier method doing the same using a for iterator with a "terminator" variable. Why it was done in the first place I can only speculate about.

I think it's so that the dependency updates from dependencyManagemnt are not repeated in the depenedencies section.

If so, why isn't the same done wrt other sections -- that I don't know.

[jarmoniuk]

Moved interpolateVersion to a static method inside MavenProjectUtils, since it is not using anything from VersionsHelper.

[slawekjaranowski]

I think it will be to more complicated ... many configuration options will not be accepted like ruleSets ...

Maybe easier will be introduce new goal to existing plugin ...

[slawekjaranowski]

I still not convinced for such solution.

When user has configuration for versions-m-p like ruleSet and so on ...
When user want to use enforcer rule should copy paste configuration again to rule - right?

In such case maintain configuration in double place is difficult to maintenance.

[jarmoniuk]

I still not convinced for such solution.

When user has configuration for versions-m-p like ruleSet and so on ... When user want to use enforcer rule should copy paste configuration again to rule - right?

In such case maintain configuration in double place is difficult to maintenance.

My problem with using display-dependency-updates to enforce a number of dependencies is that display-dependency-updates does not have "ignore...updates" options. "allow...updates" options have opposite semantics. It's like "include" vs "exclude". So, one cannot copy the options for one goal to another.

Display-dependency-updates allows ignoring the most major segemnts: *-2.3-1, *-*.3-1, *-*-*-1.

But here we need to be able to ignore the least major ones: 1.2.3-*, 1.2.*-*, 1.*.*-*.

That, plus the purpose of enforcing a number of updates is different.

A lot of the functionality is similar, to I abstracted that and moved it to that static utility class.

[jarmoniuk]

I'll check later what went wrong there

[jarmoniuk]

Soooo... I was a bit too optimistic with taking the enforcer-rule out to its own module. Too early for that. The rule needs to use some functionality from VersionsHelper, but the plugin also needs to package the rule, so it needs to depend on it. So, this is a circular dependency.

So, I'm putting it back until we extract the api to its own module.

Second stage of the module split:

• enforcer-rules
• versions-api
• versions-test (TestUtils, MockUtils, etc. -- everything which is independent, but will be used by several different modules in tests)

The above is a discussion on its own, but right now, the api package is also not really mature -- it contains some API, but it also contains API implementation and utilities. Also, I think VersionsHelper and AbstractArtifactVersions seem to serve a very similar purpose.

[jarmoniuk]

@slawekjaranowski rebased with master. Please review.

[jarmoniuk]

@slawekjaranowski should I make any more changes to this PR (apart from resolving merge conflicts)?

[jarmoniuk]

So, I've waited with this quite some time as well, and it's also been increasingly more cumbersome to resolve all conflicts. Please review again and merge @slawekjaranowski

[jarmoniuk]

Changes applied, please re-review/merge.

[slawekjaranowski]

IT test for enforcer should be in versions-enforcer module

Now under test latest version of tested artifact is downloaded from remote repo
or used from previous build from local repository

[jarmoniuk]

@slawekjaranowski changes applied. One question remaining regarding the version of maven-enforcer-plugin in the docs.

[jarmoniuk]

@slawekjaranowski changes applied where possible (one was not possible -- yet)