Am 01/30/17 um 23:19 schrieb Stephen Connolly: > I find it hard to follow your explanations as to what the change is, but I > think I understand... > > could you try and rephrase what your change is because the current phrasing > is rather more alarming than I suspect it is
1. The commit to the core is fixing external parent version range resolution and adds missing version validation to local parent version range resolution. External parent version range resolution got introduced in 3.2.2 and was working there. When I wrote the initial ITs, I did not notice that Maven just logs a warning when it fails to build a parent MavenProject instead of failing the build. As a consequence, one of the first commits after the release of 3.2.2 broke external parent version ranges without the ITs starting to fail. I updated the ITs to check for that warning message so that they start to fail as expected. That means you cannot run the updated ITs with anything > 3.2.2 as they will start to fail (expected) due to external parent version ranges being broken. The changes to class 'MavenITmng2196ParentResolutionTest.java' are fixing the ITs to fail as expected. 2. When working on MNG-2199 for 3.2.2, I wasn't sure how the local parent resolution is to be performed and decided to not do anything about it. During development of 3.3.0, there is a commit removing version comparison so that what you put into a <parent>'s <version> element is more or less ignored. There must be a value but that value is not checked any further breaking local Maven parent coordinates in an unexpected way. You noticed something is wrong and filed MNG-5840 and fixed the issue. Noticing external parent version ranges are broken I started to work on it again for - back then - 3.4.0. Reading the local parent resolution code again, I noticed your changes and also noticed that the behaviour I wasn't sure about wasn't intention - you fixed it. Looking at your fixes I noticed that external parent version range resolution is more strict than local parent version range resolution and that the local parent version range resolution is lacking some validation performed for external parent version range resolution. The missing validation is this: If a parent is referenced using a version range, the project version must be a constant - that is - it cannot be inherited and it cannot use expressions. For the expression case, there already would have been a warning message. Reason for not supporting this was due to objections mentioned in the MNG-2199 JIRA issue. If you deploy a POM referencing it's parent using a version range, the POM version must not change in any way due to inheriting it from any of the parent's of the range or by using an expression, which may also be declared in those said parents. That validation is saving us from versions of deployed POMs changing due to parent version range resolution resolving to the highest available parent available. Shorter form: Deploy a new parent and all children referencing that parent like GID:AID:RANGE would inherit a different project version or different property value. Adding this lacking validation to local parent version range resolution, there was an IT testing that you can inherit a version from a parent referenced using a range. I moved that test out of class 'MavenITmng2196ParentResolutionTest.java' into a new class 'MavenITmng2199DeprecatedParentVersionRangeTest.java'. That new class is running the unchanged test but declares a different range of Maven versions. Initially it would have run against [3.2.2,) although the project cannot be build with any Maven version < 3.3.0. The only change to the IT is the range I updated to [3.3.0,3.3.9]. That's the only changes to ITs. The addition of class 'MavenITmng2199ParentVersionRange350Test.java' is just adding ITs for the local parent version range resolution. Regards, -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
