[ccw-users] CCW and Clojure1.3

How are you starting the REPL?

I mostly have Clojure 1.3.0 projects and find that if I right-click
the project in the Navigator and select Run As... Clojure Application
it starts up a 1.3.0 REPL just fine.

HTH,
Sean

On Mon, Oct 3, 2011 at 4:48 PM, Luc Prefontaine
wrote:

Hello Luc,

2011/10/4 Luc Prefontaine <lprefontaine@softaddicts.ca>:


Well, maybe ...

I mean : I just re-did a little test with 0.3.0.STABLE002. I created a
new project, removed clojure & clojure contrib jars from the java
build path that were installed by default in 1.2 versions. Added
clojure-1.3.0.jar as an external dep. Started a REPL from the
contextual menu of the project's node : Clojure 1.3 is launched ...

Ok, I 'll try to sort it out today... with a lot of caffeine :)

On Tue, 4 Oct 2011 06:38:57 +0200
Laurent PETIT wrote:

HI all,

Just checking ... I've installed Eclipse Indigo and CCW 4.0. I
followed the directions here:

http://dev.clojure.org/display/doc/Getting+Started+with+Eclipse+and+Counterclockwise

The project is running clojure 1.2.

If I copy clojure 1-3.jar into the Project directory, rename it to
clojure.jar, then it loads Clojure 1.3.0.

My question is, where is CCW getting it's clojure.jar file and how to
I set it to use the newest version of Clojure?

Thanks for any assistance,

Adam

Hello,

Currently, CCW does not offer, when using "New Project" feature, to
choose which clojure.jar to use.
Currently, it ships with a 1.2 version of Clojure. In the next weeks,
it will be changed to use a 1.3 version.

So what you did is one way to change the jar. Another it to go to the
project's contextual menu, and manage from them which clojure version
is on the classpath via the "java build path" menu of Eclipse.

HTH,

-- Laurent

Hello,

i would like to ask for publishing two releases of counterclockwise,
one linked to clojure 1.2 + contrib, and another one linked to clojure
1.3.0. Something like 0.4.x-stable-cloj1.2 and 0.4.x-stable-cloj1.3.
Obviously installing both on the same eclipse instance will be
impossible.

The reasons behind this request are:

1/ while it is not difficult to change the linked jar (clojure 1.2
versus 1.3), it has to be done on a project basis, and for my own i
very often forget to do this initially and then run to strange
compilation errors. Ok, this is pure laziness ;-)

2/ i think that programming under clojure 1.2 is not a dead art,
provided this is only an opinion.

3/ this is a personal taste, but i prefer managing two eclipse working
spaces, one dedicated to clojure 1.2 and the other one to clojure
1.3.

If this request doesn't generate too much work for you, and if it
makes sense for other peoples, i think this could be a reasonable
solution while waiting for next improvement when choosing clojure
release will be available at project creation time.

IMO, I think a far more productive use of time will be to ensure reasonable support for Leiningen, either from ccw itself or as a separate (automatically-installed) plugin so that ccw isn't adding anything to projects at all that isn't dictated by one's project.clj or pom.xml.

- Chas

Indeed, and this topic is revisited regularly :)
What has been preventing work to start on it is the fact that some
things were considered more urgent, and also that the problem domain
was still "moving" when in [S2 2010 -S1 2011] (cake/cljr/lein/jark
world domination war ); and now in [S2 2011 - S1 2012], a far better
(wrt dependency management, IMHO) 2.0 version of leiningen is
envisioned, and I have the temptation to procrastinate, giving lein
2.0 the time to start & mature, or not (if not, then it'll be time to
work on CCW's -or CCW related feature- own's project.clj analyzer).

I don't know if you want to move this to the -dev list, or if we've touched on it before over IRC, but I don't think we need to be tied to a particular version of lein at all, at least to start, when dependency info is all we need. Its representation will remain steady into lein 2.0, and we can get the information we need from project.clj without having leiningen itself around at all.

FWIW, once I tie up the new nREPL enhancements (and corresponding UI bits in ccw), lein support in ccw (and working on lein itself) will be my next biggest priority.

- Chas

Not yet, I wasn't writing this to start a brainstorming. Indeed, I
should have mentioned that your recent work on a sonatype's Aether
Clojure Wrapper is one of the most recent ideas for doing project.clj
support without lein.
If you're there before me (and you may well be there before, since I
first want to work a little more on the editor, and also on OSGi
integration so that it is possible to better work on CCW itself -or
eclipse plugins in general- without having to restart a repl -when
interop is in play and classloader visibility enter the dance-), we'll
have to consider if it is interesting to do this : just in the
ccw.core plugin by facility, in a separate plugin but still provided
with the ccw_feature, or with a separate feature. My current bet is on
separate plugin/same feature, but deal is open :-)

