I have project A and B:
ls ..
a b
in project A, I have both:
a/dev/deps.edn
a/deps.edn
in the project b I'm trying to use:
:deps {my-project/a {:local/root "../a/dev"}
I am declaring paths inside a/dev/deps.edn:
:paths ["../src"
"../resources"
"../dev"
"../test/integration"
"../test/unit"
"../test/resources"]
I'm getting
WARNING: Deprecated use of path /codebuild/output/.../test/resources external to project /codebuild/output/.../dev
In my project B, I have:
:deps {my-project/a {:local/root "../a/dev"}
The idea is that my project B tries to import things on the project A that has all of the namespaces... "it works in my machine" but in the pipeline machine not, why?please keep all additional details in a thread. This way it will be easier to get all details in one place
I did all the chat in the same message
sorry for early polution
There is a problem with project A: relative source paths had been deprecated some time ago. Could you check the versions of clojure cli installed localy and on CI?
chmod +x install-scripts/clojure-install-script/linux-install-1.11.2.1446.sh
ci
my machine: Clojure CLI version 1.12.0.1530
then I should bump in my CI?
worth a try. 1.11.2.1446 is almost exactly one year apart from the version on you machine.
But I wonder how it works locally. Can you see a warning like this: WARNING: Use of :paths external to the project has been deprecated, please remove: ../foo when you run cli locally?
yup
same warning
when it "doesn't work" on the pipeline machine, what happens
just the warning?
the project B does not load a namespace in a/src
"does not load" means what?
SLF4J(I): Connected with provider of type [org.slf4j.nop.NOPServiceProvider]
Loading namespaces: (core)
Test namespaces: (:automation)
Execution error at a.handler/eval24296$loading (handler.clj:1).
namespace 'a.logger' not found
Full report at:
/tmp/clojure-11801420562536830089.ednthere were some changes a while back to fix relative path resolution, would take me some digging to remember what those were or what version things changed. I think my first suggestion would be to update the CI version to latest
ok
the warning is just a warning - relative paths "above" the project still work (for now)
the preferred way to handle this is by referring to a dep, either :local relative or :git with the root
allowing access to relative paths above the project root has potential security issues and it will be disallowed in the future
you have been WARNed :)
yup
do you think then it's good for me to release the artifact of the dev app and refer to it?
build it adding the paths I want in a jar for A and refer it on B?
if you logically have two projects, then I think it probably makes sense to make two artifacts/projects
b project is for "blackbox testing" the project a
I have a http://a.dev/test-env-fn that project b needs to execute
a will have 2 jar in thesis
prod jar and test jar
then
?
yeah, I think this would be better as a separate project right now
there are some outstanding ticket ideas that would help more - one is being able to specify a dep + an alias (where you could add a :test alias for example). another is some way to reference a relative lib in the same git repo - kind of a mix of relative local and git. both of those are good ideas, but need some work
ok. Then I'll build the jar with dev paths and copy to .m2 folder in the CI machine
and refer to it or something
thx