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 req
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
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 webpage
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" li
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
wrote:
> There are also Archiva[1] and Artifactory[2].
>
> [1] http://archiva.apache.org/index.cgi
> [2] http://www.jfrog.com/home/v_artifactory_open
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 wa
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 wrote:
> On 10/17/13 9:38 AM, Andrei Serdeliuc wrote:
>
>> Hi,
>>
>> I was wondering how people handle dependencies that aren'
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 as
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 t
On Jan 22, 11:58 pm, Richard Newman 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 repository with
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
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
>> m
of the appropriate way
to codify workarounds for this kind of thing: imposing corrected
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 bee
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
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 feature-rich
ify that the version it
specifies should override that default behavior. I assume similar
functionality would 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 onl
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 A
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 range
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, t
wable versions, and the build software chooses
> the right version".
When the specification 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
Yeah, but this still *should* be doable. Not necessarily directly,
but doable.
On Jan 22, 2:38 pm, James Reeves wrote:
> Doesn't Lein currently rely on Maven for dependency management?
>
> - James
>
> On Jan 22, 6:53 pm, Sean Devlin wrote:
>
> > Okay, we'
Doesn't Lein currently rely on Maven for dependency management?
- James
On Jan 22, 6:53 pm, Sean Devlin 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
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 cou
ame
> local Clojure version, otherwise some of them will still be building
> with some older release.
>
> Oh, 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 lo
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 th
ojects again. Seems a lot like manual dependency management. :)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient wi
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
Laurent PETIT 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 machinery understand
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 th
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
On Jan 21, 8:21 pm, Richard Newman 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 clojure-maven-plugin
On Jan 21, 7:21 pm, Richard Newman 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 doesn't address
> * 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
> ve
>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 si
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.(I)V",
I checked out lot's of branched in clojure-contrib, but ended up unpacking
manually downloade
Hi,
On Jan 22, 6:40 am, Mark Derricutt 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
>
> (disclojure - bo
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
lowable versions, and the build software chooses
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 do
Richard Newman writes:
> Adjusting the lein script to use my local Clojure install gave me a
> great error:
>
> Caused by: java.lang.NoSuchMethodError: clojure.lang.RestFn.(I)V
>
> How do people deal with this? How can one simultaneously use two
> libraries which have hardwired dependencies on tw
e me.*
That's OK, and I'm sure it'll change over time. I'm looking 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
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)
--
Pu
On Jan 21, 8:37 pm, Sean Devlin 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 *controlled mutability*. I'd
> What's the community protocol around locally installing Clojure 1.2,
> and adding that as a dependency for a published library?
I'll take a shot at this question.
Clojure stresses immutability, and dependencies should be no
different. I'd say it's bad form to force a dependency on an
unrelea
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 Clo
eeds, I'd love to see 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 Jav
On Wed, Jul 8, 2009 at 11:28 AM, Phil Hagelberg 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
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 wrote:
> I've been noodling on the problem of dependency management for a while
>
b(group:'org.jidesoft', module:'jide-oss', version:'[2.2.0,)')
http://groovy.codehaus.org/Grape
On Wed, Jul 8, 2009 at 12:28 AM, Phil Hagelberg wrote:
>
>
> I've been noodling on the problem of dependency management for a while
> now. It's definite
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
On Apr 13, 10:58 am, bradford cross
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 transative deps , i.e. pulli
>
>>>> 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 dependen
/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
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://commo
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
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 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 the
aven, you name it.
>
> Yea, I don't imagine will solve things beautifully at first, but we should
> be able to at least streamline things a bit.
>
>
>
> > -Stuart S
>
> > On Apr 8, 3:31 pm, Bradford Cross wrote:
> > > When you are building s
e things beautifully at first, but we should
be able to at least streamline things a bit.
>
>
> -Stuart S
>
>
> On Apr 8, 3:31 pm, Bradford Cross wrote:
> > When you are building something real with Clojure and Emacs/Slime/Swank
> -
> > things can get a b
my build.xml:
http://tinyurl.com/c5vkfm
Multi-version dependency tracking 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 wrote:
> When you are building something real with Clojure and Emacs/Sli
#x27;m 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 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
>
>
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
66 matches
Mail list logo
