Skip to content

Conversation

@ceason
Copy link
Contributor

@ceason ceason commented Mar 18, 2019

This PR gets a jar's label from the 'Target-Label' MANIFEST.MF attribute when available (this is what java_common.{run_ijar,stamp_jar} both populate).

@ceason ceason requested a review from johnynek as a code owner March 18, 2019 19:24
Copy link
Contributor

@johnynek johnynek left a comment

Choose a reason for hiding this comment

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

this looks really nice.

I wonder if we can remove the current mechanism we have of carrying around labels in the skylark and instead just rely on the stamps.

What do you think @ittaiz ?

private def getJarLabel(jarPath: String): Option[String] = {
// First check the jar's manifest for a stamped label
Try(new JarFile(jarPath)).toOption.flatMap { jf
try {
Copy link
Contributor

Choose a reason for hiding this comment

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

can we change to:

try {
  val jf = new JarFile(jarPath)
  ...

rather than Try().toOption since we have a try following anyway? Seems a bit clearer

@johnynek
Copy link
Contributor

looks like this breaks some tests we have around unused dependencies.

Can you inspect those errors and see about fixing those tests? It may be that the test is over strict, or it may be that something really broke.

@ittaiz
Copy link
Contributor

ittaiz commented Mar 18, 2019 via email

@johnynek
Copy link
Contributor

This is still interesting but has seemed to get a bit stale.

@ittaiz can you take a look, and @ceason can you merge master?

@johnynek
Copy link
Contributor

@ittaiz is there someone on your end that can look at this? I know the skylark label propagation is something you all wanted. It would be great to switch to the same approach that java is using.

cc @andyscott @long-stripe if you are looking for clean up tasks. :)

@ittaiz
Copy link
Contributor

ittaiz commented Aug 17, 2019

We wanted it but due to disagreements with upstream java people we've dropped the usage. Essentially we allow label re-mapping (via export) whereas they determine the label at point of creation. @or-shachar maybe this is a relevant task for Shay?
It will take him through a few of the interesting places.

@ittaiz
Copy link
Contributor

ittaiz commented Aug 28, 2019

I think I’ll have someone in a month. If Long or Andy want to give it a crack I’ll be happy to guide them

@liucijus liucijus added the dep-tracking Strict/unused deps, label collections related issues label Mar 22, 2021
gergelyfabian pushed a commit to gergelyfabian/rules_scala that referenced this pull request May 31, 2022
* Use module names as package names
* Merge previously separate filter validation tests
* Move non-version specific tests to org.jacoco.core.test
@liucijus
Copy link
Collaborator

closing as stale, feel free to reopen

@liucijus liucijus closed this Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla: yes dep-tracking Strict/unused deps, label collections related issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants