Fork me on GitHub
#babashka
<
2021-11-08
>
hugod04:11:39

Adding javax.xml.namespace.NamespaceContext and javax.xml.namespace.QName gets the jar task further, but then complains about definiline in clojure/data/xml/jvm/name.clj:35:2

borkdude06:11:43

Instead of adding this class add the namespaces that tools build loads from data.xml to bb

hugod11:11:25

where do you “add the namespaces”?

borkdude11:11:36

and in babashka/main.clj

hugod12:11:01

I’ve added them to the ns forms, but still get the same complaint. I’m not understanding how these changes should be solving the issue. Do I need to add a ns map for clojure.data.xml.jvm.name , copy decode-uri to it, and then add the namespace map to the feature import in main.clj ?

borkdude12:11:03

> I’m not understanding how these changes should be solving the issue. This will bake in those namespaces into bb rather than bb trying to load these namespaces from source which causes the issue you were seeing

borkdude12:11:59

The clojure/data/xml/jvm/name.clj namespace shouldn't even be loaded by bb, because tools.build is just loading xml.tree and xml.event. So it should stop there once you have baked those in and the error from jvm/name.clj should disappear.

borkdude12:11:03

so correction, don't add clojure.data.xml.jvm.name

borkdude12:11:08

just the namespaces that tools.build loads

hugod13:11:01

ok, so that gets us further. now Unable to resolve classname: org.eclipse.aether.RepositorySystem I’m assuming you don’t want that in bb

borkdude13:11:28

hmmhm. where does tools build pull that in?

hugod13:11:36

let me see if that is tools.build or something I’m doing

hugod13:11:14

clojure.tools.deps.alpha.util.maven will need to add that to the pod

borkdude13:11:00

sounds good

hugod14:11:41

clojure.data.xml.event actually extends a couple of protocols - are those extensions pulled in automatically somehow?

borkdude14:11:11

should be. but to extend the protocol further in user space, requires more config. do you have more details?

hugod14:11:31

I’ve added the utils.maven, and now get Unable to resolve classname: clojure.data.xml.node.Element,

borkdude14:11:53

@U0HFRSY0M I see in the tools build code that it does an instance check for this class

borkdude14:11:48

check classes.clj and search for :instance-checks

borkdude14:11:50

add the class there

borkdude14:11:00

this takes up almost no space in that case

borkdude14:11:49

you must wrap this in a condition for the xml feature btw

borkdude14:11:07

else the compilation without this feature will fail

hugod14:11:19

I built a jar 🙂

hugod14:11:34

with a pom

hugod14:11:10

I’ll update my bb pr and add one for the pod

borkdude14:11:58

so how much compatibility do we now have with tools.build? ;)

hugod15:11:54

can’t load compile-clj, install, javac or uber tasks yet

borkdude15:11:20

hmm javac is only depending on shelling out to some java process right?

hugod15:11:08

it’s referencing javax.tools.ToolProvider

hugod15:11:04

not shelling out

hugod15:11:06

uber is using JarInputStream JarOutputStream

borkdude15:11:12

ok, we can add those. the tool provider stuff can probably be replaced by just shelling out to java

borkdude15:11:28

perhaps we'll have to maintain a bb compatible fork

borkdude15:11:10

I'm curious if adding the javax.ToolProvider stuff to the pod would even work

hugod15:11:50

I’ll be back later

hugod11:11:29

I think a wrapper might be best. Maybe use mranderson to pull in build.tools and then just implement compile-clj, install, and javac, and use build.tools for the rest?

borkdude11:11:39

Or just a fork, so it's easier to pull changes?

borkdude11:11:47

tools.bbuild

hugod12:11:45

sounds good

hugod12:11:48

Do you want to create it? Or shoud I, then move it to you?

borkdude12:11:16

You can create it, we can decide later if we want to host in under the babashka org or not

borkdude12:11:28

And if we do, we can still add you as admin to maintain it

dpsutton15:11:57

Am i overlooking something? I’m trying to unzip a file and passing the option to overwrite the existing, but i’m getting an error that the file already exists

user=> (fs/unzip zip-download "/Users/dan/bin/clojure-lsp" {:replace-existing true})
java.nio.file.FileAlreadyExistsException: /Users/dan/bin/clojure-lsp [at <repl>:63:1]

borkdude15:11:52

perhaps another edge case I might have missed

dharrigan15:11:55

Could it be the case of macos case in-sensitivitity?

dharrigan15:11:03

That's bit me in the past

dpsutton15:11:15

all the casing here aligns though

dpsutton15:11:38

and presumably if the files have the same name (regardless of case) the copy attribute should do its job since they are the same file

borkdude15:11:24

user=> (fs/unzip "02-cpu-flamegraph-2020-06-28-13-15-27.svg.zip" ".")
java.nio.file.FileAlreadyExistsException: ./02-cpu-flamegraph-2020-06-28-13-15-27.svg [at <repl>:1:1]
user=> (fs/unzip "02-cpu-flamegraph-2020-06-28-13-15-27.svg.zip" "." {:replace-existing true})
nil

dpsutton15:11:24

oh i know what it is. my destination includes the name of the file i want to unzip (which already exists) rather than a destination to unzip to

borkdude15:11:27

you should specify a directory

borkdude15:11:29

not a target file

dpsutton15:11:52

yep. thanks

borkdude15:11:03

perhaps worth adding a check

borkdude15:11:09

for better error messages