io.quarkus.builder.ChainBuildException: Cycle detected #860
Comments
|
Hi, I am having the same issue (ext version version 2.0.2 and quarkus 3.0.1-Final). This is my stack trace:
|
|
Is this just an empty project with no Java code? Could you please paste your pom.xml? |
|
@ppalaga No it's a gradle project with kotlin code. The |
So there is some code. Could you please post some minimal reproducer then? |
|
@ppalaga Sure, here is it. I have find out that the error occurs if I add the So if you clone the repository and comment |
|
Hi guys. Same here, just with Maven and version 2.0.2 of And here's my list of extensions (I noticed a missing After I comment out the |
|
Hm, I just figured out, that after I remove the @ghermaniov based on your stack trace you're also using S3, right? If so, did you try to remove it? |
|
@ppalaga The patch below addresses the cyclic dependency issues being described. However, I'm not familiar enough with the Proxy related changes that were added, and I couldn't find any test cases covering them, so not entirely sure if this is the ideal solution. Index: extensions/core/deployment/src/main/java/io/quarkiverse/cxf/deployment/CxfClientProcessor.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/extensions/core/deployment/src/main/java/io/quarkiverse/cxf/deployment/CxfClientProcessor.java b/extensions/core/deployment/src/main/java/io/quarkiverse/cxf/deployment/CxfClientProcessor.java
--- a/extensions/core/deployment/src/main/java/io/quarkiverse/cxf/deployment/CxfClientProcessor.java (revision 46033d79fc3d689407642ed65f6087a0ff5414f1)
+++ b/extensions/core/deployment/src/main/java/io/quarkiverse/cxf/deployment/CxfClientProcessor.java (date 1683479821733)
@@ -54,7 +54,6 @@
import io.quarkus.deployment.builditem.NativeImageFeatureBuildItem;
import io.quarkus.deployment.builditem.nativeimage.NativeImageProxyDefinitionBuildItem;
import io.quarkus.deployment.builditem.nativeimage.ReflectiveClassBuildItem;
-import io.quarkus.deployment.builditem.nativeimage.RuntimeInitializedClassBuildItem;
import io.quarkus.deployment.builditem.nativeimage.RuntimeInitializedPackageBuildItem;
import io.quarkus.deployment.util.IoUtil;
import io.quarkus.gizmo.ClassCreator;
@@ -75,7 +74,6 @@
void collectClients(
CxfFixedConfig config,
CombinedIndexBuildItem combinedIndexBuildItem,
- List<RuntimeInitializedClassBuildItem> runtimeInitializedClasses,
List<RuntimeInitializedPackageBuildItem> runtimeInitializedPackages,
BuildProducer<NativeImageFeatureBuildItem> nativeImageFeatures,
BuildProducer<NativeImageProxyDefinitionBuildItem> proxies,
@@ -83,9 +81,6 @@
BuildProducer<ClientSeiBuildItem> clientSeis) {
IndexView index = combinedIndexBuildItem.getIndex();
- final Set<String> rtInitClasses = runtimeInitializedClasses.stream()
- .map(RuntimeInitializedClassBuildItem::getClassName)
- .collect(Collectors.toSet());
final Set<String> rtInitPackages = runtimeInitializedPackages.stream()
.map(RuntimeInitializedPackageBuildItem::getPackageName)
.collect(Collectors.toSet());
@@ -121,7 +116,6 @@
Optional.ofNullable(clientConfig.native_).map(native_ -> native_.runtimeInitialized)
.orElse(false),
wsClassInfo,
- rtInitClasses,
rtInitPackages,
index);
proxies.produce(new NativeImageProxyDefinitionBuildItem(proxyInfo.interfaces));
@@ -469,7 +463,6 @@
public static ProxyInfo of(
boolean refersToRuntimeInitializedClasses,
ClassInfo wsClassInfo,
- Set<String> rtInitClasses,
Set<String> rtInitPackages,
IndexView index) {
final List<String> result = new ArrayList<>();
@@ -480,8 +473,7 @@
if (!refersToRuntimeInitializedClasses) {
/* Try to auto-detect unless the user decided himself */
- Predicate<String> isRuntimeInitializedClass = className -> rtInitClasses.contains(className)
- || rtInitPackages.contains(getPackage(className));
+ Predicate<String> isRuntimeInitializedClass = className -> rtInitPackages.contains(getPackage(className));
refersToRuntimeInitializedClasses = refersToRuntimeInitializedClasses(
wsClassInfo,
isRuntimeInitializedClass,
|
|
Thanks for the investigation, @shumonsharif! This proxy juggling was added to solve #580 The idea is to try to figure out automatically whether the the SEI method signatures refer to any class that requires runtime initialization and if so, then add a special package-visible interface to the proxy and register that package for late initialization. That was the most viable strategy how I could move GraalVM towards making the generated proxy class runtime initialized. There are two tests supposed to cover this:
As it happens none of them actually covers the case that the SEI method refers a class registered for postponed init through RuntimeInitializedClassBuildItem. clientWithRuntimeInitializedPayload relies on appilcation.propeties config whereas MtomAwtTest covers the RuntimeInitializedPackageBuildItem. I'd need to ponder a bit on what we should do. |
|
@knuspertante can you try with this branch ? |
|
Hey @scrocquesel, yes the build and test works fine with your branch! Thanks for your effort and amazing work! |
Good to know, I'll make a release soon. |
@knuspertante @ppalaga If the cycle cannot be easily broken in the CXF extension, here is my understanding of the cycle created when using CXF with The issue arises when other extensions emit The problem with the CXF extension occurs because it emits I believe the easiest is to break the cycle in this build step. To resolve this, it may be beneficial to split this build step into two separate build steps: one for List extensionSslNativeSupport and another for BuildProducer runtimeInit, BuildProducer runtimeReinit. Alternatively, in order to break the cycle when used with We maybe re-open quarkusio/quarkus#33955. |
|
great analyze. and java2wsdl consume GeneratedBeanBuildItem produce GeneratedResourceBuildItem so I think we can split CxfClientProcessor.collectClients in 2 build step. |
|
Sorry for the delay. After thorough pondering about the root cause and the proposed fixes, I am for fixing the issue in the following way:
What do others think? |
Sounds like a very good approach to me - thanks @ppalaga ! Hopefully soon enough the experimental flag will become default. |
Hello, I am trying to add the extension on a new project (ext version version 2.0.1 and quarkus 3.0.1-Final). The code is generated but the build fail with:
Execution failed for task ':infrastructure:quarkusAppPartsBuild'.
The text was updated successfully, but these errors were encountered: