the distinction is: resources go on the classpath of a jvm app

but bundles do not go on the classpath

so it wouldn't make sense for a library to depend on a bundle, because libraries should be thinking about classpaths

I agree that makes sense and might be the change we need to make. In our current setup we have a lot of files that live outside of the classpath that we depend on - shell scripts or groovy scripts that call methods inside Java code for example, or data files that are read from outside of the classpath. It would be nice to somehow attach these to the java_library targets so you could have the code, the resources (in the classpath) and the bundles (outside of the classpath) that are associated with the code.

how are they associated with the code?

the library expects to be able to load them at a fixed location?

(...outside the classpath)

yes. we have a $HOME/data directory outside of the classpath that code reads from, for example. we take data files from any of the projects that make up this service and combine them into a single data directory in our distribution.

another example of data is static files in webapp/ROOT that we gather from each project.

yea, i don't have a great solution there, unfortunately. bundles aren't super composable either.

pants biases toward using resources for things that will be loaded at runtime

and those are composable

see https://github.com/pantsbuild/pants/issues/2068 about improving the bundle situation.

can use symlinks, but it's awkward.

ok. we might be able to move some of it to the classpath, so I’ll think about that. I think more flexibility in the future around bundles would be helpful in my case.

we had some similar use cases @straight-waiter-86090

now for us it was fine to staple the exact same bunch of configuration/data files into each bundle

but I did end up scripting it after

./pants bundle

was finished

@witty-crayon-22786 I don't suppose you remember the issue I had where the scala compiler said a full rebuild was needed - could that be the under compilation talked about at https://github.com/sbt/zinc/issues/212 ?

turning off incremental compilation doesn't prevent the issue, I believe

no: a full rebuild would be the opposite of under-compilation

Related question to centralized pants daemon question I asked a couple weeks ago. I now have multiple agents in the build pool, each agent stands up a pants daemon for each build config, so there is multiple redundant daemons that live for the span of the build process which is fine. We moved the compiler cache to a common area on each agent so each daemon on that agent can access it, which is working well. We have an nginx-based webdav compiler cache tested and are ready to stand that up. I’d like to centralize the reporting server on the same machine as nginx. Is there a way to do this within pants (like a flag saying go dump your report to this URI)??

hm, good question... i'm not sure the run directory is configurable, but that would be quite neat.

are there any samples of pants adding resources on the fly to a target?

@purple-oil-45048 can you provide a little more detail on what you’re trying to accomplish? You can synthesize targets in a task, but I’m not sure about adding sources to existing targets. It can be done technically, I suspect, but I’m not sure about the implications for things like fingerprinting.

hi @happy-kitchen-89482 .. essentially I am trying to achieve the same as @acceptable-scooter-37412 did earlier. I intend to generate a

build.properties

file that ends up on the classpath for my bundle/jar

I am currently attaching my own task to the

resources

goal

Ah, in that case your task can synthesize a Resources target and add your properties file to it.

And your task can subclass

ResourcesTask

Actually, in that case you don’t need to synthesize a target