For anyone interested, the approach I ended up taking was to AOT everything all
the time. But, require the class namespaces to be explicitly defined in the
build config file for any which needs to be included in the Jar. And when
packaging the Jar, only the Clojure source and the AOT class
rfield -- (970) FOR-SEAN -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> --
> *From:* clo...@googlegroups.com > on behalf o
-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
From: clojure@googlegroups.com on behalf of Didier
Sent: Friday, January 25, 2019 10:11:45 PM
To: Clojure
Subject: Re:
> On Jan 26, 2019, at 12:43 AM, Didier wrote:
>
> Okay, so after reading through the linked issue here:
> https://dev.clojure.org/jira/browse/CLJ-322 I'm not sure, as a tool builder,
> what is the ideal path forward.
>
> This is what I seem to understand would be ideal, let me know if I'm
Okay, so after reading through the linked issue here:
https://dev.clojure.org/jira/browse/CLJ-322 I'm not sure, as a tool
builder, what is the ideal path forward.
This is what I seem to understand would be ideal, let me know if I'm wrong:
1) AOT compile everything. So basically, always AOT
So I got to the bottom bottom of the problem here.
This is a scenario:
1) Library A depends on library B and Clojure 1.10
2) Library B must be AOTed due to a gen-class, but depends on Clojure 1.9
3) Library A does not work, because it is now using the Clojure core spec
1.9 compiled transitively
On 16 Jan 2019, at 18:17, Alex Miller wrote:
> Yes, it's one of the downsides of AOT.
I'd say it's not so much a downside of AOT - but of having a single output path
for classes. I've long wanted Chas's patch to be applied, or something like it.
Having everyone reinvent the mechanism whenever
Okay, I think I have a good understanding now.
Internally, I was using the Clojure build which bundles the dependency with it.
That's why that namespace shows up inside my Clojure Jar.
It makes sense also not to guarantee binary compatibility. We will make sure to
always build and run using
On Tue, Jan 15, 2019 at 10:43 PM Didier wrote:
> Okay, I found my issue, mostly.
>
> It seems that Clojure 1.9 and 1.10 both now have a
> clojure.core.specs.alpha.clj file.
>
> This file seems to be the only file that is not AOT compiled by the maven
> compile script for Clojure. Thus the Jar
Okay, I found my issue, mostly.
It seems that Clojure 1.9 and 1.10 both now have a clojure.core.specs.alpha.clj
file.
This file seems to be the only file that is not AOT compiled by the maven
compile script for Clojure. Thus the Jar for Clojure only has it as source, and
is missing the
:import works with either (personally I prefer []).
> On Jan 15, 2019, at 7:00 PM, Matching Socks wrote:
>
> This might have nothing to do with it, but, doesn't :import use parens?
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to
This might have nothing to do with it, but, doesn't :import use parens?
--
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
That file looks fine to me - can you post what libraries/classpath you're
using? I can't repro this with 1.10.
On Monday, January 14, 2019 at 8:39:49 PM UTC-6, Didier wrote:
>
> When compiling with Clojure 1.10, I get the following error, which I did
> not use to get on 1.7, 1.8 and 1.9:
>
>
13 matches
Mail list logo
