Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MRESOLVER-247] IT update for resolver behaviour change #140

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

cstamas
Copy link
Member

@cstamas cstamas commented Mar 11, 2022

Once MRESOLVER-247 is merged, and maven consumes it, this IT
will fail, as maven will resolve LESS then this IT expects.

This change makes IT perform same assertion ("no POM is read twice") but
without locking down the absolute number of POMs read.

I tried to be least intrusive here (so I left old but added
new values w/ explanation).

Once MRESOLVER-247 is merged, and maven consumes it, this IT
will fail, as maven will resolve LESS then this IT expects.
@cstamas cstamas marked this pull request as ready for review March 11, 2022 15:59
Copy link
Member

@michael-o michael-o left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this change. Why 140+? And how did + 4 make it to - 4? Moving the expected value to a constant make sense, but the rest is unclear.

@cstamas
Copy link
Member Author

cstamas commented Mar 11, 2022

I don't understand this change. Why 140+? And how did + 4 make it to - 4? Moving the expected value to a constant make sense, but the rest is unclear.

Changes one by one:

  • The assert for 140+ is really just to exclude false positives (ie. Maven does not parse even one POM). We KNOW there are hundred-something POMs to parse, but we DO NOT WANT to fix that number (as will change between DFS/BFS/skipper)
  • instead to assert lines in log (created by agent), we "remember" the count, then we make that list unique, and compare size again
  • the +4 was factored out, the sum was asserted (168+4), so assertion happened with 172, hence, to get 168 out of 172 we do -4.
  • In other words (applies to testWithBuildConsumer) method only: we KNOW that reactor POMs are read twice (and reactor has 2 POMs, hence we "correct" the count with -4)
  • finally, I have a list of strings, making them unique by file path (using model.building.source) and asserting result is list.size - 1 = uniqList.size (as super pom is OMITTED from uniq list, it has NO model.building.sourcre).

Example of log entries for POM that went thru model builder vs Super POM (reformatted for easier read, they are all one liners):

{
  org.apache.maven.model.io.inputSource=null null, 
  org.apache.maven.model.io.isStrict=true, 
  org.apache.maven.model.building.source=/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it- suite/target/test-classes/mng-5669-read-poms-once/module3/pom.xml
}, 
{
  org.apache.maven.model.io.inputSource=org.apache.maven:maven-model-builder:4.0.0-alpha-1-SNAPSHOT:super-pom jar:file:/home/cstamas/Worx/apache-maven/maven-integration-testing/core-it-suite/target/apache-maven/lib/maven-model-builder-4.0.0-alpha-1-SNAPSHOT.jar!/org/apache/maven/model/pom-4.0.0.xml, 
  xml:4.0.0=xml:4.0.0
}

@michael-o
Copy link
Member

Is this one still necessary?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants