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

[Java] Package native dependencies into jar #4367

Merged
merged 6 commits into from
Mar 15, 2019

Conversation

raulchen
Copy link
Contributor

What do these changes do?

Package Java binary dependencies into the jar file, so the runtime won't depend on any relative paths. This change would make it easier to support maven and bazel simultaneously (#4284, cc @alegithub111 ).

Later, we can also build and distribute jars for mainstream platforms (just like the python wheels), so users don't need to compile the code by themselves.

Related issue number

@guoyuhong
Copy link
Contributor

Could this PR solve the problem of building Arrow using bazel in #4284 ? So we can pre-build arrow and put all the binaries to a jar file like the python wheel and during building of ray, we need only to download the jar file, right?

@raulchen
Copy link
Contributor Author

@guoyuhong yeah, we can do that.

@raulchen raulchen changed the title [Java] Package binary dependencies into jar [Java] Package native dependencies into jar Mar 14, 2019
@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/12871/
Test FAILed.

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/12875/
Test FAILed.

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/12876/
Test FAILed.

/**
* Copy a file from resources to a temp dir, and return the file object.
*/
private File getTempFile(String fileName) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better to declare this as a static method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-static should be fine. there's only one RunManager instance.

Copy link
Contributor

@guoyuhong guoyuhong left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

try {
// Reset library path at runtime.
resetLibraryPath();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need this function to set java.library.path?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, because users may pass in custom library path.

@raulchen raulchen merged commit f8d12b0 into ray-project:master Mar 15, 2019
@raulchen raulchen deleted the jar_pack_binaries branch March 23, 2019 03:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants