Closed kjothen closed 4 years ago
Thanks James. Once this patch needs to be released (1.0.6?) to maven, ring will need to update its dependencies to use it (1.8.3?). I know you've just released ring 1.8.2 to maven to fix the jetty vulnerability, so I'm really very sorry I didn't include a link to this before you got to it. Together though, ring will pass the artifact scanning and so will hiccup.
Sorry, I'm not following. Why does Ring need an updated version of Hiccup?
Hi James - Hiccup is a dependency of ring-devel
only, which I recognise may only be intended to be used in a :dev profile. However, many dependent libraries bring the entire, convenient Ring package into their project rather than individual libs, eg figwheel-main. Hope that helps?
git clone https://github.com/ring-clojure/ring.git
git checkout tags/1.8.2
lein deps :tree
[clojure-complete "0.2.5" :exclusions [[org.clojure/clojure]]]
[nrepl "0.6.0" :exclusions [[org.clojure/clojure]]]
[ring/ring-core "1.8.2"]
[commons-fileupload "1.4"]
[commons-io "2.6"]
[crypto-equality "1.0.0"]
[crypto-random "1.2.0"]
[org.clojure/clojure "1.7.0"]
[ring/ring-codec "1.1.2"]
[commons-codec "1.11"]
[ring/ring-devel "1.8.2"]
[clj-stacktrace "0.2.8"]
[hiccup "1.0.5"]
[ns-tracker "0.4.0"]
[org.clojure/java.classpath "0.3.0"]
[org.clojure/tools.namespace "0.2.11"]
[ring/ring-jetty-adapter "1.8.2"]
[org.eclipse.jetty/jetty-server "9.4.31.v20200723"]
[javax.servlet/javax.servlet-api "3.1.0"]
[org.eclipse.jetty/jetty-http "9.4.31.v20200723"]
[org.eclipse.jetty/jetty-util "9.4.31.v20200723"]
[org.eclipse.jetty/jetty-io "9.4.31.v20200723"]
[ring/ring-servlet "1.8.2"]
Yes, I know Hiccup is a dependency of ring-devel. What I don't understand is why ring-devel needs an updated version of Hiccup.
I do see your point, it's not essential. All licenses in all dependencies are checked by the artefact scanning tool I'm required to use to bring an external library into my org. Now, I can skip rejected dependencies, which is fine for now. Ultimately, a version of hiccup with a license will be necessary, because many libs (other than ring-devel) need it. It's the usual story of trying to transfer a home setup to a corporate setup, and it's of course nice to have a neat project.clj without lots of :exclusions.
Why doesn't the artifact scanning tool look at the project.clj
file? The license is always listed there, and it's more reliable than trying to guess what the license filename is in the project repository.
It's probably a little optimistic to expect a maven package scanner to parse edn in project.clj
files, although, any licenses in here will be transferred to the maven pom.xml
through lein pom
(incidentally, the same does not apply for deps.edn
and clj -Spom
to my knowledge). Besides, github has built-in support and search for licenses, so it's perhaps best to follow their guidelines and include a plain old LICENSE file.
The license should also be in pom.xml
, though I see for 1.0.5 it hasn't been included, perhaps because it was generated with an older version of Leiningen.
As for including a plaintext LICENSE file, that's what I have been doing. A few older repositories that predate the Github guidelines had HTML licenses, but I believe Hiccup might have been the last one.
As for making the license scanner happy, can you add a dependency for Hiccup 2.0.0-alpha1? That should override 1.0.5 and provide the license you require.
Yes, the 2.0.0-alpha1 version passed the scanning, thanks again for seeing to this.
Hi James - I see you've done the above for many of your other projects, now I think I understand why - some artifact scanners can't handle the license.html and report that the library is missing a license. Do you think you could replace it? Thanks.