Can a plugin override a pants rule? We would like to override

DeployJar

rules instead of adding a new goal or new target. Is this possible?

Hello! It is not currently possible, although I've wondered in the past if we should let plugin authors "unregister" a rule For now, you'd want to use a new goal or new target

We have a plugin that instead of creating a fatjar it just collect all jars to a directory. It is faster (and cacheable) and we later containerize that directory. Regarding upstream, it can either be a new target or a flag on DeployJar? I think it would be useful when containerizing.

cc @witty-crayon-22786 @ancient-vegetable-10556, does that sound useful upstreamed? I know very little about deploy jar

We’d probably want a new target — there’s already

war

support, which I believe uses a new target. As for upstreaming, yes, absolutely, there are a plenty of valid use cases there. I think we focused only on

deploy_jar

because there was a user who needed it urgently.

It would probably be better as its own target. In my view, the target type models a specific class of output and fields configure aspects of that output but those aspects are still within that specific class of output.

deploy_jar

is intentionally runnable by

java -jar

. A flat directory of jars is not so runnable without special classloader support (which, for example,

war

files get by being run within a Servlet container, e.g. Tomcat). Thus, I submit a flat set of jars would be outside the “class” of

deploy_jar

.

Right, I’d probably call the sort of jar this plugin uses a

library_jar

or a

simple_jar

(slight preference for the former)

Longer term, I would like to see a general “assembly” plugin for JVM similar to the Maven Assembly plugin. https://maven.apache.org/plugins/maven-assembly-plugin/. Such a plugin for Pants would take a list of directions on how to layout an archive. A flat directory of jars could be one of the instructions (as it is in Maven although I don’t recall which assembly directive it is offhand).

yea, new target for sure.

v1

had some really weird semantics due to trying to pack too many behaviors (via boolean flags) into one target definition

Thanks all, we would work on making it upstream. At the moment we have issues with resources and "collect all jars to a directory" (we have the same issue with scalatest_tests), as the classloader is not able to load the resources, we suspect this is because the resources are on their own jar (although they are in the classpath). So trying to figure this out.

would suggest a new thread for the

resources

thing, but: you’ll want to check your source roots

source roots are actually fine, I will make a sample repo to reproduce and open an issue.

thanks!