Add support for dependency-filtering

[horschi]

Would it be possible to add inclusions/exclusions?

I would like to have some dependencies built into my jar, which is something I need for "system" scoped dependencies. Also there are some dependencies that require "requiresUnpack".

[horschi]

Sorry, I think this might be a duplicate of #15

Alternatively, might there be an alternative solution for system scope dependencies?

Currently I get this error message during launch:

Exception in thread "main" java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.springframework.boot.loader.wrapper.ThinJarWrapper.launch(ThinJarWrapper.java:140)
	at org.springframework.boot.loader.wrapper.ThinJarWrapper.main(ThinJarWrapper.java:107)
Caused by: java.lang.IllegalStateException: Cannot build model
	at org.springframework.boot.loader.thin.DependencyResolver.dependencies(DependencyResolver.java:243)
	at org.springframework.boot.loader.thin.PathResolver.extract(PathResolver.java:214)
	at org.springframework.boot.loader.thin.PathResolver.resolve(PathResolver.java:101)
	at org.springframework.boot.loader.thin.ThinJarLauncher.getClassPathArchives(ThinJarLauncher.java:355)
	at org.springframework.boot.loader.Launcher.launch(Launcher.java:49)
	at org.springframework.boot.loader.thin.ThinJarLauncher.launch(ThinJarLauncher.java:193)
	at org.springframework.boot.loader.thin.ThinJarLauncher.main(ThinJarLauncher.java:140)
	... 6 more

[WARNING] 'dependencies.dependency.systemPath' for xxx:jar should not point at files within the project directory, ${project.basedir}/lib/xxx.jar will be unresolvable by dependent projects @ line 82, column 16
[ERROR] 'dependencies.dependency.systemPath' for xxx:jar must specify an absolute path but is ${project.basedir}/lib/xxx.jar @ line 82, column 16

[dsyer]

Might be a duplicate. I'm not sure I understand your use case: "dependency-filtering" is a bit vague, and "inclusions and exclusions" are already supported, so you must mean something else.

[horschi]

I apologize for being so vague and for opening what seems to be a duplicate.

Let me be a bit more verbose:

I have the issue that I have a couple of system scoped dependencies in my application. These are of course not available where I deploy my application. Same is with dependencies to other parts of my application.

How can I exclude these dependencies from the "dynamic" dependency loading process? Instead I would like to include them into the application-jar file? Would I specify the exclusions in the configuration of spring-boot-maven-plugin and instead pack them using maven-dependency-plugin->copy-dependencies?

[dsyer]

My recommendation would be to not use scope=system for mandatory dependencies that you actually control - just deploy them to a maven repository (or the local cache if that's all you have). What is the actual nature of these "system" dependencies? You kind of imply that there are 2 kinds - some that are "part of the application" and some that are not? How did that come to be the case? How is it that the ones that are "part of the application" are not available as resolvable dependencies?

[horschi]

I don't have a own maven repo that I can deploy to and some dependencies are not publically available. So I include them as system-scoped dependency.

Then there is that second case where I have dependencies that are part of my application, that also are not available in public repos. Bonus complication: These could be snapshots :-)

[dsyer]

If you can always locate a jar file (for the system scoped dependency), you can put it in the local Maven cache (and use regular compile scope). That's a workaround at least. I'm not sure I understand the difference between that and the "second case".

[dsyer]

Seems like a duplicate of #78 and #109 (maybe). Installing in the local Maven cache is the right way to use dependencies that are not available remotely.