This is an automated email from the ASF dual-hosted git repository.

davsclaus pushed a commit to branch chore/camel-launcher-its-not-quickly
in repository https://gitbox.apache.org/repos/asf/camel.git

commit 7f39d00a97add0909e3028154a6c298589b92750
Author: Claus Ibsen <[email protected]>
AuthorDate: Mon Nov 2 15:35:25 2026 +0100

    chore: camel-launcher - run the distribution ITs in verify, not with 
-Dquickly, and in the native exe workflow
    
    The snapshot deploy (-Dcamel.exe.build=true -Dquickly) failed in 
LauncherArchiveLayoutIT with a NoClassDefFoundError
    for CamelLauncher. The require-native-exe profile bound failsafe whatever 
-Dquickly says, and failsafe tested against
    the main JAR, which the repackager rewrites with the Spring Boot layout 
(classes under BOOT-INF/classes).
    
    - The failsafe execution moves to a profile of its own, active without 
-Dquickly, as the root POM does for surefire.
      The ITs still only run with -Dcamel.exe.build=true (their 
@EnabledIfSystemProperty).
    - failsafe uses target/classes instead of the repackaged JAR.
    - The "Build launcher with native camel.exe" step of 
camel-launcher-native-exe.yml runs the tests: it is the only
      build with the native exe files, so the ITs and PackagePlanTest ran 
nowhere before.
    
    Found by Aurelien Pupier in #28873.
    
    Co-Authored-By: Claude Opus 5.5 <[email protected]>
    Signed-off-by: Claus Ibsen <[email protected]>
---
 .github/workflows/camel-launcher-native-exe.yml |  5 ++++-
 dsl/camel-jbang/camel-launcher/pom.xml          | 23 +++++++++++++++++++++++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/.github/workflows/camel-launcher-native-exe.yml 
b/.github/workflows/camel-launcher-native-exe.yml
index 7a09a8963a51..4ef4ecb9c545 100644
--- a/.github/workflows/camel-launcher-native-exe.yml
+++ b/.github/workflows/camel-launcher-native-exe.yml
@@ -224,10 +224,13 @@ jobs:
         # Plain mvn: once -am is gone this reactor is only a few modules, so 
the mvnd
         # daemon brings no parallelism benefit and adds a cold-start failure 
mode.
         # -P apache-snapshots is required here so the upstream modules resolve.
+        #
+        # With the tests: this is the only build with the native exe files, 
which the tests that need
+        # -Dcamel.exe.build=true check (PackagePlanTest, and the *IT of the 
distributions in verify).
         run: |
           mvn -B -P apache-snapshots \
             -pl buildingtools,tooling/camel-exe,dsl/camel-jbang/camel-launcher 
verify \
-            -Dcamel.exe.build=true -DskipTests
+            -Dcamel.exe.build=true
       - name: Assert archive carries both exe files
         run: |
           ZIP=$(find dsl/camel-jbang/camel-launcher/target -maxdepth 1 -name 
'camel-launcher-*-winget-bin.zip' -print -quit)
diff --git a/dsl/camel-jbang/camel-launcher/pom.xml 
b/dsl/camel-jbang/camel-launcher/pom.xml
index bf8cf66cbed4..aed071e6eaf1 100644
--- a/dsl/camel-jbang/camel-launcher/pom.xml
+++ b/dsl/camel-jbang/camel-launcher/pom.xml
@@ -549,9 +549,32 @@
                             </execution>
                         </executions>
                     </plugin>
+                </plugins>
+            </build>
+        </profile>
+
+        <!--
+            The integration tests of the distributions (*IT), which need the 
native exe files and
+            only run with -Dcamel.exe.build=true (they are disabled 
otherwise). Not with -Dquickly,
+            as the root POM does for the unit tests, so a snapshot deploy does 
not run them.
+        -->
+        <profile>
+            <id>launcher-its</id>
+            <activation>
+                <property>
+                    <name>!quickly</name>
+                </property>
+            </activation>
+            <build>
+                <plugins>
                     <plugin>
                         <groupId>org.apache.maven.plugins</groupId>
                         <artifactId>maven-failsafe-plugin</artifactId>
+                        <configuration>
+                            <!-- the classes, not the JAR: the JAR is 
repackaged with the Spring Boot layout, where
+                                 the classes are under BOOT-INF/classes -->
+                            
<classesDirectory>${project.build.outputDirectory}</classesDirectory>
+                        </configuration>
                         <executions>
                             <execution>
                                 <goals>

Reply via email to