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

Implement bazel Java sandwich #2614

Closed
iirina opened this Issue Mar 1, 2017 · 5 comments

Comments

Projects
None yet
5 participants
@iirina
Contributor

iirina commented Mar 1, 2017

bazel Java sandwich allows Skylark rules to depend on Java rules and the other way around. It allows the users to do Java compilation inside a Skylark rule.

This is a document that explains in more details the purpose of the sandwich, but it is only informative and does NOT contain the latest API and implementation details. An updated documentation will be added soon.

The current status of the sandwich:

  • Java compilation can be done in a Skylark rule
  • compiling Java inside a Skylark rule will return a (black-box) declared provider that must be returned by the rule
  • all native Java rules return this black-box, meaning that a Skylark rule can retrieve this black-box from all its Java dependencies and use them either as dependencies for a Java compilation, or just passing them further, for other rules to pick them up.

Some examples can be found in these tests (look for tests ending in java_sandwich).

The purpose of this issue is to track progress on Java sandwich. Reporting of bugs/feature requests should be done in new issues. Questions are welcomed.

@tomlu

This comment has been minimized.

Show comment
Hide comment
@tomlu

tomlu Mar 2, 2017

Contributor

Is this going to be powerful enough? If I'm reading the proposal right this will work for custom rules that transpile to Java, but it won't work for (say) Scala and similar because they will need a custom compilation action.

To implement that, it seems you'd have to be able to construct a java provider manually by feeding it the resulting jars from any compilation action. Is that part of this, or does that belong with another tracking issue?

Contributor

tomlu commented Mar 2, 2017

Is this going to be powerful enough? If I'm reading the proposal right this will work for custom rules that transpile to Java, but it won't work for (say) Scala and similar because they will need a custom compilation action.

To implement that, it seems you'd have to be able to construct a java provider manually by feeding it the resulting jars from any compilation action. Is that part of this, or does that belong with another tracking issue?

@ittaiz

This comment has been minimized.

Show comment
Hide comment
@ittaiz

ittaiz Mar 2, 2017

Member
Member

ittaiz commented Mar 2, 2017

bazel-io pushed a commit that referenced this issue Mar 10, 2017

Add java_common.create_provider to allow creating a java_common.provider
from already compiled jars.

Progress on #2614.

--
PiperOrigin-RevId: 149750579
MOS_MIGRATED_REVID=149750579

hermione521 added a commit that referenced this issue Mar 14, 2017

Add java_common.create_provider to allow creating a java_common.provider
from already compiled jars.

Progress on #2614.

--
PiperOrigin-RevId: 149750579
MOS_MIGRATED_REVID=149750579

bazel-io pushed a commit that referenced this issue May 12, 2017

Add resources to java_common.compile.
Progress on the java sandwich #2614 in an effort to make the Java compilation exposed to Skylark as similar as possible to java_library's API.

PiperOrigin-RevId: 155861145

bazel-io pushed a commit that referenced this issue Jun 29, 2017

Add exports param to java_common.compile.
This is a step forward to having the same semantics for java_library and custom Skylark rules that use java_common.compile, facilitating the migration from native Java rules to Skylark.

Progress on #2614

PiperOrigin-RevId: 160513771

bazel-io pushed a commit that referenced this issue Jul 3, 2017

Add plugins and exported_plugins params to java_common.compile.
This is a step forward to having the same semantics for java_library and
custom Skylark rules that use java_common.compile, facilitating the migration
from native Java rules to Skylark.

Progress on #2614

PiperOrigin-RevId: 160644961

bazel-io pushed a commit that referenced this issue Jul 3, 2017

Add recursive jars to java_common.create_provider
Progress on #2614.

PiperOrigin-RevId: 160649080

bazel-io pushed a commit that referenced this issue Nov 24, 2017

Create the output source jar in java_common.compile
and expose transitive source jars to Skylark.

Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes.

Creating the output source jar in java_common.compile makes the behavior more similar to java_library.

Exposing the transitive_source_jars to Skylark helps with the Skylark migration from the old 'java' provider to JavaInfo.

Progress on #2614.

RELNOTES: transitive_source_jars is now exposed on JavaInfo.
PiperOrigin-RevId: 176844750

femik added a commit to femik/bazel that referenced this issue Nov 26, 2017

Add java_common.create_provider to allow creating a java_common.provider
from already compiled jars.

Progress on #2614.

--
PiperOrigin-RevId: 149750579
MOS_MIGRATED_REVID=149750579

bazel-io pushed a commit that referenced this issue Nov 29, 2017

Create the output source jar in java_common.compile
and expose transitive source jars to Skylark.

Initial change was rolled back (unknown commit). java_common.compile wouldn't fill the JavaRuleOutputJarsProvider when there was only one input source jar. Fixed that and added test (there was one before, but didn't check this particular provider).

Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes.

Creating the output source jar in java_common.compile makes the behavior more similar to java_library.

Exposing the transitive_source_jars to Skylark helps with the Skylark migration from the old 'java' provider to JavaInfo.

Progress on #2614.

RELNOTES: transitive_source_jars is now exposed on JavaInfo.
PiperOrigin-RevId: 177311138

duggelz added a commit to duggelz/bazel that referenced this issue Dec 15, 2017

Create the output source jar in java_common.compile
and expose transitive source jars to Skylark.

Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes.

Creating the output source jar in java_common.compile makes the behavior more similar to java_library.

Exposing the transitive_source_jars to Skylark helps with the Skylark migration from the old 'java' provider to JavaInfo.

Progress on #2614.

RELNOTES: transitive_source_jars is now exposed on JavaInfo.
PiperOrigin-RevId: 176844750

duggelz added a commit to duggelz/bazel that referenced this issue Dec 15, 2017

Create the output source jar in java_common.compile
and expose transitive source jars to Skylark.

Initial change was rolled back (unknown commit). java_common.compile wouldn't fill the JavaRuleOutputJarsProvider when there was only one input source jar. Fixed that and added test (there was one before, but didn't check this particular provider).

Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes.

Creating the output source jar in java_common.compile makes the behavior more similar to java_library.

Exposing the transitive_source_jars to Skylark helps with the Skylark migration from the old 'java' provider to JavaInfo.

Progress on #2614.

RELNOTES: transitive_source_jars is now exposed on JavaInfo.
PiperOrigin-RevId: 177311138
@buchgr

This comment has been minimized.

Show comment
Hide comment
@buchgr

buchgr Mar 27, 2018

Contributor

can this be closed?

Contributor

buchgr commented Mar 27, 2018

can this be closed?

@sdtwigg

This comment has been minimized.

Show comment
Hide comment
@sdtwigg

sdtwigg Mar 27, 2018

Contributor

I think there is a latent question on making sure native dependencies are propagated in the non-java part of the sandwich (as exposed via https://docs.bazel.build/versions/master/be/java.html#java_binary.launcher).

However, that might be better as a separate issue?

Contributor

sdtwigg commented Mar 27, 2018

I think there is a latent question on making sure native dependencies are propagated in the non-java part of the sandwich (as exposed via https://docs.bazel.build/versions/master/be/java.html#java_binary.launcher).

However, that might be better as a separate issue?

@ittaiz

This comment has been minimized.

Show comment
Hide comment
@ittaiz

ittaiz Mar 28, 2018

Member
Member

ittaiz commented Mar 28, 2018

@buchgr buchgr closed this Mar 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment