java_common.compile should support neverlink

[ittaiz]

Please provide the following information. The more we know about your system and use case, the more easily and likely we can help.

Description of the problem / feature request / question:

given I call java_common.compile with a dependency which is neverlink I expect its jar to be added as a compile time dependency but not added as a runtime dependency.
According to a discussion @iirina and myself had over #3528 it seems this isn't the case and will probably cause classpath pollution.

[ittaiz]

@iirina - Will you be tackling this one after #3769?
This will be great to try and finalize the advancement of java_common compile and create_provider

[iirina]

Yes - but the progress won't be that fast on these issues, I had to prioritize some other things. They are scheduled for Q4.

[ittaiz]

friendly ping

[iirina]

@ittaiz This will have to wait for Q1.

[ittaiz]

I wonder if, given specific need of rules_scala where I have another provider which I create myself, I'm blocked with this or not. Any ideas?

[iirina]

I don't understand, can you provide more details?

[ittaiz]

ok, scratch my previous statement.
I think that this might block our adoption of the new create_provider API.
Given the new API is more high level and only accepts one actual file (output_jar) then rules_scala will have to use the JavaInfo provider returned from java_common.compile. Given this provider is deeply flawed in propagating the neverlink onto to the classpath that is a problem.
I also thought of taking the full jar from the java_common.compile and creating a new provider but then I'd either have to forego ijars in my java (if in the manual java provider I will create an ijar bazel will error that both actions created the same file).

[iirina]

Thanks @ittaiz for explaining. I'm looking into this now. I'll try implementing it this week.

Given the new API is more high level and only accepts one actual file (output_jar) then rules_scala will have to use the JavaInfo provider returned from java_common.compile.

So you don't have the neverlink problem with the current version of create_provider? How come you can replace the JavaInfo created from jars with the one returned by java_common.compile? Also with the new constructor you can set neverlink.

Given this provider is deeply flawed in propagating the neverlink onto to the classpath that is a problem.

This I agree with and will be solved ASAP.

I also thought of taking the full jar from the java_common.compile and creating a new provider but then I'd either have to forego ijars in my java (if in the manual java provider I will create an ijar bazel will error that both actions created the same file).

Yes let's not do this.

[ittaiz]

Thanks!
Re "So you don't have the neverlink problem with the current version of create_provider?"- we don't since we just take the jars (full and ijar) and manually add them to the java info we create for the scala code (since it works with raw jars)
Re "Also with the new constructor you can set neverlink."- which new constructor? Of create provider? That's not my problem. My prolem is when you have neverlink dependencies

[ittaiz]

Hi,
What is the status of this issue?

[ittaiz]

@helenalt this might become another blocker

[iirina]

Sorry Ittai for the lack of replies, I have been caught up in something else. There is no update on this. Work on java_common had to be deprioritized for a while. I'm back on it now.

My prolem is when you have neverlink dependencies

I don't understand the problem. Dependencies of what? If the neverlink attribute will be available on java_common.compile, wouldn't that solve this issue?

Do you need this in bazel 0.11.0?

[ittaiz]

What I meant is that if we change semantics on java provider from files (current) to dependencies (WIP) then I’ll have a big problem because I can’t do the manipulation I do today.
Does that make sense?
And yes, we will need it for 0.11.0

[iirina]

What I meant is that if we change semantics on java provider from files (current) to dependencies (WIP) then I’ll have a big problem because I can’t do the manipulation I do today.

Can you give me an example of how you use the current java_common.create_provider for neverlink? I think it will be easier for me to explain on examples.

And yes, we will need it for 0.11.0

Noted. The neverlink attribute on java_common.compile should reach 0.11.0 (#3959)

[ittaiz]

Thanks! If I understand this commit it does two things: 1. Allows creation of JavaInfo from java_common.compile with never link attribute 2 Makes java_common.compile respect the neverlink attribute Is that correct? I now re read your previous question and understood where we had the miscommunication. I can’t use the neverlink flag today from skylark because the skylark API is low level and talks about files (jars) and my big need for *this* issue is so I will be able to adopt the new create_provider API which will hopefully rolled out soon.

…

On Wed, 31 Jan 2018 at 21:09 bazel.io machine account < ***@***.***> wrote: Closed #3735 <#3735> via 223ed93 <223ed93> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3735 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF04wdr61AmQD90vGkw-0_bSwnWrHks5tQLpXgaJpZM4PXdhU> .

[ittaiz]

@iirina will java_common.compile "respect" the neverlink attribute on a JavaInfo that was created with a neverlink attribute (when it tries to create its own JavaInfo)?

[iirina]

Yes!