Ewps. My bad. I was thinking of mirrors, not a general proxy. However, the
profiles route would probably help as well.
http://maven.apache.org/settings.html#Profiles
Basically, by moving configuration settings inside a profile, it's like
having two settings.xml files that can be turned on/o
On 29.03.2010, at 08:24, Mark Derricutt wrote:
> Why do you need to edit the settings twice a day? Strikes me as a problem.
> You could move the relevant settings into a which is only
> activated based on network/env settings, so those changes are automatic?
What I found about proxy configu
On 28/03/2010, at 8:01 PM, B Smith-Mannschott wrote:
> On Sun, Mar 28, 2010 at 08:39, Antony Blakey wrote:
>>
>> On 28/03/2010, at 4:42 PM, Antony Blakey wrote:
>>
>>> (defproject main "org.clojars.the-kenny:clojure-couchdb:0.2"
>>> :add-default-plugins true
>>> :description "Simple Clojure
On Mon, Mar 29, 2010 at 08:24, Mark Derricutt wrote:
> Why do you need to edit the settings twice a day? Strikes me as a problem.
> You could move the relevant settings into a which is
> only activated based on network/env settings, so those changes are
> automatic?
> --
> Pull me down under..
Why do you need to edit the settings twice a day? Strikes me as a problem.
You could move the relevant settings into a which is
only activated based on network/env settings, so those changes are
automatic?
--
Pull me down under...
On Fri, Mar 26, 2010 at 8:36 PM, Konrad Hinsen
wrote:
> 2) B
My current proposal for the Clojure DSL for polyglot maven looks like this:
--
(defproject com.linkuistics.lamdras/website "1.0-SNAPSHOT"
:model-version "4.0.0"
:name "Lamdras Website"
:description "Acumen / LRMDS Integr
On 28/03/2010, at 8:01 PM, B Smith-Mannschott wrote:
> - Clojure code manipulating poloyglot's notation is more complex
> because it must be parsed first, and then recombined. Leiningen's
> notation already is 'parsed'.
Partly parsed. The most 'correct' form would be [groupdId artifactId version
On Sun, Mar 28, 2010 at 08:39, Antony Blakey wrote:
>
> On 28/03/2010, at 4:42 PM, Antony Blakey wrote:
>
>> (defproject main "org.clojars.the-kenny:clojure-couchdb:0.2"
>> :add-default-plugins true
>> :description "Simple Clojure interface to Apache CouchDB, fork of the
>> original project wit
On 28/03/2010, at 4:42 PM, Antony Blakey wrote:
> (defproject main "org.clojars.the-kenny:clojure-couchdb:0.2"
> :add-default-plugins true
> :description "Simple Clojure interface to Apache CouchDB, fork of the
> original project with function arguments instead of *server* and some other
> ch
[I've cross posted because I think this is relevent to both lists]
I've started fixing some bugs in the Clojure support in polyglot maven. I've
sent pull requests upstream, but until then you can get it from
http://github.com/AntonyBlakey/polyglot-maven. It works as my default maven
(although t
Or you can help out with Polyglot Maven for which there is preliminary
Clojure support:
http://github.com/sonatype/polyglot-maven/blob/master/pmaven-clojure/src/test/resources/org/sonatype/maven/polyglot/clojure/test1.clj
I've tried to put the infrastructure in place in Maven to use dynamic
langu
I'm now using polyglot maven for a project in both NetBeans/Enclojure and
Intellij/LaClojure. The pom.clj for one of my subprojects looks like this:
--
(defproject main "com.linkuistics.lamdras:website:1.0-SNAPSHOT"
On Fri, Mar 26, 2010 at 10:31 AM, Saul Hazledine wrote:
> The article reads to me as, "don't reinvent the wheel, everyone should
> use maven." Personally I disagree with this because maven
> configuration is much harder than it needs to be.
I think there's a misconception that's been spread that
On Mar 25, 3:42 pm, Chas Emerick wrote:
> I'm not entirely sure what would be required from clojure-maven-plugin
> (for example) for maven to achieve greater acceptance in the
> community...
I think all it takes is getting the word out. Ease of use matters to
me, but sexp vs. XML or simple i
On Mar 25, 7:55 pm, Chas Emerick wrote:
> I published a blog post earlier today, along with a short screencast
> that might be of interest:
>
> Read on:http://muckandbrass.com/web/x/AgBV
>
The article reads to me as, "don't reinvent the wheel, everyone should
use maven." Personally I disagree wi
I'm not familiar with labrepl (except by name), but I think this is
*exactly* right, as long as people do realize that maven is the "next
natural step" from lein as soon as they have build requirements beyond
running repls and maybe wrapping up a jar. Insofar as any higher-
level tool provi
On 25 March 2010 22:17, Brian Carper wrote:
> On Mar 25, 11:55 am, Chas Emerick wrote:
>
> Why does building and installing dependencies have to be harder than
> this? Lein right now tries to fill this niche of being braindead easy
> to use, and comes pretty close. I realize Maven does a lot mo
On Mar 26, 2010, at 10:18 AM, David Nolen wrote:
Now, it *would* be nice, when it's really called for, to be able to
create a maven plugin using clojure. The API is just a pile of
interfaces, so it's fundamentally the same as implementing any other
Java API. As for having to package it -
On Fri, Mar 26, 2010 at 7:33 AM, Chas Emerick wrote:
> Now, it *would* be nice, when it's really called for, to be able to create
> a maven plugin using clojure. The API is just a pile of interfaces, so it's
> fundamentally the same as implementing any other Java API. As for having to
> package
On Mar 26, 2010, at 4:33 AM, Jarkko Oranen wrote:
No, compilation should not be included. You mention make; it is a
macro language, dependency graph walker, shell executor and
up-to-dateness checker. It doesn't do any compilation. It's very bare
bones. It's not at all perfect but it's much close
On Mar 26, 2010, at 5:35 AM, David Powell wrote:
I often want to add a custom task to a build, just as an example, I
might want to call a Java method in my code after it has built which
will generate a property file to be included in the distribution.
If this was just a make file or some sort
Hi,
On Mar 25, 11:17 pm, Brian Carper wrote:
> Ruby: gem install X
> Perl: perl -MCPAN -e shell, then "install X"
>
> Why does building and installing dependencies have to be harder than
> this?
I think you got this backwards. With maven, ant (ie. Ivy), gradle and
leiningen this similar easy to
2010/3/26 David Powell :
>
> I often want to add a custom task to a build, just as an example, I
> might want to call a Java method in my code after it has built which
> will generate a property file to be included in the distribution.
>
> If this was just a make file or some sort batch file, then
I often want to add a custom task to a build, just as an example, I
might want to call a Java method in my code after it has built which
will generate a property file to be included in the distribution.
If this was just a make file or some sort batch file, then that would
just be an extra line in
Hello
Brian Carper at "Thu, 25 Mar 2010 15:17:10 -0700 (PDT)" wrote:
BC> On Mar 25, 11:55 am, Chas Emerick wrote:
>> I published a blog post earlier today, along with a short screencast
>> that might be of interest:
>>
>> "Like any group of super-smart programmers using a relatively new
On Mar 26, 8:53 am, Per Vognsen wrote:
> It's not semantic nitpicking. There's a clear-cut difference a piece
> of reusable code with a function that can be called to generate a
> bundled Windows installer based on a set of arguments versus something
> that only works as part of a build system
Fully agree, reinventing the wheel is not a good time investment.
Ant has been there for years, why not reuse it ? Why reinvent Ant (or
Maven) in Clojure ?
The fact that they may look ugly and cumbersome to use has to be
separated from
the benefits they provide.
We switched to Leiningen here and
On Fri, Mar 26, 2010 at 1:06 PM, Konrad Hinsen
wrote:
> On 26 Mar 2010, at 05:50, Chas Emerick wrote:
>
>> Because they're common processes that are ideally built once, and then
>> reused with minor variation. Library reuse is generally considered to be a
>> good thing in software development, so
On 26 Mar 2010, at 05:50, Chas Emerick wrote:
Because they're common processes that are ideally built once, and
then reused with minor variation. Library reuse is generally
considered to be a good thing in software development, so it strikes
me as odd that many think that such practices sh
Is there a tool which takes a simple config file as input in some
human readable format (like below) and generate mavel pom xml?
name: foobar
version: x.y.z
dependencies: clojure (>= 1.1.0), clojure-contrib (= 1.1.0)
...
...
Ramakrishnan
--
You received this message because you are subscribed
On Fri, Mar 26, 2010 at 12:59 PM, Chas Emerick wrote:
>
> On Mar 26, 2010, at 12:59 AM, Per Vognsen wrote:
>
>> On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick
>> wrote:
>>>
>>> Because they're common processes that are ideally built once, and then
>>> reused with minor variation. Library reuse i
On 26/03/2010, at 4:37 PM, Rayne wrote:
> I don't think I've ever seen a language in which part of the community
> shunned build tools written in the language itself. It's quite
> hilarious.
People aren't shunning anything because it's written in Clojure. I think that
reinventing all that Maven
On 26/03/2010, at 4:37 PM, Rayne wrote:
> I don't think I've ever seen a language in which part of the community
> shunned build tools written in the language itself. It's quite
> hilarious.
I've seen many examples where an overwhelming Not-Invented-Here attitude lead
to failure.
Antony Blakey
I'll have to agree with Brain here. As of now, all I need is
Leiningen. It does what I want. Lein is a new project, and I'm fairly
certain that it will be much more useful in the future.
I don't think I've ever seen a language in which part of the community
shunned build tools written in the langu
On Mar 26, 2010, at 12:59 AM, Per Vognsen wrote:
On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick
wrote:
Because they're common processes that are ideally built once, and
then
reused with minor variation. Library reuse is generally considered
to be a
good thing in software development, so
On Fri, Mar 26, 2010 at 11:50 AM, Chas Emerick wrote:
> Because they're common processes that are ideally built once, and then
> reused with minor variation. Library reuse is generally considered to be a
> good thing in software development, so it strikes me as odd that many think
> that such pra
Because they're common processes that are ideally built once, and then
reused with minor variation. Library reuse is generally considered to
be a good thing in software development, so it strikes me as odd that
many think that such practices should stop at the build's edge, as it
were.
T
One of the weirdest things coming to the Java world is to witness what
strange things people take for granted should be in the build tool.
All the example features you mention in your article are convenient,
but I don't see why they belong in the build tool. They should be
completely separate piece
For whats it worth here - IntelliJ IDEA will automatically add maven
dependencies to you pom.xml file for unknown classes ( in java source, not
the clojure plugin - yet), for example if you type "com.cemerick.Foo" in
your source, and its an unknown class, the intention dialog gives you
options of "
I am in complete agreement! Clojure continues to hinder itself by not
providing an official executable. java -cp clojure.jar was good enough
for Clojure 0.9, but that's not where it is anymore.
Even simple things like submitting bug reports would be helped by
having a default "clj" executable. It
On Thu, Mar 25, 2010 at 6:17 PM, Brian Carper wrote:
>
> Ruby: gem install X
> Perl: perl -MCPAN -e shell, then "install X"
If you're just installing CPAN module X, then on most installations
all you need to run is this:
cpan X
You can still go into the interactive shell if you want, usually
Brian,
FWIW, I'd claim that maven does deliver on all five points you list.
Of note is that it absolutely is IDE-agnostic (I used NetBeans in the
screencast because that's what I use -- you can load up maven-defined
projects in Eclipse and IntelliJ just as easily). I'm not an emacs
user
On Mar 25, 2010, at 19:55 , Chas Emerick wrote:
> I published a blog post earlier today, along with a short screencast that
> might be of interest:
>
> "Like any group of super-smart programmers using a relatively new language, a
> lot of folks in the Clojure community have looked at existing
On Mar 25, 2010, at 6:08 PM, Rob Wolfe wrote:
No, XML is not the worst thing (at least for me).
The real problem is here:
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
I'm not sure what you're referring to there. :-)
Let's suppose that from time to time I'd
On Mar 25, 11:55 am, Chas Emerick wrote:
> I published a blog post earlier today, along with a short screencast
> that might be of interest:
>
> "Like any group of super-smart programmers using a relatively new
> language, a lot of folks in the Clojure community have looked at
> existing bui
Chas Emerick writes:
> I published a blog post earlier today, along with a short screencast
> that might be of interest:
>
> "Like any group of super-smart programmers using a relatively new
> language, a lot of folks in the Clojure community have looked at
> existing build tools (the JVM space i
46 matches
Mail list logo
