This message was deleted.
# community-support
s
This message was deleted.
v
Including
gatlingCompileClasspath
is a bad idea. That one is for compiling and for example also contains
gatlingCompileOnly
dependencies. You really shouldn't include those at runtime. The
application
plugin sets the classpath to the jar task outputs plus runtime classpath.
Alternatively, to pick up the "other project" idea you had, you could expose that source set as a separate feature variant and then consume that feature variant in the separte project where you then use the standard
application
plugin facilities.
Regarding
distZip
and
distTar
, those are coming from the
distribution
plugin, which is applied by the
application
plugin. The
application
plugin just configures its
main
distribution, but you could as well add a second distribution that you then configure accordingly if you do not go the separate-project-approach.
i
Do you have an example of configuring the
distribution
plugin for a custom source set?
v
Not more than linking you to the application plugin code again, which configures the
main
distribution
But it basically just configures to put the
runtimeClasspath
to
lib/
, the generated start scripts to
bin/
- or the configured exectuable dir - with filemode
0755
and everything in
src/dist
directly to the root directory.
i
The
application
plugin sets the classpath to the jar task outputs plus runtime classpath.
Do you know the GitHub link of where they do this? I'm not knowledgeable enough of plugin structure to find it myself…
v
i
Thanks, I'll look into it.