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
Springboot forbids compression nested jars/archives, however, it does not (to my knowledge) forbid compression assets in the top-level jar. This rule set does disables all the compression on the final artifact, which can result in much higher archive sizes compared to the same application built in gradle for example.
It would be helpful to only disable compression on jars within the top level jar.
The text was updated successfully, but these errors were encountered:
I don't see an easy way to selectively compress some files and not others. To support Windows #25 , I am starting to wonder if we need to rewrite the packaging rule in Java. If we do that, we could also solve this pretty easily.
As of #72 we are now building the executable jar file using multiple invocations of jar command. This is possible because jar has an "update" option. For #72, we are doing this to insure insertion order is deterministic for classloading reasons. I wonder if this same technique could be used to compress some entries but not others.
Springboot forbids compression nested jars/archives, however, it does not (to my knowledge) forbid compression assets in the top-level jar. This rule set does disables all the compression on the final artifact, which can result in much higher archive sizes compared to the same application built in gradle for example.
It would be helpful to only disable compression on jars within the top level jar.
The text was updated successfully, but these errors were encountered: