Skip to content

Pull #2292: Modernize codebase with Java improvements - SOC DefaultModelProcessor#read #2292

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

Closed

Conversation

Pankraz76
Copy link
Contributor

@Pankraz76 Pankraz76 commented May 2, 2025

Pull #2292: Modernize codebase with Java improvements - functionalize DefaultModelProcessor#read

enable for:

depends on:

add missing Exception requirement to prevent:
image
image
image
finally 100
image

@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch 2 times, most recently from 4e0114f to 4ba53a1 Compare May 2, 2025 20:01
@Pankraz76 Pankraz76 marked this pull request as ready for review May 2, 2025 20:01
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch 4 times, most recently from d897766 to 4a35897 Compare May 2, 2025 20:07
@Pankraz76
Copy link
Contributor Author

whats the mystery about this?

[ERROR] Errors: 
[ERROR]   EmbeddedMavenExecutorTest.defaultFs3xCaptureOutput(Path) » Timeout defaultFs3xCaptureOutput(java.nio.file.Path) timed out after 15 seconds
[ERROR]   ForkedMavenExecutorTest.dump4(Path, Path) » Timeout dump4(java.nio.file.Path, java.nio.file.Path) timed out after 15 seconds
[ERROR]   ToolboxToolTest.metadataPath3(Mode)[1] » Timeout metadataPath3(org.apache.maven.cling.executor.ExecutorHelper$Mode) timed out after 15 seconds

@Pankraz76 Pankraz76 changed the title Pull #2287: Modernize codebase with Java improvements - functional DefaultModelProcessor#read Pull #2287: Modernize codebase with Java improvements - functionalize DefaultModelProcessor#read May 2, 2025
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 2, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch from 4a35897 to 594f1bc Compare May 2, 2025 20:13
@Pankraz76 Pankraz76 changed the title Pull #2287: Modernize codebase with Java improvements - functionalize DefaultModelProcessor#read Pull #2292: Modernize codebase with Java improvements - functionalize DefaultModelProcessor#read May 2, 2025
Copy link
Contributor

@gnodet gnodet left a comment

Choose a reason for hiding this comment

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

This totally breaks the exception handling.

@Pankraz76
Copy link
Contributor Author

This totally breaks the exception handling.

yes, then we need test, thanks.

private Model readOnSelfOrParent(Path pomFile, XmlReaderRequest request) throws IOException {
return pomFile == null
? doRead(request)
: modelParsers.stream()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

extract concern into readParent() to hide impl. detail and give dedicated concern

Copy link
Contributor

@elharo elharo left a comment

Choose a reason for hiding this comment

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

Please don't. The original code is clearer. Lambdas do not improve this.

Copy link
Contributor

@elharo elharo left a comment

Choose a reason for hiding this comment

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

Test cases might be missing here, but it looks like this changes functionality in a negative way by not grouping exceptions

@Pankraz76
Copy link
Contributor Author

Pankraz76 commented May 5, 2025 via email

@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch from 594f1bc to 0cd0f4e Compare May 7, 2025 10:32
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 7, 2025
Copy link
Contributor Author

@Pankraz76 Pankraz76 left a comment

Choose a reason for hiding this comment

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

add tc; challenge API

@@ -137,7 +139,7 @@ private Path doLocateExistingPom(Path project) {
}
}

