We run into this sort of thing quite a bit. Our solution so far has been:
1. Always use `:pedantic? :abort` in the project file. It can be annoying,
but we've found that's much better to get annoying errors about version
conflicts at build time than to get cryptic failures at runtime, such as
Hi,
Thanks for your responses. I will go and try the :provided profile and see
how it works out.
Thanks,
Sven
Am Samstag, 9. April 2016 02:51:15 UTC+2 schrieb Daniel Ziltener:
>
> Hi Sven,
>
> When you're sure the project depending your library does also has a
> dependency on a third library,
Hi Sven,
When you're sure the project depending your library does also has a
dependency on a third library, it's best to use the ":provided" profile,
rather than declaring it in the :dev profile. In your case there are two
possible solutions:
1. the dependency higher up wins. So if you declare
Include it as a dependency.
Maven dependency resolution is rather strange, and Leiningen inherits this
strangeness. Effectively what matters is how "close" the dependency is. So
dependencies in your project file take precedence over the dependencies of
your dependencies, and so forth.
Maven does
Hi,
I have a library A that I use in project B. Now, library A makes use of
plumatics schema, as well as project B. I wonder what the best practice is
here.
Include schema in library A's dependencies? Or only declare a
dev-dependency on schema in library A?
If I declare a dev-dependency I
On 10/17/13 9:38 AM, Andrei Serdeliuc wrote:
Hi,
I was wondering how people handle dependencies that aren't on clojars.
We have a couple of clojure libs which are hosted on an internal
github enterprise.
So far I've been using lein's checkouts feature, but this seems fairly
difficult when
Hi,
I was wondering how people handle dependencies that aren't on clojars. We
have a couple of clojure libs which are hosted on an internal github
enterprise.
So far I've been using lein's checkouts feature, but this seems fairly
difficult when trying to setup continuous integration. As far
We are using apache archiva. Access through https, custom certificate and
username/password, all work flawlessly in lein.
JW
On Thu, Oct 17, 2013 at 5:56 PM, Ben Mabey b...@benmabey.com wrote:
On 10/17/13 9:38 AM, Andrei Serdeliuc wrote:
Hi,
I was wondering how people handle dependencies
There are also Archiva[1] and Artifactory[2].
[1] http://archiva.apache.org/index.cgi
[2] http://www.jfrog.com/home/v_artifactory_opensource_overview
Shantanu
On Thursday, 17 October 2013 21:26:09 UTC+5:30, Ben Mabey wrote:
On 10/17/13 9:38 AM, Andrei Serdeliuc wrote:
Hi,
I was
I've used an old version of Archiva, and we currently use Nexus. Nexus was
the better experience.
On Thu, Oct 17, 2013 at 12:05 PM, Shantanu Kumar
kumar.shant...@gmail.comwrote:
There are also Archiva[1] and Artifactory[2].
[1] http://archiva.apache.org/index.cgi
[2]
I'll +1 Archiva. It's easy to setup and pretty simple to use. For a
long time I resisted the idea of running an internal Maven repo at
World Singles so we relied on lein-localrepo and other somewhat hacky
techniques (that Technomancy regularly ribbed me about :) and once we
reached three rogue
At work, we're using Jenkins for CI. It happens to have a maven server
plugin and a leiningen plugin. I did not participate in the original setup
of the Jenkins system, but I was the one who (stealthily at first)
installed both plugins, which is doable by just clicking around on the
Jenkins
We have been using archiva for a long time. Less sophisticated than nexus
but a lot simpler to set up, at least that was the state of things more than
2 years ago.
Luc P.
I've used an old version of Archiva, and we currently use Nexus. Nexus was
the better experience.
On Thu, Oct 17,
I believe some people use HttpUnit for this purpose. It's a very full-featured
HTTP client. YMMV.
On 23 Jan 2010, at 01:25, Richard Newman wrote:
And as for Apache HttpComponents, it sounds like they don't grok the
notion that breaking backwards compatibility should only occur with a
I use leiningen to download and publish libraries, but in terms of
setting up for development I use a bash script that adds whatever I
need for the project to the CLASSPATH and starts the nailgun server.
(swank for vimclojure) This seems to work pretty well, although it
would be nice if Leiningen
On Jan 22, 11:58 pm, Richard Newman holyg...@gmail.com wrote:
I foresee a future with a lot more time spent modifying other people's
project files.
This is the past, the present, and the forever-after of open-source
software development.
If you need lots of libraries, you need your own Maven
On 22 Jan 2010, at 07:23, Richard Newman wrote:
* For those who might ask and what kind of user are you?:
* I keep up to date with Clojure master. I don't use binary releases.
* I fix bugs and make changes in my local Clojure/contrib/third-
party library trees, and I want *all* of my builds
Hi,
On Jan 22, 6:40 am, Mark Derricutt m...@talios.com wrote:
We're not all jumping on Leiningen, some of us are sticking with
maven, using the maven-clojure-compiler plugin, and also the
experimental Maven Polyglot Clojure build support:
http://polyglot.sonatype.org/clojure.html
I got a similar issue, yesteday I tried to update from github to newest
version of clojure\clojure-contrib,
and clojure-contrib showed me Caused by: java.lang.NoSuchMethodError:
clojure.lang.RestFn.init(I)V,
I checked out lot's of branched in clojure-contrib, but ended up unpacking
manually
From my googling, the only way to solve this in the general case (IE
the java case) is through using OSGi. I have no idea what the state
of compatibility is between clojure and OSGi at this time. I'd be
curious to find out in fact. Here's the stackoverflow.com page I
found that describes the
* I keep up to date with Clojure master. I don't use binary releases.
* I fix bugs and make changes in my local Clojure/contrib/third-
party library trees, and I want *all* of my builds to use *those*, not
their own choice of versions. With lein/mvn I have to install a custom
On Jan 21, 7:21 pm, Richard Newman holyg...@gmail.com wrote:
Now, I like to keep track of Clojure master. Right now, Clojure
reports Clojure 1.2.0-master-SNAPSHOT.
(I don't see that in Maven Central or in Clojars, so I guess I have to
put it in my local repository...?)
Richard, this
On Jan 21, 8:21 pm, Richard Newman holyg...@gmail.com wrote:
Apparently everyone is jumping on the Leiningen bandwagon and deleting
their build.xml files. I guess that means I'm moving, too.
Deleting build.xml files is good. After that, you've got several
options, including Leiningen and
On Thu, Jan 21, 2010 at 10:23:10PM -0800, Richard Newman wrote:
I'm somewhat swayed by Leiningen because it makes doing some things
easy (uberjar! starting a REPL! neat!), at the cost of making other
things (such as managing dependencies myself) more frustrating.
However, if it wasn't for all
Is it possible in maven or leiningen to place a dependency not on a
specific version of a pre-built artifact, but rather on a specific scm
revision (or just head, aka SNAPSHOT for binary releases) of a
project's source repository, and having the machinery understand it
has to first locally build
Laurent PETIT laurent.pe...@gmail.com writes:
Is it possible in maven or leiningen to place a dependency not on a
specific version of a pre-built artifact, but rather on a specific scm
revision (or just head, aka SNAPSHOT for binary releases) of a
project's source repository, and having the
Richard, this doesn't address your larger points, but I wanted to make
sure you're aware of
http://build.clojure.org
which is a maven repo for clojure contrib artifacts. At /snapshots,
there are builds for Clojure 1.2 (1.2.0-master-SNAPSHOT). Leiningen is
aware of this repo by default, so you
Alternatively, is it possible to at least depend on a source
version
of the dependency, having it compiled on the fly locally when
compiling the main project ? (so that one could benefit from AOP, and
this could also solve the problem of a library mixing java and
clojure
source) ?
I've
, and if I don't want three versions of Commons libs (some want
Logging 1.1, some Logging 1.1.1, etc.), I have to modify those
projects again. Seems a lot like manual dependency management. :)
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post
Okay, we've all seen this thread:
http://groups.google.com/group/clojure/browse_thread/thread/182f171afc49473b
It just hit me that we're all going about this the wrong way. Our
libraries shouldn't specify specific versions. Each dependency should
be a Clojure predicate. Then, the lein deps
Doesn't Lein currently rely on Maven for dependency management?
- James
On Jan 22, 6:53 pm, Sean Devlin francoisdev...@gmail.com wrote:
Okay, we've all seen this thread:
http://groups.google.com/group/clojure/browse_thread/thread/182f171af...
It just hit me that we're all going about
Yeah, but this still *should* be doable. Not necessarily directly,
but doable.
On Jan 22, 2:38 pm, James Reeves weavejes...@googlemail.com wrote:
Doesn't Lein currently rely on Maven for dependency management?
- James
On Jan 22, 6:53 pm, Sean Devlin francoisdev...@gmail.com wrote:
Okay
of your library is [1.2-SNAPSHOT,) and the
other is [1.1] maven will complain, I would expect, before you run
into strange compile errors.
This is a hard problem, and any dependency management system which
requires you to pick a single version of a dependency, when multiple
versions exist
Now for the original question:
http://groups.google.com/group/clojure/browse_thread/thread/6cef4fcf523f936
The problem is AOT compiled code.
Not only. If my library refer to a function that's first defined in
library-X version 1.5, and some other code uses library-X 1.4 *and* my
library,
BTW: commit ids as version numbers break down here, because they are
not ordered.
They have a partial ordering wrt a particular repo. Many repos have
straight-line histories, and thus have a total ordering.
Neither maven nor ivy are so simple-minded to allow only one version.
How well
Just this week I noticed that Apache HttpComponents 4.0.1 and 4.1
use completely different methods to apply pre-emptive HTTP Basic
Auth, and have even changed class hierarchies. A version of clj-
apache-http targeted at 4.0.1 won't even run against a 4.1 jar (and
vice versa), *even without
be necessary for any dependency management system.
And as for Apache HttpComponents, it sounds like they don't grok the
notion that breaking backwards compatibility should only occur with a
major-version change.
--
You received this message because you are subscribed to the Google
Groups Clojure group
And as for Apache HttpComponents, it sounds like they don't grok the
notion that breaking backwards compatibility should only occur with a
major-version change.
Yeah, it's a pain to use their stuff -- I've never seen *so many
packages* in one library -- but it seems to be the only
Hi,
Am 22.01.2010 um 21:07 schrieb Richard Newman:
BTW: commit ids as version numbers break down here, because they are
not ordered.
They have a partial ordering wrt a particular repo. Many repos have
straight-line histories, and thus have a total ordering.
So how do I find out the
dependencies on upstream libraries; specifying that some library
should be built from source; using predicates to decide on
dependencies; etc.
From what you've written it appears that work has been done on
dependency management systems that make some of these tasks easier
(e.g., Gradle
Hi folks,
Apparently everyone is jumping on the Leiningen bandwagon and deleting
their build.xml files. I guess that means I'm moving, too.
Now, I like to keep track of Clojure master. Right now, Clojure
reports Clojure 1.2.0-master-SNAPSHOT.
(I don't see that in Maven Central or in
On Jan 21, 8:37 pm, Sean Devlin francoisdev...@gmail.com wrote:
Clojure stresses immutability, and dependencies should be no
different. I'd say it's bad form to force a dependency on an
unreleased version of Clojure, because it's a moving target. Granted,
BTW, Clojure also stresses
We're not all jumping on Leiningen, some of us are sticking with
maven, using the maven-clojure-compiler plugin, and also the
experimental Maven Polyglot Clojure build support:
http://polyglot.sonatype.org/clojure.html
(disclojure - both of these are my projects so I'm somewhat biased)
--
forward to
more plugins arriving to perhaps allow me to define per-project tasks
(for database operations, say).
I'm not at all swayed by Maven itself. XML *and* bloated opaque
dependency management! What's not to love?
(Yes, I know it does a lot of cool stuff -- http://blog.lick-me.org/2010
Richard Newman holyg...@gmail.com writes:
Adjusting the lein script to use my local Clojure install gave me a
great error:
Caused by: java.lang.NoSuchMethodError: clojure.lang.RestFn.init(I)V
How do people deal with this? How can one simultaneously use two
libraries which have hardwired
the right version.
This is a hard problem, and any dependency management system which
requires you to pick a single version of a dependency, when multiple
versions exist (and your code might work on more than one) is going to
hit it. I don't think everybody has to upgrade at once is a good
On Wed, Jul 8, 2009 at 11:28 AM, Phil Hagelbergp...@hagelb.org wrote:
I've been noodling on the problem of dependency management for a while
now. It's definitely a pain point for projects with more than a couple
dependencies. Currently our approach has been to use maven, but that
involves
that in action.
For my own needs, I care primarily about dependency management, which as
far as I can tell is the one thing that Maven does well. (I had never
used Maven before working with Clojure, so I make no claims towards
knowing what I'm talking about wrt Java build systems.) The actual
compilation
I've been noodling on the problem of dependency management for a while
now. It's definitely a pain point for projects with more than a couple
dependencies. Currently our approach has been to use maven, but that
involves a fair amount of arcane knowledge as well as writing a bunch of
XML, which
:'jide-oss', version:'[2.2.0,)')
http://groovy.codehaus.org/Grape
On Wed, Jul 8, 2009 at 12:28 AM, Phil Hagelbergp...@hagelb.org wrote:
I've been noodling on the problem of dependency management for a while
now. It's definitely a pain point for projects with more than a couple
dependencies
Phil, it might be worthwhile to look at Ivy (http://ant.apache.org/
ivy). It has real good interop with ant and can easily pull from a
maven repo and read pom files.
On Jul 7, 9:28 pm, Phil Hagelberg p...@hagelb.org wrote:
I've been noodling on the problem of dependency management for a while
I have written up my journeys so far:
http://bradfordcross.blogspot.com/2009/04/clojure-build-and-dependency-management.html
I re-used Meikel's ant + ivy successfully. Next step is to get something
working for the transative deps , i.e. pulling other clojure projects i
depend on and building
On Apr 13, 2009, at 4:58 PM, bradford cross wrote:
I have written up my journeys so far:
http://bradfordcross.blogspot.com/2009/04/clojure-build-and-dependency-management.html
Thanks very much for the write-up!
Given the recent discussions and interest in dependency management I
thought
!
Given the recent discussions and interest in dependency management I
thought I'd mention an idea in that area that I think is a good one.
At ILC '09, Francois-Rene Rideau made a presentation about xcvb:
http://common-lisp.net/project/xcvb/
which is intended to be a successor to Common Lisp's
-and-dependency-management.html
Thanks very much for the write-up!
Given the recent discussions and interest in dependency management I
thought I'd mention an idea in that area that I think is a good one.
At ILC '09, Francois-Rene Rideau made a presentation about xcvb:
http://common-lisp.net/project
journeys so far:
http://bradfordcross.blogspot.com/2009/04/clojure-build-and-dependency-management.html
Thanks very much for the write-up!
Given the recent discussions and interest in dependency management I
thought I'd mention an idea in that area that I think is a good one.
At ILC '09
On Apr 13, 10:58 am, bradford cross bradford.n.cr...@gmail.com
wrote:
I have written up my journeys so
far:http://bradfordcross.blogspot.com/2009/04/clojure-build-and-dependenc...
Nice article.
I re-used Meikel's ant + ivy successfully. Next step is to get something
working for the
Hi Bradford,
Am 08.04.2009 um 21:31 schrieb Bradford Cross:
I heard some chatter yesterday on #clojure about using Ivy with
Clojure.
Yes. I'm working on marrying Clojure and Ivy. So far with, IMHO,
great success. I set up a little ivy repo with clojure and contrib.
The clojure module has
:
When you are building something real with Clojure and Emacs/Slime/Swank
-
things can get a bit hairy with dependency management.
I have scoured the inter-tubes in the past couple days to see what I
could
find.
I found Lancet, for builds:
http://github.com/stuarthalloway/lancet
is HARD. I've never seen a system
that does it perfectly -- Rubygems, CPAN, Maven, you name it.
-Stuart S
On Apr 8, 3:31 pm, Bradford Cross bradford.n.cr...@gmail.com wrote:
When you are building something real with Clojure and Emacs/Slime/Swank -
things can get a bit hairy with dependency
bradford.n.cr...@gmail.com wrote:
When you are building something real with Clojure and Emacs/Slime/Swank
-
things can get a bit hairy with dependency management.
I have scoured the inter-tubes in the past couple days to see what I
could
find.
I found Lancet, for builds:
http
When you are building something real with Clojure and Emacs/Slime/Swank -
things can get a bit hairy with dependency management.
I have scoured the inter-tubes in the past couple days to see what I could
find.
I found Lancet, for builds:
http://github.com/stuarthalloway/lancet/tree/master
I
and Emacs/Slime/
Swank - things can get a bit hairy with dependency management.
I have scoured the inter-tubes in the past couple days to see what I
could find.
I found Lancet, for builds:
http://github.com/stuarthalloway/lancet/tree/master
I haven't tried it yet.
I found some people
also quite willing to help with such an effort, but I don't feel
qualified to lead it myself as I haven't had any exposure to other
dependency-management tools on the JVM, though I have hacked a lot on
RubyGems. But the needs for Clojure are quite different.
-Phil
64 matches
Mail list logo
