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
n
>> dependencies. Thus if you choose clojure-contrib-freechart, you get
>> that JAR (or compiled Clojure sources) plus the jfreechart dependency.
>>
>> In this way you are using the good part of Maven: transitive
>> dependency management.
>>
>> On Tue, Apr 1
gement.
>
> On Tue, Apr 14, 2009 at 5:19 AM, Rich Hickey wrote:
> >
> > I've been thinking recently about contribs with dependencies.
> >
> > I think it's very important to have layers - e.g. core depends only on
> > JDK 1.5, contrib only on core. La
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
ese be in separate projects?
>
> > Regards,
>
> > Mark.
> > --http://mark.reid.name/
>
> > On Apr 14, 10:19 pm, Rich Hickey wrote:
>
> > > I've been thinking recently about contribs with dependencies.
>
> > > I think it's
ese be in separate projects?
>
> > Regards,
>
> > Mark.
> > --http://mark.reid.name/
>
> > On Apr 14, 10:19 pm, Rich Hickey wrote:
>
> > > I've been thinking recently about contribs with dependencies.
>
> > > I think it's
> >
> > I've been thinking recently about contribs with dependencies.
> >
> > I think it's very important to have layers - e.g. core depends only on
> > JDK 1.5, contrib only on core. Lately there have been some ideas
> > centering around Joda Time, [Par
rescript at the top of the
> trunk? Shouldn't these be in separate projects?
>
> Regards,
>
> Mark.
> --http://mark.reid.name/
>
> On Apr 14, 10:19 pm, Rich Hickey wrote:
>
> > I've been thinking recently about contribs with dependencies.
>
> > I th
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
k.
--
http://mark.reid.name/
On Apr 14, 10:19 pm, Rich Hickey wrote:
> I've been thinking recently about contribs with dependencies.
>
> I think it's very important to have layers - e.g. core depends only on
> JDK 1.5, contrib only on core. Lately there have been some ideas
> centeri
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 23:02 schrieb Howard Lewis Ship:
I'd say to refactor clojure-contrib into a number of seperate modules;
individual modules (each with its own pom) could have their own
dependencies. Thus if you choose clojure-contrib-freechart, you get
that JAR (or compiled Clojure sources)
u are using the good part of Maven: transitive
dependency management.
On Tue, Apr 14, 2009 at 5:19 AM, Rich Hickey wrote:
>
> I've been thinking recently about contribs with dependencies.
>
> I think it's very important to have layers - e.g. core depends only on
> JDK 1.5
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
hing to do with the downloaded jar, either
directly or indirectly ...
2009/4/14 Stuart Sierra
>
> 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 s
tise, but again a lot of posts about parallel
> computation.
>
>
> On Tue, Apr 14, 2009 at 8:19 AM, Rich Hickey wrote:
>
>>
>> I've been thinking recently about contribs with dependencies.
>>
>> I think it's very important to have layers - e.g. cor
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
graphics related projects (and have done)
that built in support for matrix math would be really great.
fork/join - not my expertise, but again a lot of posts about parallel
computation.
On Tue, Apr 14, 2009 at 8:19 AM, Rich Hickey wrote:
>
> I've been thinking recently about co
I've been thinking recently about contribs with dependencies.
I think it's very important to have layers - e.g. core depends only on
JDK 1.5, contrib only on core. Lately there have been some ideas
centering around Joda Time, [Parallel]Colt, AWS, JFreeChart, Fork/Join
etc.
I'd
29 matches
Mail list logo
