This seems like a pretty straightforward bug with maven-shade-plugin not preserving information that it should, so it seems like it should be fixed there.
On Wednesday, December 28, 2016 at 7:06:11 AM UTC-6, Mike Rodriguez wrote: > > Background: > > This problem is specific to building jars that contain AOT (Ahead Of Time) > compiled Clojure code using Maven and the maven-shade-plugin. > > Clojure AOT compilation depends on timestamps of .class files vs .clj > files being accurate. When both .class files and their associated .clj > files exist, the AOT .class files are only used by the compiler if their > last modified timestamp is strictly greater than the last modified > timestamp of the associated .clj file. > > Also note that the Clojure core jar itself is deployed AOTed. > > I know that much of the Clojure ecosystem uses Leiningen as a build tool > (and boot now too I guess). This problem doesn't apply to Leiningen (and I > haven't looked at boot). > > Problem: > > The maven-shade-plugin is popular for building shaded/uber/standalone jars > in Maven. Typically this means the jar will include some/all of its > dependency jars' files. The maven-shade-plugin has an unfortunate property > though. It does not preserve the timestamps on files that are added to > this final shaded jar. The resulting jar actually ends up with all files > inside of it having the same timestamp (when the jar was created). In > particular, if you originally had AOT Clojure .class files and .clj files > with different last modified timestamps, now they will have the same > timestamps in the shaded jar. > > I've brought this up before @ > http://stackoverflow.com/questions/19594360/preserving-timestamps-on-clojure-clj-files-when-building-shaded-jar-via-maven-s > > I have rarely seen people bring up issues around this with > maven-shade-plugin beyond this particular case. I believe I have seen a > complaint or two around the timestamp loss during shading (I can't find > them now), but nothing that has gained any traction (I may try to bring it > up to the plugin people soon though). > > When the AOTed .class file is ignored in favor of the .clj file, the > namespace is JIT (Just-In-Time) compiled. There are several issues with > this. > > 1) Performance: It makes the AOT files mostly worthless since they are > not saving you on startup time costs anymore. Everything is JITed anyways. > 2) Errors: The reloading of the .clj files is a forced reload of the .clj > namespaces involved. This can cause classpath clashes among ClassLoaders. > - There are quite a few CLJ Jiras out there that faced trouble dealing > with the mix of reloading namespaces and AOT compilation. > > You may be thinking, "Just don't build your Clojure jars with Maven. Use > Leiningen instead perhaps?" > This is fine when it is something you control. However, what if I want to > use Clojure to develop a library that may be consumed by Java consumers who > very likely will be using Maven. If my library is going to be shaded into > a standalone jar with maven-shade-plugin by this Java consumer (again, > likely) then this scenario can happen. > > Another thought that may occur is to just avoid AOT compilation of my > library application to avoid the problem (this is recommended in the > community I believe). However, Clojure core is AOT compiled and it will > get included in the shaded jar. That alone is enough to cause the issue. > > Example: > > I have a GitHub repo to show a minimum example of where this can be a > problem. In particular it shows a way for the problem (2) to occur. > @ https://github.com/mrrodriguez/mvn-shade-test > > This repo has a Java API through shade.ShadeJava that will cause the > Clojure compiler to require the shade.main namespace using JIT compilation. > However, shade.main uses clojure.pprint, which is AOT compiled via Clojure > core. > > clojure.pprint was chosen here just because it one of the cases I've seen > come up that actually fail with problem (2) from above. Even if there were > no failures though, the Clojure core namespaces would be getting recompiled > with problem (1). > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
