Cleanup default classpaths for Clojure/ClojureScript and make them more configurable by ajoberstar · Pull Request #173 · clojurephant/clojurephant
This removes the need to provide a separate source set for Clojure code that the main source set depends on. This may be related to #172, but doesn't test for Clojure depending on Groovy/Kotlin/etc.
We need to ensure that the compile task was registered before we call compiledBy on the SourceDirectorySet. This new ordering should be solid.
This was legacy from the way we generated templates. It could be considered a breaking change for some if they relied on this, so should document it if they still want it.
It seems I'm getting a wider exception in the Prepl input loop sometimes, this AsynchronousCloseException instead of the ClosedByInterrupteException (which is a subclass) we used to get and were handling. This just caused some harmless, but confusing, stack traces in the Gradle output. This change should help clean that up.
This removes special logic we had to disable Clojure tasks when the repl was the only task requested at the command line. Instead, we're just being more explicit about which stuff we put on the classpath, and avoid having dependencies on any of the *classes tasks that pulled in all language compile tasks. The breaking change here is that compiled test Java classes will not be on the classpath anymore, however that doesn't seem like a common need. It will also be a little more fiddly to get other language classes on the classpath, but won't be terrible. This does revert b151ff1, so it will require some other solution to allow you to get your ClojureScript compiles on the classpath. I think this involves outputting to build/tmp/clojureRepl, but need to make that easier and let people get access to all of their build configurations.
ajoberstar
changed the title
minor(clojure): Allow Java code to depend on Clojure
Cleanup default classpaths for Clojure/ClojureScript and make them more configurable
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters