using Classpath shrinker to warn on indirect targets #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The key change is that the scala provider has been completely restructured to match the structure of the JavaProvider. It no longer tracks exports separately but instead has the following fields: * outputs = contains all the outputs generated by the current rule (nothing or ijar and class_jar); however, no rules here actually use it. * compile_jars = contains all the jars dependent rules should compile with. Thus, ijar and exports.compile_jars * transitive_runtime_jars = contains all the jars needed to handle this target at runtime. Thus, class_jar plus (deps + exports + runtime_deps).transitive_runtime_jars The created java provider (used by dependent native java rules) uses just compile_jars and transitive_runtime_jars. In general, this change was seamless. The major exception is if you were specifically relying on only exports being re-exported by specifically gen_scrooge_srcjar. Beforehand, any jars produced by direct dependencies were not being exported to dependents but now they are. Note that, if you were using scrooge_scala_library instead, nothing should change. Other changes: * Use depset instead of set. (set docs already say set should be considered deprecated and just points to depset anyway) * Tests amended to exploit that JavaProvider is properly constructed. Note that things are still a little strange until Bazel releases incorporate some fixes to JavaProvider and native provider rules. Generally, only deps for java_library and java_binary work at the moment.
Remove scala_exports_to_java Prefer using JavaProvider over scala provider (can probably avoid using scala provider completely?)
|
relates to bazelbuild#235 |
|
@nadavwe , there were two bugs related to string encoding/escaping. both are fixed now |
|
1) would you like me to review?
2) are you copying the code in? If not should I review it in the other repo?
…On Thu, 29 Jun 2017 at 12:17 Natan Silnitsky ***@***.***> wrote:
@nadavwe <https://github.com/nadavwe> , there were two bugs related to
string encoding/escaping.
first, we encoded the jars and targets with ":" instead of "," to the temp
file read by the worker.
second, specifically for targets, they contain ":", themselves, so they
needed to be escaped...
both are fixed now
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABUIFy1WeNYamqJHiqDZ7e35zg--o-3Kks5sI2uVgaJpZM4OIJnJ>
.
|
|
|
Will do
…On Thu, 29 Jun 2017 at 12:35 Nadav Wexler ***@***.***> wrote:
@ittaiz <https://github.com/ittaiz>
1. please do - i think this is a bit too POC code yet - it should have
major beautification refactoring.
2. please review in the other repository anyway and we can decide on
copying later.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABUIF6-3Hd7Hj5h1iDyKnsKcsIiNvcbuks5sI2_HgaJpZM4OIJnJ>
.
|
ittaiz
requested changes
Jul 2, 2017
| @@ -0,0 +1 @@ | |||
| /Users/natans/Work/rules_scala/bazel-genfiles/external/scala/_ijar/scala-compiler/external/scala/lib/scala-compiler-ijar.jar:/Users/natans/Work/rules_scala/bazel-genfiles/external/scala/_ijar/scala-library/external/scala/lib/scala-library-ijar.jar | |||
There was a problem hiding this comment.
why do you need this? only for tests? take a look at $location expansion on bazel.build
| | org.apache.commons.lang3.ArrayUtils.EMPTY_BOOLEAN_ARRAY.length | ||
| |} | ||
| """.stripMargin | ||
| val commonsPath = Coursier.getArtifact(commons) |
There was a problem hiding this comment.
this looks like a really problematic pattern for a bazel build. why not have "commons" in the deps?
plugin/src/test/BUILD
Outdated
| deps = ["//main:dependency_analyzer", | ||
| "@io_get_coursier_coursier_cache//jar", | ||
| "@io_get_coursier_coursier//jar", | ||
| "@org_scalaz_scalaz_concurrent_2_11//jar", |
There was a problem hiding this comment.
why do you need this? also, why do you need the scalaz stuff?
instead of overloading jvm_flags for both scalac and executable (breaking change)
…ention deprecation of jvm_flags
* Restructure scala provider, add JavaProvider The key change is that the scala provider has been completely restructured to match the structure of the JavaProvider. It no longer tracks exports separately but instead has the following fields: * outputs = contains all the outputs generated by the current rule (nothing or ijar and class_jar); however, no rules here actually use it. * compile_jars = contains all the jars dependent rules should compile with. Thus, ijar and exports.compile_jars * transitive_runtime_jars = contains all the jars needed to handle this target at runtime. Thus, class_jar plus (deps + exports + runtime_deps).transitive_runtime_jars The created java provider (used by dependent native java rules) uses just compile_jars and transitive_runtime_jars. In general, this change was seamless. The major exception is if you were specifically relying on only exports being re-exported by specifically gen_scrooge_srcjar. Beforehand, any jars produced by direct dependencies were not being exported to dependents but now they are. Note that, if you were using scrooge_scala_library instead, nothing should change. Other changes: * Use depset instead of set. (set docs already say set should be considered deprecated and just points to depset anyway) * Tests amended to exploit that JavaProvider is properly constructed. Note that things are still a little strange until Bazel releases incorporate some fixes to JavaProvider and native provider rules. Generally, only deps for java_library and java_binary work at the moment. * Using JavaProvider, requires Bazel 0.5.2 Remove scala_exports_to_java Prefer using JavaProvider over scala provider (can probably avoid using scala provider completely?) * update minimum bazel version to 0.5.2
note we need 0.5.2 now.
* don't put signatures in fat jar * Add tests
Add a provider for binary targets
The key change is that the scala provider has been completely restructured to match the structure of the JavaProvider. It no longer tracks exports separately but instead has the following fields: * outputs = contains all the outputs generated by the current rule (nothing or ijar and class_jar); however, no rules here actually use it. * compile_jars = contains all the jars dependent rules should compile with. Thus, ijar and exports.compile_jars * transitive_runtime_jars = contains all the jars needed to handle this target at runtime. Thus, class_jar plus (deps + exports + runtime_deps).transitive_runtime_jars The created java provider (used by dependent native java rules) uses just compile_jars and transitive_runtime_jars. In general, this change was seamless. The major exception is if you were specifically relying on only exports being re-exported by specifically gen_scrooge_srcjar. Beforehand, any jars produced by direct dependencies were not being exported to dependents but now they are. Note that, if you were using scrooge_scala_library instead, nothing should change. Other changes: * Use depset instead of set. (set docs already say set should be considered deprecated and just points to depset anyway) * Tests amended to exploit that JavaProvider is properly constructed. Note that things are still a little strange until Bazel releases incorporate some fixes to JavaProvider and native provider rules. Generally, only deps for java_library and java_binary work at the moment.
|
changes were merged to upstream in bazelbuild#243. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this is written in top of bazelbuild#227.
@natansil - we should probably rebase on master.
this still fails - we have something unexpected regarding the output targets, need to investigate.
@ittaiz @or-shachar