-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Maven: enable configuring maven.top-level-basedir
in quarkus:dev
#46145
Maven: enable configuring maven.top-level-basedir
in quarkus:dev
#46145
Conversation
Thanks for your pull request! Your pull request does not follow our editorial rules. Could you have a look?
This message is automatically generated by a bot. |
Marking as a draft, because I need to figure out if there's a way to write a test for this. |
maven.top-level-basedir
in quarkus dev
maven.top-level-basedir
in quarkus:dev
The `quarkus:dev` configuration `copySurefireVariables` that was added recently used to copy values without interpolating them. This is not desirable and this commit fixes that by using what Maven also uses to configure mojos: `PluginParameterExpressionEvaluator`.
The `quarkus:dev` goal now reads `maven.top-level-basedir` from its `systemProperties` configuration (which is potentically copied from Surefire if `copySurefireVariables` is set) and if set, configures the root project directory for the `BootstrapMavenContext`. This effectively means that the `maven.top-level-basedir` configuration may occur not just in a system property, but also in the POM.
8790a30
to
9f4118b
Compare
maven.top-level-basedir
in quarkus:dev
maven.top-level-basedir
in quarkus:dev
Added test, marking as ready. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Ladicek !
Status for workflow
|
Status | Name | Step | Failures | Logs | Raw logs | Build scan |
---|---|---|---|---|---|---|
✖ | Build report | Produce report and add it as job summary |
Logs | Raw logs | 🚧 |
You can consult the Develocity build scans.
Flaky tests - Develocity
⚙️ JVM Tests - JDK 17
📦 extensions/smallrye-reactive-messaging-kafka/deployment
✖ io.quarkus.smallrye.reactivemessaging.kafka.deployment.testing.KafkaDevServicesContinuousTestingWorkingAppPropsTestCase.testContinuousTestingScenario3
- History
io.quarkus.builder.BuildException: Build failure: Build failed due to errors [error]: Build step io.quarkus.redis.deployment.client.DevServicesRedisProcessor\#startRedisContainers threw an exception: java.lang.RuntimeException: org.testcontainers.containers.ContainerLaunchException: Container startup failed for image docker.io/redis:7 at io.quarkus.redis.deployment.client.DevServicesRedisProcessor.startRedisContainers(DevServicesRedisProcessor.java:124) at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:732) at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
-java.lang.RuntimeException
java.lang.RuntimeException:
io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[error]: Build step io.quarkus.redis.deployment.client.DevServicesRedisProcessor#startRedisContainers threw an exception: java.lang.RuntimeException: org.testcontainers.containers.ContainerLaunchException: Container startup failed for image docker.io/redis:7
at io.quarkus.redis.deployment.client.DevServicesRedisProcessor.startRedisContainers(DevServicesRedisProcessor.java:124)
at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:732)
at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
at io.quarkus.builder.BuildContext.run(BuildContext.java:255)
at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
Should this be backported to 3.19? |
I don't think this warrants a backport, but I don't really feel strongly on either side. |
Fixes #22321