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

improve the deploy jar creation #85

Merged
merged 4 commits into from
Aug 17, 2016
Merged

Conversation

johnynek
Copy link
Member

This does not pass the zip contents through the file system and makes deploy jar creation part a executable action. It should be both faster, but also safer for creation of deploy jars on linux systems (such as Docker or with encrypted home directories) that often have limited file lengths that might be violated by jars.

review? @ianoc @ittaiz ?

@bazel-io
Copy link
Member

Can one of the admins verify this patch?

jar=_get_jar_path(ctx.files._jar),
java=ctx.file._java.path,
manifest=ctx.outputs.manifest.path)
args = ["-m", ctx.outputs.manifest.path, ctx.outputs.deploy_jar.path]
Copy link
Member

Choose a reason for hiding this comment

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

what does -m stand for? Obviously a noob question but maybe should be a constant? a bit of a magic symbol?

@ittaiz
Copy link
Member

ittaiz commented Aug 16, 2016

@johnynek are there any tests around this feature? If not I'd add one or two. If there are then this does look like refactoring so it's not needed

@johnynek
Copy link
Member Author

@ittaiz there are existing tests that exercise this (the java consumption of scala deploy jars) and on top of that, this fixes the issue seen on linux (the contents of some jars were too long, so we could not make the fat jar).

@johnynek
Copy link
Member Author

@ittaiz I am not sure I follow. That flag is how we signal to the jar program that we are passing a manifest file. I think your suggestion is confusing, I don't understand it. In the interest of you saying "ship it" I am tempted to take the suggestion, but it seems to mislead the reader if we say "USE_EXISTING_MANIFEST_FLAG". What is the existing one? The ones in the inner jars?

By the way, we generally have not documented flags in other scripts. So this is a bit of a break to concern ourselves so deeply with this one flag.

I'll try one more time and see if you like it.

@johnynek
Copy link
Member Author

@ittaiz I updated the code. If you have any suggestions on how to improve the wording, please make a suggestion. Otherwise, I can merge and you can make a PR that improves it if you like.

I appreciate you taking the time to look at the change.

@ianoc
Copy link
Contributor

ianoc commented Aug 17, 2016

LGTM

@johnynek johnynek merged commit 5a6f332 into master Aug 17, 2016
@johnynek johnynek deleted the oscar/improve_deploy_jars branch August 17, 2016 19:19
petemounce pushed a commit to improbable-io/rules_scala that referenced this pull request Oct 20, 2016
* upstream/master:
  use strings rather than HOST/DATA_CFG
  Add cfg attribute on executable labels
  Switch to using shorter stack traces.
  Catch throwables from type errors
  make thrift targets quieter (bazelbuild#94)
  Fix jvm_flag support (bazelbuild#93)
  Make compile timing optional, with default false
  Update README.md
  Persistent/worker scala compiler (bazelbuild#91)
  fix typo in README.md (bazelbuild#89)
  Fix for thrift rule issue that manifests with remote repos (bazelbuild#83)
  improve the deploy jar creation (bazelbuild#85)
  Use bind's for twitter scrooge so local repo's can override scrooge and thrift versions (bazelbuild#84)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants