I just tripped over this and
opened https://issues.apache.org/jira/browse/MSHADE-272 . Affected users
might like to vote it up.
FWIW, my workaround:
maven-shade-plugin
...
Thanks for the feedback. I will try to track this issue via the
maven-shade-plugin then. Hopefully there can be some momentum to change it
there.
On Saturday, December 31, 2016 at 12:09:32 PM UTC-5, Alex Miller wrote:
>
> This seems like a pretty straightforward bug with maven-shade-plugin
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
I also forgot to include the error message from my example GitHub project,
in case it is easier than actually running it. I understand this issue for
the most part. It has still been a bit tricky for me to fully understand
how this AOT class interface/class is being referred to by any Clojure
I appreciate your input.
When we have controlled the Maven shade projects, we have been able to
workaround the issue as well. We actually add a
org.codehaus.mojo/exec-maven-plugin step where we re-open the shaded jar,
create a new jar, and re-add every file into the new jar via a script.
My workaround in a multi-module maven shaded java project with a clojure
module was to strip out CLJ files in the top-level build (shipped with
clojure.core jar).
I had also stripped CLJ files from my project artifact, but AOT compiles
classfiles from all referenced namespaces, so I attempted to
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
