-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Java build system enhancements #2866
Conversation
I'd prefer to remove all the Java related things out of cmake. We don't have to use cmake driving the java compilation. In order to make it part of the CI, we can add one extra step in win-ci-pipeline.yml. And we may directly use maven/gradle to do so. All of our Windows build machines already have gradle installed at %GRADLE_HOME%. You may invoke it directly. |
Yeah I moved all of the Java stuff out of the CMake except the piece that compiles the JNI shared object, which needs to stay. I chose the Gradle wrapper for ease of developers, since they won't have to install it and we can lock the version for compatibility purposes. The normal CI process should work just fine since the |
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.
What's the gradle-wrapper.jar ?
The gradle wrapper jar needs to be there since it is a part of the wrapper mechanism https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:adding_wrapper see the note in that section |
It's auto-generated right? Then why not generated it in the build? |
Can we avoid using Gradle Wrapper? I'd prefer to not download something from a third-party website during the build, because it adds extra risk. |
Azure Pipelines successfully started running 1 pipeline(s). |
Azure Pipelines successfully started running 8 pipeline(s). |
} | ||
System.load(tempFile.getAbsolutePath()); |
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.
So, if onnxruntime.dll has any dependencies that are not in the java.library.path, then this call will fail, right?
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.
I do not know precisely since I do not work in windows environments, but I believe the load call will load the file and whatever dependency configuration is set in the library file. Linux SO files can have relative, absolute, and rpath dependency locations. DLL's should probably have similar capabilities.
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.
It should check the system path for dependent libraries as it's basically a wrapper around the platform's dynamic library loader.
I'm fixing it. |
/azp run Linux CPU CI Pipeline |
Azure Pipelines successfully started running 1 pipeline(s). |
@Craigacp Do you think this PR is ready to merge? |
@snnn Assuming all the CI pipelines pass, yes. |
/azp run Linux CPU CI Pipeline,Linux GPU CI Pipeline,Linux GPU TensorRT CI Pipeline,MacOS CI Pipeline,Win CPU x86 CI Pipeline,Windows CPU CI Pipeline,Windows GPU CI Pipeline,Windows GPU TensorRT CI Pipeline |
/azp run Win CPU x64 NoContribops CI Pipeline,MacOS NoContribops CI Pipeline,Linux CPU x64 NoContribops CI Pipeline |
Azure Pipelines successfully started running 8 pipeline(s). |
Azure Pipelines successfully started running 3 pipeline(s). |
Ok cool the linux build works. The windows ci pipelines timed out because they took a long time for unknown reasons. Something is off given that most of the runs for that job take around 25 minutes. Any ideas? Sadly I do not have access to a windows environment, so any help would be appreciated. Does the gradle daemon keep running or something weird which prevents that stage from ending? I think my last CI build hung indefinitely after those pybind jobs were built. I can see the Java builds occurring in the logs. |
Something is wrong here. Windows build hangs forever. |
Let me try to disable gradle daemon. |
/azp run Linux CPU CI Pipeline,Linux GPU CI Pipeline,Linux GPU TensorRT CI Pipeline,MacOS CI Pipeline,Win CPU x86 CI Pipeline,Windows GPU CI Pipeline,Windows GPU TensorRT CI Pipeline |
/azp run Win CPU x64 NoContribops CI Pipeline,MacOS NoContribops CI Pipeline,Linux CPU x64 NoContribops CI Pipeline |
This time it should be ok. |
Azure Pipelines successfully started running 3 pipeline(s). |
Azure Pipelines successfully started running 7 pipeline(s). |
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.
Thank you so much!
Description: I cleaned up the CMake files to delegate building and testing to a Gradle build system. Gradle is manages java build/testing, dependencies, and packaging better than CMake. Additionally, all of the Java build output files are in a single output directory. I added a README which explains what JAR files and build output is generated. I relaxed the requirements in JNI loader in OnnxRuntime.java to allow for flexible loading of the library (i.e. from the os libpath or if the developer wants to load the library from some other way). If the developer wants to do that, then they would not use the
onnxruntime-lib.jar
. I attempted to build out an azure pipeline for the java build (based on the python build). I do not know how to test that. I would assume the maintainers would have to add it. I added spotless plugin to ensure formatting compliance. I selected a stock formatting profile (google's) and reformatted the project in a consistent manner. All changes to java files are formatting except OnnxRuntime.java. Not in this PR: I am playing around with Gradle's maven publishing mechanism.Motivation and Context