[ANN] New release 0.28.1 of Counterclockwise

9 views
Skip to first unread message

Laurent PETIT

unread,
Sep 28, 2014, 3:50:58 PM9/28/14
to clojuredev-users, counterclockwise, clo...@googlegroups.com, cloju...@googlegroups.com
Counterclockwise, the Eclipse Clojure development tool.

Counterclockwise 0.28.1 has been released.

Improvement over 0.28.0 based on user feedback. Thanks to all who helped improve Counterclockwise by their constructive comments!

- Drag & Drop from Github / Bitbucket / Google Code URLs works in Linux
- Better User feedback for Drag & Drop folder actions
- Added a check for missing `.classpath` file for Leiningen projects. Automatically reconstruct the java build path if it is missing.


ChangeLog
=========


Installation instructions
==================


Cheers,

--
Laurent Petit

Laurent PETIT

unread,
Oct 4, 2014, 2:10:05 AM10/4/14
to clojured...@googlegroups.com, clojured...@googlegroups.com, clo...@googlegroups.com, cloju...@googlegroups.com
Points taken. 
After rethinking about this, thanks to your feedback, it seems indeed really wrong to silently automatically override existing Java build paths. 

I think I will confine the automatic leiningen conversion only for projects which do not yet appear to be Java/just projects - those without a .classpath file yet. 

What do you think?

Le samedi 4 octobre 2014, Howard Green <hhg...@ieee.org> a écrit :

So, I did the upgrade from 0.27.0 to 0.28.1 several hours ago... and immediately made the startling discovery that every project in my workspace with a project.clj file had been auto-converted to a Leiningen project!

Under ideal circumstances, this would not have bothered me, as I like the Lein support a lot; but a number of my long-running projects had substantial discrepancies between the Eclipse build information and what was in project.clj. Fortunately, my backup is pretty good... :-)

I assume the problem arose here because the (innocuous) "Automatic detection of Clojure project" option turned into the (dangerous) "Automatic detection of Clojure / Leiningen projects"… and I did indeed have the former option checked.  It might be nice to forcibly un-check the option as part of an upgrade, as a way of preventing unforeseen consequences.

Anyway, no real harm done. However, I think I'd suggest that during conversion process it would be a good idea to retain the old .classpath file, so there's an easy way to fully reverse the effects of a conversion, or maybe abort the conversion if the Eclipse and Lein content didn't agree.

--- Howard

--
You received this message because you are subscribed to the Google Groups "counterclockwise-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojuredev-use...@googlegroups.com.
To post to this group, send email to clojured...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojuredev-users.
For more options, visit https://groups.google.com/d/optout.


--
Laurent Petit

Laurent PETIT

unread,
Oct 4, 2014, 10:24:42 AM10/4/14
to clojured...@googlegroups.com, clojured...@googlegroups.com, clo...@googlegroups.com, cloju...@googlegroups.com
Hello lee,

The drag and drop of projects with a project.clj file should not be affected :

- if the project already has eclipse metadata (that's what .project and .classpath files are), then ccw will rely on them and not try to overwrite them. 
- if the project has no eclipse metadata (or no metadata declaring a classpath), then adding Lein support can only improve the situation, so it would be done automatically. 

So for projects imported from github wih no eclipse specific files, it will continue to do the magic. 

Le samedi 4 octobre 2014, Lee Spector <lspe...@hampshire.edu> a écrit :

What would this mean in practice for using the new drag/drop functionality to open Clojure projects, regardless of origin or history? Would some require an additional manual step to behave as proper Leiningen projects?

This new functionality has been making life *much* better for me and for my students in the short time that it has existed, and it'd be a shame to lose some of the new functionality.

I don't even know if/when there is a .classpath or .project or any of other hidden files in the projects I've been opening and sharing, and I'd love to never have to worry about that again. Being able to drag anything with a project.clj to CCW and having it open and run correctly is just wonderful, and I think it greatly improves the usability of CCW, especially for newcomers to the ecosystem.

Maybe if some of that would no longer work automatically after the change that you are contemplating then the system could be made to ask whether to do the full conversion (what it does now in 0.28.1) or not in a dialog, rather than just doing or not doing it automatically and requiring a manual step later in some cases?

 -Lee


On Oct 4, 2014, at 2:10 AM, Laurent PETIT <lauren...@gmail.com> wrote:

> Points taken.
> After rethinking about this, thanks to your feedback, it seems indeed really wrong to silently automatically override existing Java build paths.
>
> I think I will confine the automatic leiningen conversion only for projects which do not yet appear to be Java/just projects - those without a .classpath file yet.
>
> What do you think?
>
> Le samedi 4 octobre 2014, Howard Green <hhg...@ieee.org> a écrit :
> So, I did the upgrade from 0.27.0 to 0.28.1 several hours ago... and immediately made the startling discovery that every project in my workspace with a project.clj file had been auto-converted to a Leiningen project!
>
> Under ideal circumstances, this would not have bothered me, as I like the Lein support a lot; but a number of my long-running projects had substantial discrepancies between the Eclipse build information and what was in project.clj. Fortunately, my backup is pretty good... :-)
>
> I assume the problem arose here because the (innocuous) "Automatic detection of Clojure project" option turned into the (dangerous) "Automatic detection of Clojure / Leiningen projects"... and I did indeed have the former option checked.  It might be nice to forcibly un-check the option as part of an upgrade, as a way of preventing unforeseen consequences.


--
Laurent Petit

Reply all
Reply to author
Forward
0 new messages