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

gRPC gradle plugin rework #983

Merged
merged 1 commit into from
Mar 26, 2020
Merged

Conversation

Scottmitch
Copy link
Member

Motivation:
0ebe48e divided the
servicetalk-grpc-gradle plugin into two files:

  1. an executable script
  2. an uber jar with the plugin logic
    The executable script assumed the uber jar would be co-located in the
    same directory as the uber jar, but that isn't the case in gradle
    caches. This means the plugin may fail to execute outside of the maven
    m2 repository structure.

Modifications:

  • Instead of publishing a static script for each platform which assumes
    a co-located uber jar, dynamically generate the executable script
    depending upon where the uber jar is resolved from for the local build.

Result:
servicetalk-grpc-gradle works with gradle cache directory structure and
local development.

File scriptExecutableFile
try {
if (org.gradle.internal.os.OperatingSystem.current().isWindows()) {
scriptExecutableFile = File.createTempFile(scriptNamePrefix, ".bat")
Copy link
Member Author

Choose a reason for hiding this comment

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

generation of temp files is not ideal ... but a reliable way to make sure we use the jar file that is actually resolved for each build. I'm open to alternatives @idelpivnitskiy

Copy link
Member

Choose a reason for hiding this comment

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

how grpc-java solves this issue?

Copy link
Member Author

Choose a reason for hiding this comment

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

they don't have to deal with this because they write their plugin in c++ and publish a single executable for each platform.

File scriptExecutableFile
try {
if (org.gradle.internal.os.OperatingSystem.current().isWindows()) {
scriptExecutableFile = File.createTempFile(scriptNamePrefix, ".bat")
Copy link
Member

Choose a reason for hiding this comment

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

how grpc-java solves this issue?

@Scottmitch
Copy link
Member Author

build failure attributed to #744

@Scottmitch
Copy link
Member Author

@servicetalk-bot test this please

Motivation:
0ebe48e divided the
servicetalk-grpc-gradle plugin into two files:
1. an executable script
2. an uber jar with the plugin logic
The executable script assumed the uber jar would be co-located in the
same directory as the uber jar, but that isn't the case in gradle
caches. This means the plugin may fail to execute outside of the maven
m2 repository structure.

Modifications:
- Instead of publishing a static script for each platform which assumes
a co-located uber jar, dynamically generate the executable script
depending upon where the uber jar is resolved from for the local build.

Result:
servicetalk-grpc-gradle works with gradle cache directory structure and
local development.
@Scottmitch
Copy link
Member Author

another failure attributed to #744

@Scottmitch Scottmitch merged commit 4a85c39 into apple:master Mar 26, 2020
@Scottmitch Scottmitch deleted the grpc_plugin_deps branch March 26, 2020 04:07
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.

2 participants