My workflow is:
* use lein new proj-name to create a project in the shell
* optionally adjust dependencies in project.clj
* run lein deps
* create new java project in eclipse in the proj-name folder
* enable clojure support

At this point, CCW is using whatever version of Clojure the project is using.

If I want to change versions, I edit project.clj and - in a shell -
run lein deps again, then update the build path in Eclipse. That's the
same workflow for any dependency changes.

It would be nice to be able to run lein deps and update the build path
automatically inside CCW (and I think Chas / Laurent are considering
that) but a Leiningen-based workflow completely removes the issue of
which version of Clojure is used by CCW (IMO).

answering to Chas and Sean,

including maven or leiningen capacities is not a problem (as clojure
is running on java, i think that maven is the obvious first target,
especially in the perspective of integration into existing java
projects), as long as counterclockwise will not render them mandatory
even at installation time, aka the current 'native clojure' will stay
available.

What do you mean by "native clojure"? i.e. a Clojure project that does not use lein or maven to define dependencies?

If so, you'll always be able to get that, regardless of what ccw does w.r.t. maven or lein support. A Clojure project is really just a java project + the enabling of "clojure language support" + a Clojure jar on the classpath.

- Chas

Hello,

'native clojure' is very simply what counterclockwise currently
handles: plain and simple clojure. This mean managing source files and
sending them to repl without requiring intermediate tools.

I think the next logical step for counterclockwise is generating a
clojure class (currently only deliver the source as built element),
implying some way to set -Dclojure.compile.path and calling
clojure.lang.Compile (which leads to an interesting question about
compilation choice, because clojure source file as built element is
interesting if you manage some repl directly from java and then need
the clojure source as script file).

And as soon as a clojure compiler will be available with
counterclockwise, compatibility with soviet bureaucracy style tools as
maven or leiningen or so on, will be relevant, for soviet bureaucracy
style organization only this is sure (*), but regarding this later
point i have to say that they are numerous ;-)

(*) I'm precisely using functional programming to be able to manage
significant programs (mean: they really do something) within a range
of 1000 to 6000 lines of code, and i really don't see the point to
loose time with one of those so-called code manager. Clearly this
doesn't mean nor imply that others can't have other views on the
topic, but this clearly mean that rendering maven or leiningen or so
on mandatory to initiate a clojure project is a show stopper for me,
period.

Integration with existing java projects being an obviously different
topic, and there maven compatibility is required. And your idea for a
wrapper over counterclockwise is probably the right answer.

I can't imagine working on a significant project without a project
structure and something to manage my dependencies. For me, Leiningen is a
huge time SAVER and I don't think I'd want to work on Clojure without it.
Maven is a different matter, I agree.

If you really want simple and to get infrastructure out of your way, I'm
kinda surprised you're using Eclipse in the first place :)

I've really enjoyed using Eclipse + CCW + Leiningen for my Clojure work
over the last year or so. I think it's a solid tool chain that just keeps
getting better. For reasons completely unrelated to CCW itself, I've
recently switched to Emacs on all machines - with Leiningen to manage my
projects - but I shall continue to support and advocate CCW! :)

Sean

Really, targeting maven in CCW is not an objective : Eclipse already
has maven support with m2eclipse (now officially included under the
Eclipse Foundation umbrella at http://www.eclipse.org/m2eclipse/ ).
So every work made here would certainly be a side project to extend
m2eclipse with e.g. clojure-maven support.

In the mean time, the "poor man's solution" working out-of-the-box
with Eclipse, CCW & Maven is to just put all your Clojure source files
in e.g. src/main/resources folder.

Hello,

2011/11/5 warfall <warfall007@gmail.com>:
I think I understand your reasoning, but I don't want to start
following this road, even if it's a small one.

I intend to release CCW with Clojure 1.3 in the not so far away future.
My guess is also that there will be far more *newly created projects*
starting with 1.3, while previous projects may stay for a longer time
with 1.2. So when CCW ships with 1.3, and as such suggests an 1.3
version of Clojure jars as a default for newly created projects, I
don't see this as being a big deal. (I don't exect a lot of new
projects starting wih 1.2 these days, and for those wanting to stay
with 1.2 rather than keeping the current 1.3, I expect them to know
what they're doing, and as such how to do it).

As Chas said in reply to you, the problem is the problem of carefully
choosing how to spend one's time. Building CCW is not a career for me,
so I'd better choose wisely ;-).

But please, don't stop the flow of suggestions in this ml, this "no"
to the request at hand does not imply my answers here will always be
no ;)

ok,

no problem here, as i said pure laziness was part of the request ;-)