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

Incubating Maven resolver: do not load the workspace when the original resolver isn't aware of it #44680

Conversation

aloubyansky
Copy link
Member

This change includes an important enhancement in the incubating application model resolver impl to skip workspace loading when it's not necessary.
It also introduces an option to switch to a blocking task runner in the incubating resolver (for now not documented, for my own testing, I'll make it a proper option later) and some other clean up.

…l resolver isn't aware of it, switch to choose between blocking and non-blocking dependency processor, clean-up
@quarkus-bot quarkus-bot bot added the area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins label Nov 25, 2024

private static final Logger log = Logger.getLogger(NonBlockingModelResolutionTaskRunner.class);

private final Phaser phaser = new Phaser(1);
Copy link
Contributor

Choose a reason for hiding this comment

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

Man, I've almost never seen a Phaser used :)

import org.jboss.logging.Logger;

/**
* Non-blocking task runner implementation
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe it also makes sense to document when it makes sense to use this implementation

Copy link
Member Author

Choose a reason for hiding this comment

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

Basically, if the non-blocking failed, to check whether it due to concurrency issues :)
So that plus to see how much more efficient the non-blocking approach is.
I'll document it when I make it a proper option.

Copy link
Contributor

Choose a reason for hiding this comment

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

👌

@geoand geoand added the triage/waiting-for-ci Ready to merge when CI successfully finishes label Nov 25, 2024
@aloubyansky aloubyansky merged commit 87e1d39 into quarkusio:main Nov 25, 2024
51 checks passed
@quarkus-bot quarkus-bot bot added this to the 3.18 - main milestone Nov 25, 2024
@quarkus-bot quarkus-bot bot removed the triage/waiting-for-ci Ready to merge when CI successfully finishes label Nov 25, 2024
Copy link

quarkus-bot bot commented Nov 25, 2024

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 17ddf2a.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.


Flaky tests - Develocity

⚙️ JVM Tests - JDK 17

📦 integration-tests/opentelemetry-vertx-exporter

io.quarkus.it.opentelemetry.vertx.exporter.grpc.SimpleGrpcNoTLSWithCompressionTest.test - History

  • Assertion condition defined as a Lambda expression in io.quarkus.it.opentelemetry.vertx.exporter.AbstractExporterTest Expecting Optional to contain a value but it was empty within 30 seconds. - org.awaitility.core.ConditionTimeoutException
org.awaitility.core.ConditionTimeoutException: 
Assertion condition defined as a Lambda expression in io.quarkus.it.opentelemetry.vertx.exporter.AbstractExporterTest 
Expecting Optional to contain a value but it was empty within 30 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
	at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:790)

⚙️ JVM Tests - JDK 17 Windows

📦 integration-tests/grpc-hibernate

com.example.grpc.hibernate.BlockingRawTest.shouldAdd - History

  • Condition with Lambda expression in com.example.grpc.hibernate.BlockingRawTestBase was not fulfilled within 30 seconds. - org.awaitility.core.ConditionTimeoutException
org.awaitility.core.ConditionTimeoutException: Condition with Lambda expression in com.example.grpc.hibernate.BlockingRawTestBase was not fulfilled within 30 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:975)
	at com.example.grpc.hibernate.BlockingRawTestBase.shouldAdd(BlockingRawTestBase.java:59)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins triage/flaky-test
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants