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
I don't think the excludes are necessary as, unlike the loader, the layer tools are not unpacked. The reproducible ordering and timestamps are to improve cache hits and up-to-date checking at build time. We should either sacrifice those for the benefit of our users or we should apply the settings to the published artifact and then just use it as-is.
We may also want to consider a slightly larger change where we try to use Maven or Gradle to add the dependency to the app. This would mean that the jar was no longer embedded within spring-boot-loader-tools and we could just use the published artifact as-is. I think that would be relatively straightforward with Gradle. I'm not sure if it's possible with Maven.
The text was updated successfully, but these errors were encountered:
The difference in the hash is due to two things:
The differences are caused by this configuration:
spring-boot/spring-boot-project/spring-boot-tools/spring-boot-loader-tools/build.gradle
Lines 55 to 63 in a0dd6ef
I don't think the excludes are necessary as, unlike the loader, the layer tools are not unpacked. The reproducible ordering and timestamps are to improve cache hits and up-to-date checking at build time. We should either sacrifice those for the benefit of our users or we should apply the settings to the published artifact and then just use it as-is.
We may also want to consider a slightly larger change where we try to use Maven or Gradle to add the dependency to the app. This would mean that the jar was no longer embedded within
spring-boot-loader-tools
and we could just use the published artifact as-is. I think that would be relatively straightforward with Gradle. I'm not sure if it's possible with Maven.The text was updated successfully, but these errors were encountered: