https://pantsbuild.org/ logo
Join Slack
Powered by
When publishing codegen jars, I’m noticing `Simple...
# general
g
When publishing codegen jars, I’m noticing 
SimpleCodegenTask
copies the 
provides
parameter from the concrete target to the synthetic target, resulting in two targets that provide the same artifact. I found this while attempting to publish a 
java_thrifty_library
, but also verified the same issue happens when attempting to publish a 
java_wire_library
. When creating the synthetic target, should the 
provides
parameter be moved to the synthetic target?
For example, here’s what publishing a 
java_wire_library
says:
Copy code
FAILURE: Multiple targets define the same artifacts!

  org.pantsbuild.contrib.thrifty#wire is defined by:
    .pants.d/gen/wire/252d64521cf9/contrib.thrifty.tests.thrift.org.pantsbuild.contrib.thrifty.common.wire/current:contrib.thrifty.tests.thrift.org.pantsbuild.contrib.thrifty.common.wire
    contrib/thrifty/tests/thrift/org/pantsbuild/contrib/thrifty/common:wire
e
This must be an indirect happy sign that Twitter no longer publishes thrift?!
😂 1
w
we definitely still do.
i'm guessing that 
java_thrift_library
is explicitly skipped in publishing or something
g
Correct, 
java_thrift_library
uses a different code path. What do you think about the idea of moving the provides from the concrete target to the synthetic target? Or have another idea? I’d like to publish these thrifty jars and can take a look.
w
moving would mean mutating, so not really in favor there
👌 1
you found a codepath in JarPublish that does something to explicitly skip 
java_thrift_library
?
i'm not able to see why 
java_thrift_library
succeeds there, but i don't think it has anything to do with mutation
haven't traced too deeply, but only targets matching this condition in JarPublish should be eligible:
Copy code
@staticmethod
  def _is_exported(target):
    return isinstance(target, ExportableJvmLibrary) and target.provides
g
I’ll file a github issue about this, and dig into the publishing code path. Thanks for the pointers.
Oh, I bet the issue is 
JavaThriftyLibrary
subclasses 
ExportableJvmLibrary
, when in fact it’t not exportable. Trying this out
w
ah, yea. shouldn't.
probably ditto wire and etc.
g
Looks like a few others do this too, some of which should and some should probs be removed.
Copy code
$ git grep -h ExportableJvmLibrary | grep class
class JaxWsLibrary(ExportableJvmLibrary):
class JavaThriftyLibrary(ExportableJvmLibrary):
class JavaWireLibrary(ExportableJvmLibrary):
class AnnotationProcessor(ExportableJvmLibrary):
class ExportableJvmLibrary(JvmTarget):
class JavaLibrary(ExportableJvmLibrary):
class ScalaLibrary(ExportableJvmLibrary):
w
the first 3 i think
g
I don’t want to cross the streams, so if this is the fix I’ll send a separate PR to fix.
w
an AnnotationProcessor is ~= a JavaLibrary, but with a bit more metadata
k
thanks!
g
That was totally it, I can publish now 💥
🔥 1
4 Views
Open in Slack
PreviousNext
Powered by