Am 11/19/16 um 03:58 schrieb Igor Fedorenko: > Thank you for the analysis of the IT failures, Christian. I have a few > questions/observations, if you don't mind > > MavenITmng2199ParentVersionRangeTest.testValidLocalParentVersionRange > From what I can tell, module uses parent version=[1.0,2) which matches > locally available parent version=1.1. Can you explain why this test is > expected to fail?
The local parent version range logic was lacking validation. This commit <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=893efe3a9c49952d916b0eac66973581cd2702cd> added the missing validation (DefaultModelBuilder) so that there is no difference any more in "parent from repository" vs. "parent from disc". The IT is failing with: [ERROR] The build could not read 1 project -> [Help 1] org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [FATAL] Version must be a constant @ org.apache.maven.its.mng2199:local-parent-module:[unknown-version], /home/schulte/Sources/apache.org/maven-integration-testing/ core-it-suite/target/test-classes/mng-2199-parent-version-range/local-parent/module/pom.xml, line 2, column 10 In that module, the version must be constant due to the version range in use. That's how the test would fail if the parent would not be on disc but would need to be resolved from a repository. That validation has been missing only for local parent poms. See the commit message: o Updated to make local and remote parent model resolution consistent. 'MavenProject.getParentArtifact()' now returns the same artifact no matter where the parent has been read from and the 'ModelBuilder' will disallow empty versions and version expressions in local child modules when using parent version ranges the same way as is done for remote parent models. What to note here is that parent version ranges could only be used in Maven 3.2.2. They are broken since 3.2.3. The ITs were incorrect and did not catch that. There has been just that one Maven version around with working parent version ranges. They will start working again in 3.4. > > MavenITmng4600DependencyOptionalFlagManagementTest/MNG-5227 > This seems rather major dependency resolution change for 3.4 release, > but I do not have strong opinion about the change otherwise. In my opinion Maven 3 behaviour has been correct. MNG-4600 has been reported as a regression against Maven 3.0-beta-1. Maven 3 has been changed solely for backwards compatibility to Maven 2 although it's a bug in Maven 2. > > MavenITmng3719PomExecutionOrderingTest > Shows that Maven used to allow the same plugin used in multiple <plugin> > elements. I am actually surprised this worked in 3.3.9, but I think this > will be a real problem for project that rely on this behaviour. > > For other MNG-6075 changes, again, this maybe little too big a change > for 3.4, but I think it is okay if remote pom.xml still work. Can you > confirm that Maven is still able to use "old" pom.xml file from remote > repositories? I repeat the description of MNG-6075 here: Maven 3 has warned about various model related issues clearly stating that not reacting to those warnings may break with a future Maven version. Starting with Maven 3.4, the model validation level has been increased to the next minor version so that such warnings will become errors as of 3.4. My personal opinion to this is: If there are still projects around refusing to fix theire POMs although they get warnings since years, what can we do about it? Doing it was planned for Maven 3.1 already but has never been done. If not done in 3.1, 3.2 and 3.3, then let's do it in 3.4. It's no big deal reverting that, though. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
