You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's with a heavy heart that I'm going to begin contemplating the gradle-shadow plugin. I've long felt one-jar was the most natural solution to the dependency bundling issue which if it had been adopted and refined by Sun/Oracle would have been a great step forward. One jar essentially allows the jar to contain a Plain Old Java Class Path within the jar. So (with a few esoteric exceptions) everything works/operates just like standard java class path. There's no room for issues with how the contents of the dependency jars were sprinkled into the final jar, nor need to combine service descriptors or any of that other stuff. If you understand standard java you don't need to learn/track any new processes to troubleshoot issues with your one-jar class path. (With the exception of libraries that also try to mess with the class path, or unusual security manager cases such as #89)
But time is moving on, and one-jar has not been maintained by it's author in many years (last checkin 4 years ago, before that 6 years ago... Worse yet the wonderful plugin by Ray Holder is now 2 years since any sign of maintenance and it doesn't work with gradle 4 👎 rholder/gradle-one-jar#31
The text was updated successfully, but these errors were encountered:
It's with a heavy heart that I'm going to begin contemplating the gradle-shadow plugin. I've long felt one-jar was the most natural solution to the dependency bundling issue which if it had been adopted and refined by Sun/Oracle would have been a great step forward. One jar essentially allows the jar to contain a Plain Old Java Class Path within the jar. So (with a few esoteric exceptions) everything works/operates just like standard java class path. There's no room for issues with how the contents of the dependency jars were sprinkled into the final jar, nor need to combine service descriptors or any of that other stuff. If you understand standard java you don't need to learn/track any new processes to troubleshoot issues with your one-jar class path. (With the exception of libraries that also try to mess with the class path, or unusual security manager cases such as #89)
But time is moving on, and one-jar has not been maintained by it's author in many years (last checkin 4 years ago, before that 6 years ago... Worse yet the wonderful plugin by Ray Holder is now 2 years since any sign of maintenance and it doesn't work with gradle 4 👎 rholder/gradle-one-jar#31
The text was updated successfully, but these errors were encountered: