Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uberjar applies dev/user profiles #537

Closed
ath opened this issue Apr 24, 2012 · 8 comments
Closed

Uberjar applies dev/user profiles #537

ath opened this issue Apr 24, 2012 · 8 comments
Labels
Milestone

Comments

@ath
Copy link

ath commented Apr 24, 2012

Via Leiningen 2 I would like to have several useful libs as global dev dependencies, for example Criterium for benchmarking, or Pomegranate, so that I can add interesting libs during runtime. I was not successful so far. I show how to reproduce what I did:

Make a directory temp and paste this project.clj there:

(defproject test "0.1.0"
  :dependencies [[org.clojure/clojure "1.4.0"]])

Backup your profiles.clj and replace it with this one:

{:user {:plugins [[lein-pprint "1.1.1"] [lein-swank "1.4.4"]]}
 :dev {:dependencies [[criterium "0.2.1-SNAPSHOT"]]}}

Now lein pprint shows me that Criterium is a dependency, and I have it available in lein swank. Building an Überjar however won’t work, and I get the message that

Release versions may not depend upon snapshots.
Freeze snapshots to dated versions or set the LEIN_SNAPSHOTS_IN_RELEASE environment variable to override.

So it seems Leiningen wants to add Criterium as a regular dependency, and not just for dev time. This is my first finding.
The second one is this: change the project.clj file to:

(defproject test "0.1.0"
  :dependencies [[org.clojure/clojure "1.4.0"]]
  :profiles {:dev {:dependencies [[[com.cemerick/pomegranate "0.0.11"]]]}})

Now a lein pprint confirms that Criterium just got killed. It seems my :dev profile from my profiles.clj got overwritten by the direct entry in the project.clj file.
Was my intuition right, that global dev dependencies should go into profiles.clj under the :dev profile?
If yes it seems that there are two bugs:

  1. the :dev deps from a profiles.clj are treated as regular project dependencies (as long no :dev profile is mentioned in the project.clj file)
  2. if a :dev profile is specified in the project.clj then the settings from profiles.clj are not used anymore.
@technomancy
Copy link
Owner

The fact that the :dev profile is applied at uberjar time is definitely a bug, but the fact that profiles in project.clj override profiles in profiles.clj is by design. That's why the :user profile exists, so you can add dependencies across the board without conflicting with the :dev profile found in project.clj.

@ath
Copy link
Author

ath commented Apr 24, 2012

Okay, in fact I placed my libs at first in the {:user {:dependencies […]}}, but this resulted in including them into my Überjars, and not just into dev time. Then I talked to several people, who suggested to try it with profiles.clj==>:dev.
Maybe we should be more specific in the readme:

You can place any arbitrary defproject entries into a given profile and they will be
merged into the project map when that profile is active. In addition to project.clj,
profiles specified in ~/.lein/profiles.clj will be available in all projects.

==>

You can place any arbitrary defproject entries into a given profile and they will be
merged into the project map when that profile is active. In addition to project.clj,
profiles specified in ~/.lein/profiles.clj will be available in all projects.
Be aware however that profiles specified in ~/.lein/profiles.clj will be overridden by
profiles specified in a project.clj file. For example, if you specify :dependencies in
the :dev profile in your ~/.lein/profiles.clj and also specify :dependencies in your
project.clj file, then only the one from the latter will be used.

And

The difference between the profiles active by default is that the :default profile
comes with Leiningen, while the :dev profile is meant to be specified in project.clj
and the :user plugin goes in your ~/.lein/profiles.clj file.

could get the addition

What you specify in the :user profile in your ~/.lein/profiles.clj file is treated as
if it were specified in your project.clj under the :dev profile. If you want to access
dependencies during development time for any project place them in your :user profile.

Something like that maybe, might help. Just a suggestion of course.

@technomancy
Copy link
Owner

Thanks; incorporated some of these suggestions into the readme.

@xeqi xeqi reopened this Apr 25, 2012
@xeqi
Copy link
Collaborator

xeqi commented Apr 25, 2012

Re-opening as a reminder to verify that the test dependencies still make it in the uberjar'ed pom.

Another way to solve this is by moving the pom task's project manipulation to include the snapshot check. See https://github.com/technomancy/leiningen/blob/master/src/leiningen/pom.clj#L312

@xeqi
Copy link
Collaborator

xeqi commented Apr 28, 2012

Looks like d85f2fb causes a broken pom into the jar. The pom task tries to manipulate the profiles itself, and since it's passed a project that no longer contains a :without-profiles meta it loses a bunch of data.

Also I'm pretty sure that the pom task needs to get the project with profiles added. If there is a project with

:profiles {:1.3 {:dependencies [[org.clojure/clojure "1.3.0"]]
                 :classifier "clj1.3"}}

then lein with-profiles 1.3 jar needs the pom task to know about the classifier and dependencies.

@xeqi
Copy link
Collaborator

xeqi commented Apr 28, 2012

A better example where the classifier is useful might be a project with legacy 1.2/contrib support in a separate jar with a clj1.2 classifier.

@xeqi
Copy link
Collaborator

xeqi commented May 5, 2012

I was confused on classifiers. They can't be used to specify different dependency versions.

@technomancy
Copy link
Owner

I believe the pom issue is fixed in 3826e78, but it's still the case that we should be removing the default profiles rather than using :without-profiles. This needs #512 before it can be implemented though, so I'd rather spin it off into another issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants