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

Unable to build native project depending on "quarkus-cache" without Vert.x dependency since 3.5.2 #38157

Closed
wglanzer opened this issue Jan 12, 2024 · 1 comment · Fixed by #38184

Comments

@wglanzer
Copy link

Describe the bug

Since quarkus 3.5.2 I'm unable to build without the "quarkus-vertx" dependency when using "quarkus-cache" and some of its caching features.

Just have a look at my demo class here or see my reproducer project, if you want ( https://github.com/wglanzer/quarkus-vertx-native-reproducer/tree/main ) :

package com.github.wglanzer.reproducer;

import io.quarkus.cache.CacheResult;
import io.quarkus.runtime.Startup;
import jakarta.enterprise.context.ApplicationScoped;

/**
 * @author w.glanzer, 12.01.2024
 */
@ApplicationScoped
public class DemoApp
{

  @CacheResult(cacheName = "demo")
  public String run()
  {
    return "cache" + System.currentTimeMillis();
  }

  @Startup
  public void start()
  {
    System.out.println(run());
    System.out.println(run());
    System.out.println(run());
  }

}

The pom.xml file looks something like this

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.github.wglanzer</groupId>
  <artifactId>quarkus-vertx-native-reproducer</artifactId>
  <version>1.0-SNAPSHOT</version>

  <properties>
    <quarkus.platform.version>3.5.2</quarkus.platform.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
  </properties>

  <dependencyManagement>
    <dependencies>
      <!-- Quarkus Universe -->
      <dependency>
        <groupId>io.quarkus.platform</groupId>
        <artifactId>quarkus-bom</artifactId>
        <version>${quarkus.platform.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <dependencies>
    <!-- Quarkus In-Memory Cache -->
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-cache</artifactId>
    </dependency>
  </dependencies>

  <build>
    <finalName>${project.artifactId}</finalName>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
      </plugin>

      <plugin>
        <groupId>io.quarkus.platform</groupId>
        <artifactId>quarkus-maven-plugin</artifactId>
        <version>${quarkus.platform.version}</version>
        <executions>
          <execution>
            <goals>
              <goal>build</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

  <profiles>
    <profile>
      <id>native</id>
      <activation>
        <property>
          <name>native</name>
        </property>
      </activation>
      <properties>
        <quarkus.package.type>native</quarkus.package.type>
      </properties>
    </profile>
  </profiles>
</project>

Expected behavior

The native build should compile successfully without the need of the internal used Vert.x dependency. Someone from outside should not need to consider including internal used parts, because .. they should stay internal, as long as the developer does not "really need it"

Actual behavior

The main exception is the following:

com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: Discovered unresolved type during parsing: io.vertx.core.Vertx. This error is reported at image build time because class io.quarkus.cache.runtime.CacheResultInterceptor is registered for linking at image build time by command line and command line.
Error encountered while parsing io.quarkus.cache.runtime.CacheResultInterceptor.intercept(CacheResultInterceptor.java:39) 
Parsing context:
   at io.quarkus.cache.runtime.CacheResultInterceptor_Bean.intercept(Unknown Source)
   at io.quarkus.arc.impl.InterceptorInvocation.invoke(InterceptorInvocation.java:42)
   at io.quarkus.arc.impl.AroundInvokeInvocationContext.perform(AroundInvokeInvocationContext.java:30)
   at com.github.wglanzer.reproducer.DemoApp_Subclass.run(Unknown Source)
   at root method.(Unknown Source)

How to Reproduce?

  1. Clone the reproducer or create a new project with the pom.xml and the class from above
  2. Execute a native compile with the "native" build profile
  3. An exception should appear on the console

Output of uname -a or ver

Darwin wglanzer-mb.home.lan 23.2.0 Darwin Kernel Version 23.2.0: Wed Nov 15 21:54:10 PST 2023; root:xnu-10002.61.3~2/RELEASE_X86_64 x86_64

Output of java -version

Java version: 21.0.1+12, vendor version: GraalVM CE 21.0.1+12.1

Quarkus version or git rev

3.5.2

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

Copy link

quarkus-bot bot commented Jan 12, 2024

/cc @gwenneg (cache), @zakkak (native-image)

geoand added a commit to geoand/quarkus that referenced this issue Jan 15, 2024
geoand added a commit to geoand/quarkus that referenced this issue Jan 15, 2024
geoand added a commit that referenced this issue Jan 15, 2024
Add necessary Vertx dependency to quarkus-cache
@quarkus-bot quarkus-bot bot added this to the 3.7 - main milestone Jan 15, 2024
@gsmet gsmet modified the milestones: 3.7 - main, 3.6.6 Jan 15, 2024
gsmet pushed a commit to gsmet/quarkus that referenced this issue Jan 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants