Yikes ^

Thanks

besides that it seems that yada/yada.clj is the only clj file in the jar, a file which seemingly does not exist in the repo?

One sec

Ah, yada.clj is in one of the bundles

Hi @martinklepsch - sorry was just in a conf call earlier. Yada is broken up into a number of smaller extensions, composed into bundles. The rationale was that the number of yada transitive dependencies is over 150 and that's just too many for some use-cases. The extension approach allows extensions that aren't necessarily core to HTTP (e.g. a future implementation of WebDAV), would not add to the overall bloat. It's not entirely obvious when something is an optional extra and when something is core. E.g. Parameters - these are useful for the swagger generation and validation, and have been in yada since day one, but there's nothing in HTTP itself that requires them.

The aleph extension you are seeing is version 1.2.8, it depends on the actual version of aleph. The point of making aleph an extension is to provide support for other web servers in the future.

Yada is a big project, and in the future could be even bigger. There are other projects such as Incanter that suffer from the same dependency bloat (which increases the chances of version incompatibilities when integrated with end-user projects). Last year when I refactored yada into this design there was an obvious candidate for how to structure a large library. I hope they'll be more work in the dependencies area in the future which may suggest better approaches.

I see, so those jars aren’t actually aleph etc but yada/aleph and similar?

yes

Got it

you can compose your own bundle of yada if you want to change it, it's a power-user feature but others have done this

makes sense

By design, yada is not very modular (like Ring middleware), you can't really have HTTP compliance with a pick-and-mix style of bringing in an adhoc choice of clojure libraries - it has to be batteries-included (but there is a compartment at the back which allows you to change the batteries)

If I were to create an API documentation for yada, what jar would be the “default” one is the one that has just yada/yada.clj the right one?

yep - that's the default one which has everything

i'd love to see the API documentation - I'm sure it would reveal some inconsistencies to work on

Got it. And so all other sources in src/ are packaged up in dependencies of yada itself?

Well it’s really just Codox but it poses an interesting problem which is that some common APIs may not be visible because they are not part of the jar but a dependency (which would have it’s own API docs)

With Bidi’s verbose syntax is there a way to supply a regex pattern? https://github.com/juxt/bidi/blob/e50626890d592782f8309ac950e942baafe642f4/test/bidi/verbose_test.cljc

[["/" :group-id]
 [["/" :group/index]
  [["/" :artifact-id]
   [["/" :artifact/index]
    [["/" :version]
     [["/" :artifact/version]
      [["/" [#"[\w\.]+" :namespace] ""]
       [["/" :artifact/namespace]
        [["#" :def] [["" :artifact/def]]]]]]]]]]]