Including both the library jar and the sources jar on the classpath results in an exception

[vemv]

Hi,

this library also provides a "sources" artifact. When said artifact is also in the classpath along with the main library, the following will fail:

aws-api/src/cognitect/aws/http.clj

Line 76 in 1de65bd

(throw (ex-info "Found too many http-client cfgs. Pick one." {:config cfgs})))))

I think this error doesn't make sense in face of the "sources" artifact. Why would you provide such an artifact when it can't coexist with the main one? Tooling (or users, by hand) can always be inclined to put both under the classpath, which is useful for the CIDER family of tools.

There's probably a few possible solutions:

• don't publish a "sources" artifact for projects not bundling .java source files at all
  • that is, for subsequent versions of course
• exclude .clj and .edn files from "sources" - the main artifact already will bundle such files; one could say that their main purpose is bundling .java files (which are very frequently distributed as bytecode).
• remove the check, and trust that consumers are able to perform classpath management competently
  • e.g. I always place "sources" after the main artifacts. The classpath is order-sensitive so there's no ambiguity whatsoever.

WDYT?

Thanks - V

[puredanger]

As we've talked about elsewhere, I'm unconvinced that putting the sources jar on the classpath is a sensible thing to do in the first place.

In other sources jars that we publish on Maven central, we do a variety of things (empty jar, only java source, java and clojure source, etc - there is no real "standard" here). Maven central has rules that you must include the sources jar and might have rules about non-empty source jars (can't remember), and I think you can ask for these rule to be turned off for non-Java projects, but I can't remember all the details now.

Seems like you would run into this same kind of problem with data_readers.clj too?

[vemv]

As we've talked about elsewhere, I'm unconvinced that putting the sources jar on the classpath is a sensible thing to do in the first place.

Recap'ing that conversation, over the last 8 months I've worked with this approach over a variety of large real-world projects. This is the only ever experienced instance of a problem. Said instance being an intentional failure. My approach is sensible/unobstrusive because it places source artifacts at the tail of the classpath.

Maven central has rules that you must include the sources jar

TIL, thanks for sharing this nuance.

Seems like you would run into this same kind of problem with data_readers.clj too?

With data_readers it's kind of the opposite situation: Clojure intentionally encourages us to have multiple identically-named resources in the classpath, and accordingly throws no exception whatsoever.

[jumarko]

I've just run into the same problem.
It would be great if there was at least a way to configure it to not fail.

[jumarko]

@vemv is there a way to exclude a specific artifact in the enrich-classpath's configuration?

[vemv]

It would be great if there was at least a way to configure it to not fail.

I think the same. In the aws-api source there's this TODO:

;; TODO consider providing config arguments to http constructor

That could be a "neutral" fix; one can observe that reading config from the classpath is a little too implicit. It is quite common to build config programatically, for dev/test matters.

@vemv is there a way to exclude a specific artifact in the enrich-classpath's configuration?

DMing you over Slack