LantaoJin commented on code in PR #77:
URL: https://github.com/apache/datafusion-java/pull/77#discussion_r3280322316


##########
core/pom.xml:
##########
@@ -77,9 +83,34 @@ under the License.
                 <groupId>org.apache.maven.plugins</groupId>
                 <artifactId>maven-surefire-plugin</artifactId>
                 <configuration>
-                    
<argLine>-Djava.library.path=${maven.multiModuleProjectDirectory}/native/target/debug
 --add-opens=java.base/java.nio=ALL-UNNAMED</argLine>
+                    
<argLine>--add-opens=java.base/java.nio=ALL-UNNAMED</argLine>
                 </configuration>
             </plugin>
+            <plugin>
+                <groupId>org.apache.maven.plugins</groupId>
+                <artifactId>maven-antrun-plugin</artifactId>
+                <executions>
+                    <execution>
+                        <id>copy-native-lib</id>
+                        <phase>process-classes</phase>
+                        <goals><goal>run</goal></goals>
+                        <configuration>
+                            <target>
+                                <property name="datafusion.native.lib.source"
+                                          
value="${maven.multiModuleProjectDirectory}/native/target/${datafusion.native.profile}/${datafusion.lib.filename}"/>
+                                <fail message="Native library not found at 
${datafusion.native.lib.source}. Run 'cd native &amp;&amp; cargo build' (or 
'make') before building the JAR.">
+                                    <condition><not><available 
file="${datafusion.native.lib.source}"/></not></condition>
+                                </fail>

Review Comment:
   On Windows, none of the new native profiles defines 
`datafusion.lib.filename`, `datafusion.lib.os`, or `datafusion.lib.arch`, so 
this path remains unresolved and the new process-classes fail check aborts `mvn 
test/package` even after `cargo build` creates 
`native/target/debug/datafusion_jni.dll`. This regresses the previous 
`java.library.path` flow before `NativeLibraryLoader` can fall back to 
`System.loadLibrary`. One fix is adding a Windows profile mirroring the 
Linux/Mac ones: `<datafusion.lib.os>windows</datafusion.lib.os>`, 
`<datafusion.lib.arch>amd64</datafusion.lib.arch>`, 
`<datafusion.lib.filename>datafusion_jni.dll</datafusion.lib.filename>`. Even 
though no Windows binary will be bundled today, the build at least stops 
failing, or skipping the copy step on unsupported platforms.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to