private Model doRead(XmlReaderRequest request) throws IOException {
Copy link
Contributor Author

@Pankraz76 Pankraz76 May 7, 2025

Choose a reason for hiding this comment

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

this changes the whole code as this "can not happen"; or if needed then we should change API, if we can, to make code more concise.

ATM this code is based in impl. detail, which should be communicated; therefor enforced.

image

try {
return doRead(request);
} catch (IOException e) {
exceptions.forEach(e::addSuppressed);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Then this is the last branch not covered.

Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 7, 2025
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 7, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch from 0cd0f4e to b52e0d0 Compare May 7, 2025 11:28
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 7, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch from b52e0d0 to e1d0f96 Compare May 7, 2025 11:38
if (Files.isDirectory(project)) {
Path pom = project.resolve("pom.xml");
return Files.isRegularFile(pom) ? pom : null;
} else if (Files.isRegularFile(project)) {
Copy link
Contributor Author

@Pankraz76 Pankraz76 May 7, 2025

Choose a reason for hiding this comment

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

IMHO, it's either a directory (the higher-tier entity), as there is no file without a directory containing it. Which one came first is another topic, but I think it's that simple—either/or. So, we don't need this check, as the null branch is hard to test.

image

Copy link
Contributor Author

Choose a reason for hiding this comment

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

tested:

image

* This is because the ModelProcessor interface extends ModelLocator and ModelReader. If we
* made this component available under all its interfaces then it could end up being injected
* into itself leading to a stack overflow.
*
Copy link
Contributor Author

@Pankraz76 Pankraz76 May 7, 2025

Choose a reason for hiding this comment

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

Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 7, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch from fb93e7d to 13ff316 Compare May 7, 2025 19:42
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 7, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch from 13ff316 to 739cc50 Compare May 7, 2025 19:44
@Pankraz76
Copy link
Contributor Author

Pankraz76 commented May 7, 2025

Adding checked exceptions to the API which relies on unchecked exceptions everywhere is problematic

Thanks for the feedback. But just to clarify — this reflects what the current implementation actually does, right?
I'm doing this to enforce the current API and approach, so I’d suggest we state things as they are and move forward from there.

Otherwise, I’d consider removing the IOException check — it might actually be causing issues. That’s why I want to enforce and challenge this behavior.
The tests and interface should make the actual behavior and requirements clear.

I'm not fully aware of all the requirements, but ideally, we can follow TDD and refactor aggressively to reveal the final version of the code and surface the core business logic.

@Pankraz76 Pankraz76 requested a review from elharo May 7, 2025 19:52
@gnodet
Copy link
Contributor

gnodet commented May 7, 2025

Adding checked exceptions to the API which relies on unchecked exceptions everywhere is problematic

Thanks for the feedback. But just to clarify — this reflects what the current implementation actually does, right? I'm doing this to enforce the current API and approach, so I’d suggest we state things as they are and move forward from there.

Currently, the API is designed to throw XmlReaderException. Check the implemented interface, there's no IOException thrown here.

Otherwise, I’d consider removing the IOException check — it might actually be causing issues. That’s why I want to enforce and challenge this behavior. The tests and interface should make the actual behavior and requirements clear.

I'm not fully aware of all the requirements, but ideally, we can follow TDD and refactor aggressively to reveal the final version of the code and surface the core business logic.

Not sure what you mean exactly, but refactoring is not supposed to change the API in any way.

@Pankraz76
Copy link
Contributor Author

Not sure what you mean exactly, but refactoring is not supposed to change the API in any way.

yes of course will adapt then. sorry

Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 7, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch from 739cc50 to 323035c Compare May 7, 2025 22:49
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor branch from 323035c to 2279d78 Compare May 7, 2025 23:03
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76
Copy link
Contributor Author

This totally breaks the exception handling.

I'm not sure—when asking AI and trying to mock it, both seem to say the same thing: "Checked exceptions must be declared!"
That's how I remember Java's behavior ever since.

image image

We shouldn't surprise the consumer by forcing them to handle a checked exception that hasn't been declared. A better experience would be to adapt the API to declare the exception properly, or remove the catch block if the exception can't occur by contract—especially since such cases aren't testable.

Currently, the API is designed to throw XmlReaderException. Check the implemented interface, there's no IOException thrown here.

If no exception is thrown, then there's no need for a catch block—especially if it's not testable.

org.mockito.exceptions.base.MockitoException: 
Checked exception is invalid for this method!
Invalid: java.io.IOException
image

@Pankraz76
Copy link
Contributor Author

Pankraz76 commented May 8, 2025

thats my headache Exception 'java.io.IOException' is never thrown in the corresponding try block

Dedicated PR:

image

Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76
Copy link
Contributor Author

Currently, the API is designed to throw XmlReaderException. Check the implemented interface, there's no IOException thrown here.

please notice dedicated thread: https://github.com/apache/maven/pull/2304/files#r2079127763

@Pankraz76 Pankraz76 changed the title Pull #2292: Modernize codebase with Java improvements - functionalize DefaultModelProcessor#read Pull #2292: Modernize codebase with Java improvements - SOC DefaultModelProcessor#read May 8, 2025
@gnodet
Copy link
Contributor

gnodet commented May 8, 2025

It's not thrown, that's right. So do not add a throw clause.

Copy link
Contributor

@gnodet gnodet left a comment

Choose a reason for hiding this comment

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

I' not completely sure you actually understand what you remove.
So let's keep focused PRs and let us know if you ran the tests successfully first.

}

private static Path isRegularFileOrNull(Path pom) {
return Files.isRegularFile(pom) ? pom : null;
}

@Override
public Model read(XmlReaderRequest request) throws IOException {
Objects.requireNonNull(request, "source cannot be null");
Copy link
Contributor

Choose a reason for hiding this comment

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

source --> request

@Pankraz76 Pankraz76 marked this pull request as draft May 9, 2025 11:23
@Pankraz76
Copy link
Contributor Author

wip reopen

@Pankraz76 Pankraz76 closed this May 13, 2025
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.

3 participants