https://pantsbuild.org/ logo
Join Slack
Powered by
Hey! Been ripping some hair out trying to figure t...
# general
f
Hey! Been ripping some hair out trying to figure this one out, would appreciate any ideas! (JVM/Scala) There's a google cloud library that whenever included as a dependency within pants completely breaks 
deploy_jar
builds, but works fine when running a scala target directly. Running the jar target results in 
Error: Could not find or load main class ...
I made an absolutely minimal repro here, happy for any kind of input! 🙏
h
Sorry for the trouble, and thanks for the repro! That is very helpful.
👍 1
Hmm, shouldn't there be some definition of the target 
google-cloud-pubsub
?
f
Yeah the 
jvm_artifact
in the top-level BUILD, or do you mean something else?
Running the scala target is fine even with that dependency, seems to be with the deploy_jar
Explicitly setting the main class also does not help
And just to contribute everything, packaging the jar and running it separately has the same issue
h
Ah yes, sorry, missed that
OK, this is comprehensive, thanks
And this fully reproduces on my machine, so that was very helpful
🙏 1
f
This is a valid workaround for my real-life case as well https://github.com/jgranstrom/pants-google-cloud-pubsub-repro/pull/1 would be nice to handle in pants itself 🙂
h
Nice!
@fierce-truck-19259 want to send a PR to fix this in Pants? Looks like there's some guidance in the PR
👍 1
f
Yeah I can take a look tomorrow :)
🙏 1
Sorry for the delay, it didn’t fix my issue to translate the skip rules from v1 to v2. Not sure if paths are handled differently or those go through a different code path. But META-INF/…/*.RSA and company wasn’t even caught by them. Used throw actions to attempt to find them. I can only get it to work by excluding them completely from the final jar
Tried a bunch of permutations on top of main but feels like there’s something being missed somewhere
As if they are not duplicates but end up causing a bad signature by themselves
Excluding the RSA sign from the jar is the only thing needed to fix my repro, but even a policy on 
.*RSA
with action=throw is never hit, so I suspect something before or after is also involved, but don’t know enough about it to give it a proper dig
h
Thanks for taking a look! I'll poke at it too
🙏 1
f
Did you find anything on your end? It can be worked around but I bet it could cause some pain if people happen to run into similar cases
h
Ah, haven't gotten around to it yet, will take a look today
thanks for the reminder
f
No worries, and no stress, just checking in 🙂 Thanks!
h
Yeah, so as you intuited, the duplicates mechanism isn't the right solution here, because we need to eliminate all these signature files, not just the 2nd and beyond...
So this is a bit more complicated
we could change the default of the 
exclude_files
field - but then if you ever set that field explicitly for other reasons you'd have to repeat those default excludes in your setting
f
Yeah exactly, I also considered that but felt like it's very easy to get weird situations as soon as you actually need to set that to something else. Unless we maybe include them even on top of the user supplied exclude_files, but feel a bit iffy
h
I guess we could have a 
default_exclude_files
option that defaults to these and appends to 
exclude_files
, then you have an escape hatch
f
Yeah that could make sense I think
h
But even just changing the field default is better than where we are today
f
Yeah definitely
h
But also a little mysterious - "I set exclude_files and actually ended up with more files in my jar"
f
Yeah I guess the balance is between logical sense and usability on this one
I think it would probably do more good than harm, especially if documented well when someone wants to dig deeper
h
Went for the option, seems like the better route
Plus if there is some other signature or other file that causes problems, people can easily append to the value of that option once in their pants.toml (until we update the default)
f
Yeah looks good! 🙂
h
Thanks for the bug report!
This will get released in 2.21.x, but sounds like you have a workaround until then
✅ 1
f
Checked in on it and I think it ended up on 2.22 if I'm not mistaken, just in case someone catches the thread
👍 1
21 Views
Open in Slack
PreviousNext
Powered by