search

webnf / dwn

A clojure build tool, based on nix
17 stars 2 forks source link

Unable to find com.googlecode/jsendnsca-core #3

Open charles-dyfis-net opened 5 years ago

charles-dyfis-net commented 5 years ago

Given the following project.clj:

(defproject dwnTest "0.0.1-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.8.0"] [cljr-nsca "0.0.3"]])

Running dwn gen-repo ./project.nix emits the error:

ERROR no download info [com.googlecode jsendnsca-core jar  1.3.1] nil

This still happens when requiring jsendnsca-core directly, and explicitly including the repository in which it's hosted:

(defproject dwnTest "0.0.1-SNAPSHOT"
  :repositories [["redhat" "https://maven.repository.redhat.com/ga/"]]
  :dependencies [[org.clojure/clojure "1.8.0"] [com.googlecode/jsendnsca-core "1.3.1"]])

See the POM at https://maven.repository.redhat.com/ga/com/googlecode/jsendnsca-core/1.3.1/jsendnsca-core-1.3.1.pom, and the entry at https://mvnrepository.com/artifact/com.googlecode/jsendnsca-core/1.3.1

charles-dyfis-net commented 5 years ago

I tried moving to a new upstream Aether (now "Apache Maven Resolver", since the ASF took over maintainership but hasn't been granted the trademark). No change in behavior, but might be useful if we need to communicate with the library's authors; will be submitting another PR.

charles-dyfis-net commented 5 years ago

It appears likely that this is an issue reading :repositories from project.clj, not an issue with the actual Aether code, as this can be resolved perfectly well in a REPL when manually configuring the redhat repository:

(require 'webnf.dwn.deps.aether)
(in-ns 'webnf.dwn.deps.aether)
(repo-for [["com.googlecode" "jsendnsca-core" "1.3.1"]]
          (aether-config :include-optionals false
                         :include-scopes #{"compile"}
                         :repositories (assoc default-repositories
                                        "redhat" "https://maven.repository.redhat.com/ga/")))

...does not generate the warning unless the "redhat" entry is removed.

Ed: And not even a bug, but just an unimplemented feature; apparently I saw the logic in question in a competing project and confused it with this one.

bendlas commented 5 years ago

yep, reading repositories from leiningen is TBD

additionally, the set of base repositories should probably be matched to leiningen's. I'll see what i can do ...

charles-dyfis-net commented 5 years ago

I'm halfway through an attempt to do that myself (updated lein.reader to extract the content, haven't yet plumbed that data through) -- should I drop it to avoid duplicating effort?

bendlas commented 5 years ago

No worries, I was just about to document a quick workaround. Haven't even touched lein.reader yet ..

charles-dyfis-net commented 5 years ago

(It is interesting that leiningen and Maven don't require the "redhat" repo to be configured before they're able to download jsendnsca-core as a dependency of cljr-nsca -- I'm guessing the POM for [cljr-nsca "0.0.3"] specifies a repository URL to search for its dependencies but haven't yet validated as much).

bendlas commented 5 years ago

OK, I see, how I missed that wenn porting pomegranate.aether, since dwn doesn't use maven's resolve-everything call, but implements its own most-recent-discoverable-wins resolution algorithm, geared towards determinism.

So, in deps.aether, we'd need to augment the passed in repositories with the per-dependency repositories [1], pass them down the tree, and record all discovered repositories in the final repo.edn, for deps.expander to use.

[1] http://maven.apache.org/resolver/maven-resolver-api/apidocs/org/eclipse/aether/resolution/ArtifactDescriptorResult.html#getRepositories()