Time for bed. Thanks for your help @enough-analyst-54434

fwiw, I can make this fail —

object App2 {
  def main(args: Array[String]): Unit = {
    val loader = ClassLoader.getSystemClassLoader
    println(loader.getResources("db/migration").hasMoreElements)
  }
}

How bout with trailing /

I had a random thought that I’d try it in the linux jvm (was using my mac)

so everything is rebuilding simple smile

un momento

Nope, that doesn’t work either

Works in fat jar. works in the IDE when I “run”. Doesn’t work with java -cp ‘libs/*’ and doesn’t work with bundle jar.

K, it's up to you to dig or provide a test-case repo. I'm out of hack ideas from my phone

hehe okay

I tried "db/migration/V2016030454303__init.sql” and it works. So, just a problem with “scanning” for directories. I’ll reach out to the flyway people next week. Thanks again!

waves

Hey @witty-crayon-22786 I wanted to get more of an idea of what you had in mind for an overhaul in https://rbcommons.com/s/twitter/r/3830/. You say the diff would be small. Maybe I could take this over from @brash-oxygen-26029

@ancient-stone-50795: i just meant: creating synthetic targets

@ancient-stone-50795: this is really the entire idea:

In terms of matching existing expectations, it occurs to me that the clearest way to make these "act like generated code" is to pretend that they were codegen'd, and create a synthetic target for them. It would be a bit of a re-architecture of deferred sources, but essentially, have a unpacked_sources target with a lang parameter (similar to thrift_library), and have the UnpackJars task create a synthetic target of the appropriate type paired to the unpacked_sources target.

@rough-dog-96241: looking up "directories" on the classpath requires that jars have "directory" entries in them

so it's possible that the jars in use in the failing cases don't have directory entries

...just files

@limited-country-20626: what ended up happening with the release candidates for friday?

(sorry was off hipchat starting thursday@4pt)

The conversation about what version to use was still open at ~5:30pm Eastern so I pushed it back to today. Going to start putting together

1.1.0-pre0

soonish. There were some objections to that scheme but as far as I can tell this is where we landed.

pants-devel thread about naming here: https://groups.google.com/forum/#!topic/pants-devel/QwQJCRgH6lc

largest shrug regarding naming 😉

@witty-crayon-22786: awesome! Thanks for the response! For what it’s worth, pants actually is building the jar in question — this is a

jvm_library

whose “source” is a bunch of files. A

jvm_binary

lists that library as its “resources.” Is there a way to get the behavior I want?

hm... i didn't think it was possible to have a

jvm_library

as a resources target. i think you'd want a

resources(name=.., sources=..)

target

e.g.,

resources(
  name='resources',
  sources=rglobs('*'),

followed elsewhere by

jvm_binary(
  name = 'bin',
  dependencies = [
    'services/cupid/src/main/scala:lib'
  ],
  resources = [
    'services/cupid/src/main/resources:resources'
  ],
  main = 'com.civitaslearning.services.cupid.App',
)

ah, yea. ok.

Sorry, glad I pasted simple smile

I don’t see anything in the

resources

section of http://www.pantsbuild.org/build_dictionary.html that would suggest something of use.