raynes/bultitude

A namespace finder library.

bultitude's Issues

Bultitude doesn't work under Java 9

There are two issues here: the version of dynapath used (0.2.3) is broken under Java 9, but I'll send a PR in a few minutes to fix that.

The other issue is the AppClassLoader is no longer a URLClassLoader, so we can't read its classpath via dynapath. This means that any namespaces loaded by the App or Boot classloaders aren't visible to bultitude currently. You can see this if you update to dynapath 0.2.4, then try to lein test under java 9 (though you'll have to comment out the BOOTCLASSPATH="-Xbootclasspath/a:$LEIN_JAR" line in bin/lein, since there is an issue with that under Java 9 as well).

Split up namespaces-for-dir

Hi,
I just got a commit into lein that uses part of namespaces-in-dir for just a file. The fn in lein is rather hacky as it depends on a private fn. Would you take a pull to move this fn into bultitude and use it from namespaces-in-dir? I think I'd rename the fn to namespace-for-file.

Broken 0.2.3 release jar?

Just tried to use version 0.2.3 and get a zip file error. Here's what happens on the command line:

$ cd ~/.m2/repository/bultitude/bultitude/0.2.3
$ jar tf bultitude-0.2.3.jar
java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:128)
    at java.util.zip.ZipFile.<init>(ZipFile.java:89)
    at sun.tools.jar.Main.list(Main.java:977)
    at sun.tools.jar.Main.run(Main.java:222)
    at sun.tools.jar.Main.main(Main.java:1147)

I tried deleting and re-downloading: same deal.

Fails on unreadable files

I'm opening this issue in reference to #4.

License

I am a Debian developer packaging Clojure and Leiningen. Leiningen depends on this project and I'd like to package it. Could you please explicitly display license terms for this work?

`namespaces-in-dir` returns an empty list on `GraalVM CE 21.2.0`

Hi,

I'm developing a Clojure application and I'm using the Bultitude's namespaces-in-dir function to do a bunch of stuff with some NSs.

To simplify the situation, let's say that there is a directory named foo with several namespaces (NSs) in there.

At some point, and for debugging purpose I print the number of NSs found in foo:

(println "Found" (count (b/namespaces-in-dir "foo")) "namespaces in foo")

Running the uberjar, and with the following java version, I get the expected log: Found 69 namespaces in foo. Everything is good so far.
Java version:

openjdk 11.0.15 2022-04-19
OpenJDK Runtime Environment 18.9 (build 11.0.15+10)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.15+10, mixed mode, sharing)

Now, in a different environment, I'm using GraalVM to produce a native image from the uberjar.
Here is the java version:

openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment GraalVM CE 21.2.0 (build 11.0.12+6-jvmci-21.2-b08)
OpenJDK 64-Bit Server VM GraalVM CE 21.2.0 (build 11.0.12+6-jvmci-21.2-b08, mixed mode)

With this setup, and running the exact same command line invoking the exact same jar, I get the log Found 0 namespaces in foo.

Please can someone help me figure out what I did wrong?

Handling broken `ns` forms

One thing you can ask Midje to do from the repl is to load all of the test files. It uses bultitude (either namespaces-in-dir or namespaces-on-classpath) to find files that load. A problem is that new test files can contain errors in the ns statement (especially when they're created by copy-paste-and-edit). Because bultitude silently throws those files away, Midje doesn't load them, so the non-eagle-eyed user can be fooled into thinking all the tests passed, rather than that none of them were run.

(That non-eagle-eyed user would be me: marick/Midje#166 )

I wonder if it would be useful for read-ns-form to allow the reader's complaint here:
https://github.com/Raynes/bultitude/blob/master/src/bultitude/core.clj#L27
https://github.com/Raynes/bultitude/blob/master/src/bultitude/core.clj#L30
... to make it to standard out, standard error, or some state variable that could be queried by client code that cared.

(Probably best would be a second return value done the way Common Lisp does it. But we don't have that upgrade path.)

If one of these seems a reasonable thing, I'll make a pull request.

New maintainer?

@technomancy I see that you've committed directly to master on this project. Does this project need a new maintainer?

Rest in peace, Raynes.

Please tag release 0.2.8

Without the tag, source tarballs aren't automatically generated by GitHub.