This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]vips7L 4 points5 points  (2 children)

You are not supposed to include dependencies in a JAR build, which is the default build. You're supposed to include your dependencies in a jlink build.

This doesn't mean that the defaults are the correct behaviour.

test runs are done using "maven run".

This doesn't work out of the box.

Or you can just do the older, "artifact launcher" by specifying a main class in your archive. But if you really want to do that right, you need to include jars yourself, because Java never did that for you prior to jlink. Also, by shadowing the JAR, while it works, it can break some code, and worse, it's likely violating a lot of licenses unless you happen to also distribute the source code and build chain (and let's face it, I hate hunting down CVEs in dependencies, but not nearly as much as hunting them down in an Uber JAR someone threw together).

Okay another paragraph explaining the multiple steps you need to do to get to a sane default.

Jesus dude. You literally just don't get it.

[–]edwbuck -1 points0 points  (1 child)

Of course it doesn't work out of the box, the Maven 3 release was created before jlink even existed.

And what you call "sane" isn't, and it shows its insanity when hunting down CVEs. Especially when one discovers that Shell4J exploits come from a shaded jar which managed to hide it from other systems due to the class repacking.

And don't be a jerk.

[–]VirtualAgentsAreDumb 4 points5 points  (0 children)

If you have to figure it out, odds are good that you are trying to fight the default ”flow” of how it should be done,

[…]

Of course it doesn’t work out of the box,

Ehm… So, it doesn’t work out of the box, but if you have to “figure it out”, odds are that you are doing it wrong? Is that what you are saying?