So this sounds like the original tests are wrong. As such we shipped broken versions of Maven. It wasn't ever our intent that those projects work with 3.3.x rather a bug in the tests.
In that regard *my* personal pref is that all these tests have the range starting from [3.2.2,) which would mean that 3.3.9 no longer passes the integration tests. Before merging or changing your branch we need to get agreement on how to handle bugs in the tests. The previous IT fixes where where we were choosing to change the "spec"... here is more an errata in the "spec". I'll see if I can frame the question in a way that will allow for easier action going forward some time tomorrow, and then we can see what the consensus is. Wdyt? On Mon 30 Jan 2017 at 22:49, Christian Schulte <[email protected]> wrote: > 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] > > -- Sent from my phone
