1

I would like to add a dependency to my maven project so that Maven can resolve the dependency, but not add it to the classpath. E.g.

<dependency>
    <groupId>com.example</groupId>
    <artifactId>example-artifact</artifactId>
    <type>bin</type>
    <classifier>jar-with-dependencies</classifier>
    <version>1.0</version>
</dependency>

In this particular case, the dependency is a FAT executable jar file, that I want to run from my Mojo. I don't want the contents of that jar file to pollute my mojo's classpath. I just want it treated as a binary file, so that I can look it up inside my mojo (via project.getArtifacts(), and then execute it as CLI.

I've tried both "zip" and "bin" packaging types, but it always seems to end up on the classpath.

I could bundle the zip inside another jar dependency and then extract/run it at runtime, but I would prefer to just figure out how to resolve it but exclude it from the classpath.

Any ideas?

steve hannah
  • 4,586
  • 11
  • 18
  • I have not really understood the use case. If you want to run it during the build, it should better be a part (or parameter/dependency) of the maven plugin you want to run. If you want to run it at runtime, then it should probably be added to the resulting artifact as resource. – J Fabian Meier Jan 19 '21 at 18:49
  • As a stop-gap I've added it as a resource to the artifact. This seems inefficient as it doesn't need to be on the classpath. I don't want it on the classpath. I want it to be a separate artifact so that maven will resolve it, and I can look up its location using project.getArtifacts() - but I don't want it on the classpath. – steve hannah Jan 19 '21 at 18:54
  • Just try to use the scope: runtime but the question is why do you like to add a dependenc y which you don't like to have it on the classpath? What is the relationship to a mojo ? Do you develop a mojo? – khmarbaise Jan 19 '21 at 19:16
  • Thanks. I don't want it on the classpath in runtime either. Yes, I develop the mojo. There are many reasons to have dependencies not on the classpath. One example of this is the dependency for maven plugins, vs build dependencies. You don't want your plugin dependencies to be added to your build classpath, and vice versa. I have a third execution context that I intend this dependency to be used for - not for plugin execution, and not for the app itself. It would be desireable to still have maven handle the dependency resolution, but just leave it up to me how I use the dependency. – steve hannah Jan 20 '21 at 13:44
  • There is another good reason for not having a dependency on the classpath: If my project has a dependency A v10 and a dependency B, which in turn depends on dependency A v9, then dependency A is needed in two different versions, but is only loaded once, given both versions of a have identical package names. With non-classpath dependencies I could use my own ClassLoader object to load B and thus A v9 when it is needed. – Kai Weber Aug 29 '21 at 10:05

0 Answers0