sounds like we need at least three things:
1) clojure-sandbox
2) clojure-extensions (for the CLR and javascript and jfreechart)
3) core-candidates for things that seem like they might grow up to be
in the core. This would have the intent rzezeski and I were talking about.
things here say to
Hi,
Am 16.04.2009 um 21:48 schrieb dysinger:
Why is there so much NIH churn around this dependency management
issue?
We should leverage maven repos & just wrap maven or ivy with clojure -
they both have a java api. Maven repos, like them or not, already
solved dep management in Java. Why figh
I agree with matt.
Why is there so much NIH churn around this dependency management
issue?
We should leverage maven repos & just wrap maven or ivy with clojure -
they both have a java api. Maven repos, like them or not, already
solved dep management in Java. Why fight it?
PS - buildr sucks and
On Thu, Apr 16, 2009 at 2:16 AM, Konrad Hinsen wrote:
[...]
>
> I think it would be useful to formalize this concept of a "standard
> library" that is a single entity from the point of view of users who
> just want to download a jar file and get going. A standard library
> would also define certa
On 15.04.2009, at 23:44, rzeze...@gmail.com wrote:
> That aside, I agree Contrib is a sandbox, but how big of a sandbox is
> it? That's the question I pose. I think it's irrational to put every
> Clojure library/framework that comes along into Contrib, because it
> becomes a Tower of Babel and
On Apr 15, 5:07 pm, Stuart Sierra wrote:
> On Apr 15, 2:10 pm, "rzeze...@gmail.com" wrote:
>
> > P.S. I don't want to get off-track, but I also don't understand why
> > ClojureCLR or clojurescript are included in Contrib. I also don't
> > understand why test files are not under their own top
On Apr 15, 2:10 pm, "rzeze...@gmail.com" wrote:
> P.S. I don't want to get off-track, but I also don't understand why
> ClojureCLR or clojurescript are included in Contrib. I also don't
> understand why test files are not under their own top level dir? I
> think that is a good convention and a
My .02 cents...
I always viewed Contrib as an incubator of sorts for Core. That it
was simply a testing ground for functionality that *MIGHT* make it
into Core if enough people find it useful, or Rich hands down his good
graces.
Requiring a few external libs here and there, and breaking Contrib
My .02 cents...
I always viewed Contrib as an incubator of sorts for Core. That it
was simply a testing ground for functionality that *MIGHT* make it
into Core if enough people find it useful, or Rich hands down his good
graces.
Requiring a few external libs here and there, and breaking Contrib
+1 I said the same thing on IRC
On Apr 14, 11:27 am, Mark Reid wrote:
> Hi,
>
> I'm not sure if this is relevant to this discussion but, as a
> newcomer, I was puzzled by the organisation of the clojure-contrib
> source.
>
> Why, for example, are ClojureCLR and clojurescript at the top of the
>
On 14 tra, 23:48, Meikel Brandmeyer wrote:
> I already use MacroDef. As far as I see, none of those allows me to
> define
> new targets, right? Only tasks?
>
Yes, they can only define new tasks, you can call targets from them
(using antcall) and of course call them from your tasks. If you u
Hi,
Am 14.04.2009 um 23:24 schrieb Krešimir Šojat:
I'd really love to see defmacro in ant...
There is macrodef http://ant.apache.org/manual/CoreTasks/macrodef.html
in Ant, also, there is a Script task you can use to include JavaScript
(and many other) in your Ant builds. You may also check ou
Hi,
I'm not sure if this is relevant to this discussion but, as a
newcomer, I was puzzled by the organisation of the clojure-contrib
source.
Why, for example, are ClojureCLR and clojurescript at the top of the
trunk? Shouldn't these be in separate projects?
Regards,
Mark.
--
http://mark.reid.n
Hi,
On 14 tra, 23:15, Meikel Brandmeyer wrote:
> I'd
> really love to see defmacro in ant...
There is macrodef http://ant.apache.org/manual/CoreTasks/macrodef.html
in Ant, also, there is a Script task you can use to include JavaScript
(and many other) in your Ant builds. You may also check out
Hi,
Am 14.04.2009 um 17:17 schrieb Laurent PETIT:
It will be very difficult to speak about it without the discussion
switching to a dependency management tool war OR to keep things
simple, add the dependencies (if their license allow it *OUCH*) in
some libs/ directory in clojure-contr
Are there strong feelings against moving away from a centralized
contrib repository in favor of a directory (probably on clojure.org)
of independent projects? Seems to me that this simplifies the matter
of getting just the libraries you need without having to worry about
unrelated dependencies, an
2009/4/14 Konrad Hinsen
>
> On Apr 14, 2009, at 17:17, Laurent PETIT wrote:
>
> > The problem will then be that the next time I checkout clojure-
> > contrib, BLAM I can't compile it because I need to download a jar
> > from somewhere on the web ...
>
> That could be avoided by including the Cloj
I like Stuart's idea, but I can see those dependency declarations
becoming repetitive in any significantly large project. I think there
would need to be someway to declare dependencies on a larger scope,
perhaps application wide, or some mechanism to describe dependencies
for sets of namespaces.
On Apr 14, 2009, at 17:17, Laurent PETIT wrote:
> The problem will then be that the next time I checkout clojure-
> contrib, BLAM I can't compile it because I need to download a jar
> from somewhere on the web ...
That could be avoided by including the Clojure source in clojure-
contrib, but
The problem will then be that the next time I checkout clojure-contrib, BLAM
I can't compile it because I need to download a jar from somewhere on the
web ...
But in the other end, this seems inevitable for the parts that will really
*need* those libs.
Maybe it's time to make clojure-contrib more
On Apr 14, 8:19 am, Rich Hickey wrote:
> I've been thinking recently about contribs with dependencies.
...
> I'd like to start a discussion about how best to support the
> contributions of libraries that depend on things not in the JDK.
I'm ok with contribs depending on non-JDK libs, as long as
21 matches
Mail list logo
