tonsky/uberdeps

extra-paths ignored

Closed this issue · 7 comments

maxp commented

Directories mentioned in alias :extra-paths are ignored.

   :paths ["src"]

    :uberdeps
    {
      :extra-paths ["resources"]
      :extra-deps {uberdeps {:mvn/version "0.1.4"}}
      :main-opts ["-m" "uberdeps.uberjar --target tmp/main.jar --level debug"]}

but that configuration works well

   :paths ["src" "resources]

    :uberdeps
    {
      :extra-deps {uberdeps {:mvn/version "0.1.4"}}
      :main-opts ["-m" "uberdeps.uberjar --target tmp/main.jar --level debug"]}

Thanks! I’ll look into it

maxp commented

Also would be great to have an option to specify Main-class: in META-INF/MAINFEST.MF

@tonsky should you default to something like (System/getProperty “java.class.path”) when the :aliases option is not specified?

It seems that tools.deps will create the correct path from the aliases specified with -O/-A, but the current implementation will ignore that and depend solely on what the :aliases option provides.

Not sure if :aliases option is necessary for programmatic api but at least from the shell the clojure alias flags are a more intuitive api.

@maxp It looks like you need to specify the --aliases option (e.g. --aliases uberdeps)

My previous comment is incorrect as it is not possible to remove uberdeps itself from the output, which is undesirable.

Let me try to add some clarity:

Uberdeps build is two-step process:

  1. You need to run uberdeps itself. For that you need a classpath that includes uberdeps, anything else on classpath is not important. You can have a standalone deps.edn that only have uberdeps included somewhere else and that’s enough to package any other project that has deps.edn

  2. Uberdeps process from step 1 will open deps.edn that you point it to and will try to figure out your project’s dependencies from it. Note that this step has nothing to do with how first step was run. No runtime info like current java classpath is used at this step. It simply opens deps.edn and packages every file that’s listed in it (in a form of dependency or a path)

Ideally, you’d want two separate deps.edn: one for running uberdeps and one for your project:

uberdeps.edn

{:deps {uberdeps {:mvn/version "0.1.7"}}
 :main-opts ["-m" "uberdeps.uberjar"]}

deps.edn

{:deps {clojure {:mvn/version "1.10.1"}
        ...}
 :paths ["src" "resources]}

I haven’t found a nice way to do this, so instead what you can do is merge the two, limiting uberdeps interference by putting it into its own alias. This has a downside: when running uberdeps, it will have all of your project’s dependencies on classpath. But this should do no harm. What’s important is that when your project is run and/or packaged, it will not have uberdeps classes or dependencies included.

Taking this all into account, if you want something packaged along with your project, it should be in your project’s deps or in a separate alias. Aliases are not included by default (:uberdeps alias has no special meaning, for example), so for it to appear in a final archive you must tell uberdeps to include it with --aliases argument:

:paths ["src"]

:aliases {
  :package {:extra-paths ["resources"]}
  :uberdeps {
    :extra-deps {uberdeps {:mvn/version "0.1.4"}}
    :main-opts ["-m" "uberdeps.uberjar" "--target" "tmp/main.jar" "--level" "debug" "--aliases" "package"]}
}

Note "--aliases" "package" in :main-opts

maxp commented

Yes! It works well with --aliases.
Your explanation really should be in README file.

Agreed — wrote an extensive README with project configuration examples