clj-processing applet export
Lee Spector
Thanks to help I got here I'm now happily playing with clj-processing in eclipse/ccw and I'd like to export an applet (which is the normal target for Processing projects).
In the Processing IDE there's a gloriously simple Export button that creates a folder with the JAR and an html file that loads it and even a "loading.gif" to display while it's loading. I don't suppose I'm going to be able to do that from Eclipse/ccw/clj-processing, since I assume that it's just a feature of the Processing IDE, but I'd like to export a JAR so that I can write my own html file to run the applet in a browser.
Poking around Eclipse I see a bunch of possibly related things with the most promising being File > Export > Java > JAR file, but when I try to do that I get a dialog that allows me to select all of the JARs and other top-level files in my clj-processing directory, but not the files in src or, as far as I can tell, compiled versions of anything in my src. So it looks like whatever this generates it can't know about my own code, which is in src. And even if it did include it, how would the right file be designated to start the applet?
I'm sure I'm missing something very basic here, which would be obvious to java developers. I am running my code within Eclipse by opening my file of Clojure code and doing "Load Clojure file in REPL". How do I generate a JAR file that will have the same effect (minus the REPL, or I guess with any REPL output going to the Java console)?
clj-procesing comes with a build.xml file that may (?) be for doing what I want using ant... I'm confused about that too, as I've only used ant in a few circumstances in the past and always just following instructions... but am I correct in my assumption that one does these things differently in Eclipse?
I realize I may well be confused about several different aspects of this question!
But I would appreciate any information/advice that anyone can provide.
Thanks,
-Lee
--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspe...@hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438
Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/
Chas Emerick
and IIRC, is implemented in such a way that you'll have essentially no
chance of reasonably reusing it.
You're now firmly in the realm of build tools -- a very contentious
topic among Clojure programmers (or, really, programmers of all
stripes). It's the ultimate bikeshed.
Either ant or maven will get you where you need to go, though I don't
think that there's anything in eclipse proper that will produce (a)
AOT-compile your clojure code and (b) add the results from (a) into a
jar file for you to pick up somewhere. AFAIK, it depends entirely on
you having a separate authoritative build process for producing
artifacts.
Anyway, I prefer maven these days for a host of reasons, which I wrote
about earlier this year (http://cemerick.com/2010/03/25/why-using-maven-for-clojure-builds-is-a-no-brainer/
). That post also includes a simple pom.xml file, which you can use;
assuming:
1. you have your code in the default locations (src/main/clojure for
clojure code, for example),
2. you have maven installed, and
3. you have put the sample pom.xml file in your project's root directory
You should be able to run `mvn package` and have your applet jar be
produced. Note that you'll have to add all of your dependencies to
the pom.xml first. By clj-processing, I presume you mean rosado's
package? Looks like there's an artifact on clojars here:
http://clojars.org/org.clojars.technomancy/rosado.processing
Cheers,
- Chas
> --
> You received this message because you are subscribed to the Google
> Groups "counterclockwise-users" group.
> To post to this group, send email to clojuredev-
> us...@googlegroups.com.
> To unsubscribe from this group, send email to clojuredev-use...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/clojuredev-users?hl=en
> .
>
Laurent PETIT
Yes, the Processing build process is entirely an artifact of the IDE, and IIRC, is implemented in such a way that you'll have essentially no chance of reasonably reusing it.
You're now firmly in the realm of build tools -- a very contentious topic among Clojure programmers (or, really, programmers of all stripes). It's the ultimate bikeshed.
Either ant or maven will get you where you need to go, though I don't think that there's anything in eclipse proper that will produce (a) AOT-compile your clojure code and (b) add the results from (a) into a jar file for you to pick up somewhere.
Not totally true, but true in the sense that, for your special case (a jar for an applet, with some dependencies which will be "provided" by the runtime), true enough.
Indeed, ccw does AOT-compile your clojure code when you start a Clojure VM from the project's node. It AOT-compiles everything, even what you would not have wished to AOT-compile (to be changed in the future).
And there's also a documented way to create "fat jars" within Eclipse, playing well with ccw. It's documented in ccw's documentation. The problem being that this "fat jar" solution is really the "heavy version" : it will unpack every dependency your project has, and repack it into a single jar ! Not what is needed in your case, where some dependencies (the processing library, the "applet" framework, etc.) may already be provided by the "running JVM".
AFAIK, it depends entirely on you having a separate authoritative build process for producing artifacts.
Anyway, I prefer maven these days for a host of reasons, which I wrote about earlier this year (http://cemerick.com/2010/03/25/why-using-maven-for-clojure-builds-is-a-no-brainer/). That post also includes a simple pom.xml file, which you can use; assuming:
1. you have your code in the default locations (src/main/clojure for clojure code, for example),
2. you have maven installed, and
3. you have put the sample pom.xml file in your project's root directory
You should be able to run `mvn package` and have your applet jar be produced. Note that you'll have to add all of your dependencies to the pom.xml first. By clj-processing, I presume you mean rosado's package? Looks like there's an artifact on clojars here:
http://clojars.org/org.clojars.technomancy/rosado.processing
Cheers,
- Chas
On Sep 18, 2010, at 5:58 PM, Lee Spector wrote:
Thanks to help I got here I'm now happily playing with clj-processing in eclipse/ccw and I'd like to export an applet (which is the normal target for Processing projects).
In the Processing IDE there's a gloriously simple Export button that creates a folder with the JAR and an html file that loads it and even a "loading.gif" to display while it's loading. I don't suppose I'm going to be able to do that from Eclipse/ccw/clj-processing, since I assume that it's just a feature of the Processing IDE, but I'd like to export a JAR so that I can write my own html file to run the applet in a browser.
Poking around Eclipse I see a bunch of possibly related things with the most promising being File > Export > Java > JAR file, but when I try to do that I get a dialog that allows me to select all of the JARs and other top-level files in my clj-processing directory, but not the files in src or, as far as I can tell, compiled versions of anything in my src. So it looks like whatever this generates it can't know about my own code, which is in src. And even if it did include it, how would the right file be designated to start the applet?
I'm sure I'm missing something very basic here, which would be obvious to java developers. I am running my code within Eclipse by opening my file of Clojure code and doing "Load Clojure file in REPL". How do I generate a JAR file that will have the same effect (minus the REPL, or I guess with any REPL output going to the Java console)?
clj-procesing comes with a build.xml file that may (?) be for doing what I want using ant... I'm confused about that too, as I've only used ant in a few circumstances in the past and always just following instructions... but am I correct in my assumption that one does these things differently in Eclipse?
I realize I may well be confused about several different aspects of this question!
But I would appreciate any information/advice that anyone can provide.
Thanks,
-Lee
--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspe...@hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438
Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/
--
You received this message because you are subscribed to the Google Groups "counterclockwise-users" group.
To post to this group, send email to clojured...@googlegroups.com.
To unsubscribe from this group, send email to clojuredev-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojuredev-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "counterclockwise-users" group.
To post to this group, send email to clojured...@googlegroups.com.
Lee Spector
1) Thanks so much Chas. Very helpful as always. I guess I have something new to learn, and you've given me a good starting point, but:
2) <rant, not targeted to you but to the whole unfair universe> Really, why do I or anyone have to learn this? Why *isn't* there just a button in Eclipse that does it? Surely it's a common enough need. Eclipse must already know all of the dependencies etc since it runs the thing just fine itself. Why wouldn't there be a button or, if there are options that must be specified, a wizard that packages up the same thing that Eclipse runs as code that can run elsewhere, e.g. as an applet (among other options)? Is this not done because it wouldn't work for giant projects with lots of special requirements that have to download libraries etc.? So people invent whole languages and systems for specifying this stuff, and require that everyone commit to one and read books on it and install and master additional software even if they just want to export a hello world applet? It seems sort of like if gcc came without a -o option, and if you had to learn an output-specification language, and download output-specification software, in order to produce an executable from your "hello world" C program. I know the example isn't entirely parallel, but the lack of a simple way to do this in what is "considered by many to be the best Java development tool available" seems really quite odd to me. </rant>
3) I have m2e maven support installed in my Eclipse (which got there when I followed instructions for getting labrepl). I'm guessing/hoping this will ease doing what I need from within Eclipse, but after using it to create a pom.xml for one of my projects I'm quite confused about what I'm looking at. There's a graphical view of the pom.xml but I don't know what information it wants, it won't let me select "jar" as the "packaging," and even if I got the pom right I don't see how to tell it to "do it" and actually produce the jar. Nothing in the Maven menu seems to be for doing this. Will "Build Project" do the right thing if/when I have the right pom? I tried it with "packaging" set to "war" (since it wouldn't let me select "rar") and it seemed to do *something*, but I don't see any resulting file. Anyone know of a tutorial or blog post that walks a newbie like me through using m2e? My web searches have only turned up descriptions of how to open existing Maven projects or to do much more exotic things, like using Maven to develop new Eclipse plugins (and vice versa? I'm pretty lost! :-). I guess I could give up on this and go to raw xml and the command line to create poms and run Maven to build my eclipse projects as applets or whatever, but shouldn't m2e make this easier?
Thanks,
-Lee
On Sep 20, 2010, at 1:45 PM, Chas Emerick wrote:
> Yes, the Processing build process is entirely an artifact of the IDE, and IIRC, is implemented in such a way that you'll have essentially no chance of reasonably reusing it.
>
> You're now firmly in the realm of build tools -- a very contentious topic among Clojure programmers (or, really, programmers of all stripes). It's the ultimate bikeshed.
>
> Either ant or maven will get you where you need to go, though I don't think that there's anything in eclipse proper that will produce (a) AOT-compile your clojure code and (b) add the results from (a) into a jar file for you to pick up somewhere. AFAIK, it depends entirely on you having a separate authoritative build process for producing artifacts.
>
> Anyway, I prefer maven these days for a host of reasons, which I wrote about earlier this year (http://cemerick.com/2010/03/25/why-using-maven-for-clojure-builds-is-a-no-brainer/). That post also includes a simple pom.xml file, which you can use; assuming:
>
> 1. you have your code in the default locations (src/main/clojure for clojure code, for example),
> 2. you have maven installed, and
> 3. you have put the sample pom.xml file in your project's root directory
>
> You should be able to run `mvn package` and have your applet jar be produced. Note that you'll have to add all of your dependencies to the pom.xml first. By clj-processing, I presume you mean rosado's package? Looks like there's an artifact on clojars here:
>
> http://clojars.org/org.clojars.technomancy/rosado.processing
>
> Cheers,
>
> - Chas
>
--
Lee Spector
On Sep 20, 2010, at 4:49 PM, Laurent PETIT wrote:
>
> And there's also a documented way to create "fat jars" within Eclipse, playing well with ccw. It's documented in ccw's documentation. The problem being that this "fat jar" solution is really the "heavy version" : it will unpack every dependency your project has, and repack it into a single jar ! Not what is needed in your case, where some dependencies (the processing library, the "applet" framework, etc.) may already be provided by the "running JVM".
I *think* that heavy is fine with me, and that this might be the solution to my problem and answer to my rant in the previous message!
I now see it in the ccw docs (I guess it didn't mean anything to me when I read them previously) and I will give it a try.
Thanks!!!
Lee Spector
On Sep 20, 2010, at 6:11 PM, Lee Spector wrote:
>
> 3) I have m2e maven support installed in my Eclipse (which got there when I followed instructions for getting labrepl). I'm guessing/hoping this will ease doing what I need from within Eclipse, but after using it to create a pom.xml for one of my projects I'm quite confused about what I'm looking at. There's a graphical view of the pom.xml but I don't know what information it wants, it won't let me select "jar" as the "packaging," and even if I got the pom right I don't see how to tell it to "do it" and actually produce the jar. Nothing in the Maven menu seems to be for doing this. Will "Build Project" do the right thing if/when I have the right pom? I tried it with "packaging" set to "war" (since it wouldn't let me select "rar") and it seemed to do *something*, but I don't see any resulting file. Anyone know of a tutorial or blog post that walks a newbie like me through using m2e? My web searches have only turned up descriptions of how to open existing Maven projects or to do much more exotic things, like using Maven to develop new Eclipse plugins (and vice versa? I'm pretty lost! :-). I guess I could give up on this and go to raw xml and the command line to create poms and run Maven to build my eclipse projects as applets or whatever, but shouldn't m2e make this easier?
Further bumbling on my part, but I'd appreciate any advice: The project that I tried to "Mavenize" (but didn't know what to put in the pom editor) now won't run -- when I try to load a file in the REPL it gives:
Exception in thread "main" java.lang.NoClassDefFoundError: clojure/main
Selecting "Maven > Disable dependency management" doesn't help. Deleting the pom.xml file doesn't help. Any way out of this?
Thanks,
-Lee
Chas Emerick
On Sep 20, 2010, at 10:08 PM, Lee Spector wrote:
> Further bumbling on my part, but I'd appreciate any advice: The
> project that I tried to "Mavenize" (but didn't know what to put in
> the pom editor) now won't run -- when I try to load a file in the
> REPL it gives:
>
> Exception in thread "main" java.lang.NoClassDefFoundError: clojure/
> main
>
> Selecting "Maven > Disable dependency management" doesn't help.
> Deleting the pom.xml file doesn't help. Any way out of this?
It sounds like you converted a standard java/clojure project to a
maven project, which implies that all of its configuration flows from
the pom.xml file.
Specifically, if you're seeing a NCDFE related to clojure, that means
that either your pom doesn't specify an appropriate clojure
dependency, or that it hasn't been pulled into your local maven
repository.
Deleting the pom file is a fairly nuclear option though. :-)
If the "fat" jar approach that Eclipse does offer suits you, then I'd
suggest backing away from maven/ant entirely, and get to where your
project configuration was. Otherwise, I'd focus on getting a pom file
that will build your project as you'd like; if you get to that point,
then the m2 plugin will ensure that the eclipse configuration is
mirrored, and Clojure REPL stuff should go off without a hitch.
- Chas
Chas Emerick
On Sep 20, 2010, at 6:11 PM, Lee Spector wrote:
> 2) <rant, not targeted to you but to the whole unfair universe>
> Really, why do I or anyone have to learn this? Why *isn't* there
> just a button in Eclipse that does it? Surely it's a common enough
> need. Eclipse must already know all of the dependencies etc since it
> runs the thing just fine itself. Why wouldn't there be a button or,
> if there are options that must be specified, a wizard that packages
> up the same thing that Eclipse runs as code that can run elsewhere,
> e.g. as an applet (among other options)? Is this not done because it
> wouldn't work for giant projects with lots of special requirements
> that have to download libraries etc.? So people invent whole
> languages and systems for specifying this stuff, and require that
> everyone commit to one and read books on it and install and master
> additional software even if they just want to export a hello world
> applet? It seems sort of like if gcc came without a -o option, and
> if you had to learn an output-specification language, and download
> output-specification software, in order to produce an executable
> from your "hello world" C program. I know the example isn't entirely
> parallel, but the lack of a simple way to do this in what is
> "considered by many to be the best Java development tool available"
> seems really quite odd to me. </rant>
Eclipse, and the JVM ecosystem more broadly, has always preferred a
modular approach to its architectures: tending towards reuse,
interoperability, and interchangeability of small (and sometimes, not
so small) components. That leads to a great deal of flexibility, but
a far higher degree of complexity than one sees in vertically-
integrated architectures: i.e. compare Eclipse/JVM with Visual
Studio/.NET, where the latter, because it is a vertically-integrated
system provided by a single vendor, offers a far simpler process for
common operations, including builds of all sorts, user interface
design, etc. etc. The downside of the vertically-integration option
being that, once you step outside of the well-marked path provided by
your vendor, you're in for a far longer road than if you could just
pluck a different component off the shelf to replace the default from
the factory.
Put another way, there isn't just a button in Eclipse for what you
want because then there'd have to be a button for each of the other
build processes.
> 3) I have m2e maven support installed in my Eclipse (which got there
> when I followed instructions for getting labrepl). I'm guessing/
> hoping this will ease doing what I need from within Eclipse, but
> after using it to create a pom.xml for one of my projects I'm quite
> confused about what I'm looking at. There's a graphical view of the
> pom.xml but I don't know what information it wants, it won't let me
> select "jar" as the "packaging," and even if I got the pom right I
> don't see how to tell it to "do it" and actually produce the jar.
> Nothing in the Maven menu seems to be for doing this. Will "Build
> Project" do the right thing if/when I have the right pom? I tried it
> with "packaging" set to "war" (since it wouldn't let me select
> "rar") and it seemed to do *something*, but I don't see any
> resulting file. Anyone know of a tutorial or blog post that walks a
> newbie like me through using m2e? My web searches have only turned
> up descriptions of how to open existing Maven projects or to do much
> more exotic things, like using Maven to develop new Eclipse plugins
> (and vice versa? I'm pretty lost! :-). I guess I could give up on
> this and go to raw xml and the command line to create poms and run
> Maven to build my eclipse projects as applets or whatever, but
> shouldn't m2e make this easier?
Using any graphical UI is sort of like using a calculator for math; if
you don't understand the math already, the calculator will feel either
like magic or an intransigent monster. :-)
"jar" is the default packaging; the fact that selecting it gives you
the impression that that's an invalid choice is *very* unfortunate.
In any case, I never use the graphical m2 interface, and I suspect I
do what I need to faster for it. Perhaps part of that is that, IMO,
the m2 UI is astonishingly bad (ironic that it's produced by the
authors of Maven itself, whereas the Maven UI in NetBeans, which
isn't, is far superior). It's serviceable for running maven, but I'd
stick to the "raw" pom.xml editor if I were you (at least until you
grok the basics).
As far as tutorials, you cannot get any better than Sonatype's maven
books:
http://www.sonatype.com/books.html
The "by example" is the introductory one, so start with that.
Again, what you're aiming to do should fall into place fairly easily
using the sample pom I provided in that blog post (modulo whatever
other dependencies your project requires).
- Chas
Laurent PETIT
On Sep 20, 2010, at 6:11 PM, Lee Spector wrote:
2) <rant, not targeted to you but to the whole unfair universe> Really, why do I or anyone have to learn this? Why *isn't* there just a button in Eclipse that does it? Surely it's a common enough need. Eclipse must already know all of the dependencies etc since it runs the thing just fine itself. Why wouldn't there be a button or, if there are options that must be specified, a wizard that packages up the same thing that Eclipse runs as code that can run elsewhere, e.g. as an applet (among other options)? Is this not done because it wouldn't work for giant projects with lots of special requirements that have to download libraries etc.? So people invent whole languages and systems for specifying this stuff, and require that everyone commit to one and read books on it and install and master additional software even if they just want to export a hello world applet? It seems sort of like if gcc came without a -o option, and if you had to learn an output-specification language, and download output-specification software, in order to produce an executable from your "hello world" C program. I know the example isn't entirely parallel, but the lack of a simple way to do this in what is "considered by many to be the best Java development tool available" seems really quite odd to me. </rant>
Eclipse, and the JVM ecosystem more broadly, has always preferred a modular approach to its architectures: tending towards reuse, interoperability, and interchangeability of small (and sometimes, not so small) components. That leads to a great deal of flexibility, but a far higher degree of complexity than one sees in vertically-integrated architectures: i.e. compare Eclipse/JVM with Visual Studio/.NET, where the latter, because it is a vertically-integrated system provided by a single vendor, offers a far simpler process for common operations, including builds of all sorts, user interface design, etc. etc. The downside of the vertically-integration option being that, once you step outside of the well-marked path provided by your vendor, you're in for a far longer road than if you could just pluck a different component off the shelf to replace the default from the factory.
Put another way, there isn't just a button in Eclipse for what you want because then there'd have to be a button for each of the other build processes.
3) I have m2e maven support installed in my Eclipse (which got there when I followed instructions for getting labrepl). I'm guessing/hoping this will ease doing what I need from within Eclipse, but after using it to create a pom.xml for one of my projects I'm quite confused about what I'm looking at. There's a graphical view of the pom.xml but I don't know what information it wants, it won't let me select "jar" as the "packaging," and even if I got the pom right I don't see how to tell it to "do it" and actually produce the jar. Nothing in the Maven menu seems to be for doing this. Will "Build Project" do the right thing if/when I have the right pom? I tried it with "packaging" set to "war" (since it wouldn't let me select "rar") and it seemed to do *something*, but I don't see any resulting file. Anyone know of a tutorial or blog post that walks a newbie like me through using m2e? My web searches have only turned up descriptions of how to open existing Maven projects or to do much more exotic things, like using Maven to develop new Eclipse plugins (and vice versa? I'm pretty lost! :-). I guess I could give up on this and go to raw xml and the command line to create poms and run Maven to build my eclipse projects as applets or whatever, but shouldn't m2e make this easier?
Using any graphical UI is sort of like using a calculator for math; if you don't understand the math already, the calculator will feel either like magic or an intransigent monster. :-)
"jar" is the default packaging; the fact that selecting it gives you the impression that that's an invalid choice is *very* unfortunate.
In any case, I never use the graphical m2 interface, and I suspect I do what I need to faster for it. Perhaps part of that is that, IMO, the m2 UI is astonishingly bad (ironic that it's produced by the authors of Maven itself, whereas the Maven UI in NetBeans, which isn't, is far superior). It's serviceable for running maven, but I'd stick to the "raw" pom.xml editor if I were you (at least until you grok the basics).
As far as tutorials, you cannot get any better than Sonatype's maven books:
http://www.sonatype.com/books.html
The "by example" is the introductory one, so start with that.
Again, what you're aiming to do should fall into place fairly easily using the sample pom I provided in that blog post (modulo whatever other dependencies your project requires).
- Chas
--
You received this message because you are subscribed to the Google Groups "counterclockwise-users" group.
To post to this group, send email to clojured...@googlegroups.com.
Lee Spector
On Sep 21, 2010, at 6:13 AM, Chas Emerick wrote:
> It sounds like you converted a standard java/clojure project to a maven project, which implies that all of its configuration flows from the pom.xml file.
>
> Specifically, if you're seeing a NCDFE related to clojure, that means that either your pom doesn't specify an appropriate clojure dependency, or that it hasn't been pulled into your local maven repository.
>
> Deleting the pom file is a fairly nuclear option though. :-)
So am I right that using "Maven > Enable dependency management" in Eclipse with m2e is a trap door, from which there's no return? Luckily I did that only on a throw-away project. The nuclear option, for all its explosiveness, didn't work :-(. I guess there must still be residual information somewhere saying to use Maven, but I don't see it. I see a (hidden) .project file but it's identical (except for the <name>) to the one from my non-mavenized projects. I see a org.maven.ide.eclipse.prefs in .settings but removing it doesn't solve the problem. Nor does cleaning. I'll just throw it away, but it's creepy :-).
> If the "fat" jar approach that Eclipse does offer suits you, then I'd suggest backing away from maven/ant entirely, and get to where your project configuration was. Otherwise, I'd focus on getting a pom file that will build your project as you'd like; if you get to that point, then the m2 plugin will ensure that the eclipse configuration is mirrored, and Clojure REPL stuff should go off without a hitch.
I think I will (back away from maven/ant entirely), at least for now.
What still has me confused is the fact that all of the dependency information is already in Eclipse. It has to be, because it runs my code just fine. Right? So why does m2e make me specify all of this stuff again? I've now looked at http://github.com/talios/clojure-maven-plugin (as well as your blog post), and I'm beginning to get a sense of what I need to do to correctly Mavenize my clojure projects (to enable exporting of applets made with rosado's clj-processing, which is what sent me down this path), but I'm still puzzled about why there's no automatic or nearly automatic way to get the information, which Eclipse already has, into Maven.
Perhaps this might (?) be a constructive suggestion: Include a new section on http://code.google.com/p/counterclockwise/wiki/Documentation, under "Package your work," with a title something like "Use Maven for builds" that includes:
0. A sentence about why one might want to do this -- seems crazy to you, I'm sure, and I know that page isn't a tutorial on life in the JVM, but for someone coming from the Lisp world a very brief mention about why one would care about this would be orienting.
1. instructions for installing m2e
2. a default pom.xml, like the one in your blog post (and it would be fabulous if this could somehow be made to be the default when enabling Maven for a project).
3. instructions for how to organize your Clojure code so that the default pom.xml will find everything.
4. pointers to sources of more info if the defaults aren't sufficient.
Does that make sense? I don't know if this is correct or complete, since I haven't yet done it and I'm still fuzzy on the concept. But for people coming from my far-off planet it would be great for there to be a little more guidance here.
Thanks, -Lee
Laurent PETIT
--
You received this message because you are subscribed to the Google Groups "counterclockwise-users" group.
To post to this group, send email to clojured...@googlegroups.com.
Lee Spector
On Sep 21, 2010, at 6:50 AM, Laurent PETIT wrote:
>
>
> 2010/9/21 Chas Emerick <ceme...@snowtide.com>
>> Eclipse, and the JVM ecosystem more broadly, has always preferred a modular approach to its architectures: tending towards reuse, interoperability, and interchangeability of small (and sometimes, not so small) components. That leads to a great deal of flexibility, but a far higher degree of complexity than one sees in vertically-integrated architectures: i.e. compare Eclipse/JVM with Visual Studio/.NET, where the latter, because it is a vertically-integrated system provided by a single vendor, offers a far simpler process for common operations, including builds of all sorts, user interface design, etc. etc. The downside of the vertically-integration option being that, once you step outside of the well-marked path provided by your vendor, you're in for a far longer road than if you could just pluck a different component off the shelf to replace the default from the factory.
>>
>> Put another way, there isn't just a button in Eclipse for what you want because then there'd have to be a button for each of the other build processes.
>>
>
> Yes, sometimes Eclipse / JEE feels like you can just buy the car pieces as lego bricks.
>
> It seems that Eclipse has not taken seriously enough some heavy trends of the industry: the use of "project managers" (maven !), the use of not-just-file-centric scms (svn ! and more recently DVCS such as Git !), and stick for too many time with cvs and ant as the only out-of-the-box integrated tools. This certainly explains why currently even m2eclipse and EGit are so young projects when they should be mature and *very well/tightly* integrated with the rest.
>
> And such tools as FatJar, etc., should also be integrated ...
>
I appreciate the value of modularity -- in fact it's one of my research areas (in AI & cognitive architectures, not in software development tools, but still...).
But following the lego analogy, it can be *really* valuable to provide the user with at least one default, well-documented way of putting the pieces together. Most lego sets come with clear instructions for building one thing with the set, and every kid first builds that thing and then takes it apart, maybe entirely or maybe into chunks that are then recombined. The default design serves several purposes, giving the kid a working toy and showing the familiarizing the kid with all of the pieces and some of the ways that they interact.
With the software tools we're talking about it's not even clear to the newcomer what all of the pieces in the box are, so it'd be even more helpful to provide a parts list and a default way of putting them together. I gather it's not possible for all of this (integration of FatJar and/or Maven defaults etc) to be actually built in to ccw, but I think that strategic additions to the documentation could help.
-Lee
Laurent PETIT
Lee Spector
On Sep 21, 2010, at 8:46 AM, Laurent PETIT wrote:
> Lee, quick answer (long one may come later) : how about you having edition rights to the counterclockwise wiki ? I think that you could add lot of interesting stuff in the documentation (as the one you provided at the end of the email), and the "workflow" could then be easier : you make / create some doc, and ask for review/completeness here ?
Sure, but I think that on a lot of this my first stab docs may be pretty wildly off the mark. The "hello world" update worked out pretty well in the end, but it might have been wrong for a while if my first stabs had been posted... Maybe that's okay. I still feel more clueless about the build stuff, though, so that would be worse.
>
> Concerning m2eclipse, I'm not an expert, but some info :
>
> * Eclipse does not have the "richness" of maven in its dependencies. For example, maven allows you to state if a dependency is only necessary for the compilation (but will be provided at runtime), is only a declared/known "option" for runtime (but you may want to have all available options locally for automated tests purposes), is a dependency needed for tests, whether the dependency should be "visible" transitively (when others depend on you), etc. So, for one, Eclipse <-> maven dependency synchronization is not bijective, and a Eclipse deps -> maven deps synchronization tool will have to either provided "defaults" for the dependency in the maven's pom.xml, either ask you interactively.
Understood re: the asymmetry. Defaults or interactive asking would both be better than writing the pom.xml from scratch.
> * Anyway, I think there is, in m2eclipse, some support for this bidirectional (or unidirectional) deps synchronization : for "maven pom.xml -> eclipse .classpath/.project", you have the Menu Entry : Maven > update project configuration ; for "eclipse -> maven pom.xml", you have the Menu Entry : ?????
So what I would want here (having started a Clojure project in Eclipse and wanting to Mavenize it to allow for applet JAR creation) is "eclipse -> maven pom.xml", and I *think* you're saying (by "?????") that this option isn't there yet. Right?
-Lee
Lee Spector
On Sep 21, 2010, at 8:58 AM, Laurent PETIT wrote:
>
> I wholeheartedly agree with you, and help with this (you're the perfect fit since you're in the process) would be greatly appreciated, so that I can concentrate on giving tips / checking docs at a minimum, and code new features as a maximum :)
I'll try, as I figure things out enough to know what to write, and I appreciate you doing those things!!!
-Lee
Chas Emerick
On Sep 21, 2010, at 8:33 AM, Lee Spector wrote:
> What still has me confused is the fact that all of the dependency
> information is already in Eclipse. It has to be, because it runs my
> code just fine. Right? So why does m2e make me specify all of this
> stuff again? I've now looked at http://github.com/talios/clojure-maven-plugin
> (as well as your blog post), and I'm beginning to get a sense of
> what I need to do to correctly Mavenize my clojure projects (to
> enable exporting of applets made with rosado's clj-processing, which
> is what sent me down this path), but I'm still puzzled about why
> there's no automatic or nearly automatic way to get the information,
> which Eclipse already has, into Maven.
It is (as far as I can tell) an extremely unusual situation for
someone to have fully configured a working project in Eclipse, only to
want to export that configuration to another build system (e.g. Maven,
gradle, ant, etc). The latter are almost always given precedence, as
one (usually) wants to be able to build a project outside of eclipse
(as well as inside), so the synchronization is generally thought to be
unidirectional, with the build specification (the pom, the build.xml,
whatever gradle uses, etc) as the font of all project configuration.
That's not to say that m2 shouldn't perhaps provide that functionality
(perhaps it already does somewhere?), but I suspect it'd be a crazy
amount of work to aid a very few.
> Perhaps this might (?) be a constructive suggestion: Include a new
> section on http://code.google.com/p/counterclockwise/wiki/Documentation
> , under "Package your work," with a title something like "Use Maven
> for builds" that includes:
That certainly makes sense, although doing it right is nontrivial. I
may yet tackle that to some degree in conjunction with prepping ccw to
be a natural go-to tool to be recommended in the book.
> But following the lego analogy, it can be *really* valuable to
> provide the user with at least one default, well-documented way of
> putting the pieces together. Most lego sets come with clear
> instructions for building one thing with the set, and every kid
> first builds that thing and then takes it apart, maybe entirely or
> maybe into chunks that are then recombined. The default design
> serves several purposes, giving the kid a working toy and showing
> the familiarizing the kid with all of the pieces and some of the
> ways that they interact.
>
> With the software tools we're talking about it's not even clear to
> the newcomer what all of the pieces in the box are, so it'd be even
> more helpful to provide a parts list and a default way of putting
> them together. I gather it's not possible for all of this
> (integration of FatJar and/or Maven defaults etc) to be actually
> built in to ccw, but I think that strategic additions to the
> documentation could help.
I see where you're coming from, but Eclipse/maven/etc are not push-
button tools intended for use (at least in Eclipse's case, in its
standard configuration) by nonprofessionals. Describing a "typical"
newcomer probably can't be done usefully (the array of project types
and deployment scenarios being legion), so talking about "sensible
defaults" is almost useless: whatever path one chooses, there will
inevitably be serious pushback from those that do things differently,
so the null hypothesis holds, and everyone is on their own.
Case in point: ccw *could* provide defaults for some deployment
orientation, plop a pom.xml into new projects, etc, but I'd be
surprised if that ever happened. What about people that prefer gradle
or ant or cake? Or those that do prefer maven, but who now need to
triage the default pom.xml file (which almost certainly gets more
things "wrong" as far as they're concerned as it gets right).
This is a people problem, not a technical problem. As far as I can
tell, the only known-good solution is immersive exposure to
documentation, examples, and community.
- Chas
Laurent PETIT
It is (as far as I can tell) an extremely unusual situation for someone to have fully configured a working project in Eclipse, only to want to export that configuration to another build system (e.g. Maven, gradle, ant, etc). The latter are almost always given precedence, as one (usually) wants to be able to build a project outside of eclipse (as well as inside), so the synchronization is generally thought to be unidirectional, with the build specification (the pom, the build.xml, whatever gradle uses, etc) as the font of all project configuration.
On Sep 21, 2010, at 8:33 AM, Lee Spector wrote:
What still has me confused is the fact that all of the dependency information is already in Eclipse. It has to be, because it runs my code just fine. Right? So why does m2e make me specify all of this stuff again? I've now looked at http://github.com/talios/clojure-maven-plugin (as well as your blog post), and I'm beginning to get a sense of what I need to do to correctly Mavenize my clojure projects (to enable exporting of applets made with rosado's clj-processing, which is what sent me down this path), but I'm still puzzled about why there's no automatic or nearly automatic way to get the information, which Eclipse already has, into Maven.
That's not to say that m2 shouldn't perhaps provide that functionality (perhaps it already does somewhere?), but I suspect it'd be a crazy amount of work to aid a very few.
Perhaps this might (?) be a constructive suggestion: Include a new section on http://code.google.com/p/counterclockwise/wiki/Documentation, under "Package your work," with a title something like "Use Maven for builds" that includes:
That certainly makes sense, although doing it right is nontrivial. I may yet tackle that to some degree in conjunction with prepping ccw to be a natural go-to tool to be recommended in the book.
But following the lego analogy, it can be *really* valuable to provide the user with at least one default, well-documented way of putting the pieces together. Most lego sets come with clear instructions for building one thing with the set, and every kid first builds that thing and then takes it apart, maybe entirely or maybe into chunks that are then recombined. The default design serves several purposes, giving the kid a working toy and showing the familiarizing the kid with all of the pieces and some of the ways that they interact.
With the software tools we're talking about it's not even clear to the newcomer what all of the pieces in the box are, so it'd be even more helpful to provide a parts list and a default way of putting them together. I gather it's not possible for all of this (integration of FatJar and/or Maven defaults etc) to be actually built in to ccw, but I think that strategic additions to the documentation could help.
I see where you're coming from, but Eclipse/maven/etc are not push-button tools intended for use (at least in Eclipse's case, in its standard configuration) by nonprofessionals. Describing a "typical" newcomer probably can't be done usefully (the array of project types and deployment scenarios being legion), so talking about "sensible defaults" is almost useless: whatever path one chooses, there will inevitably be serious pushback from those that do things differently, so the null hypothesis holds, and everyone is on their own.
Case in point: ccw *could* provide defaults for some deployment orientation, plop a pom.xml into new projects, etc, but I'd be surprised if that ever happened. What about people that prefer gradle or ant or cake? Or those that do prefer maven, but who now need to triage the default pom.xml file (which almost certainly gets more things "wrong" as far as they're concerned as it gets right).
This is a people problem, not a technical problem. As far as I can tell, the only known-good solution is immersive exposure to documentation, examples, and community.
- Chas
--
You received this message because you are subscribed to the Google Groups "counterclockwise-users" group.
To post to this group, send email to clojured...@googlegroups.com.
Lee Spector
On Sep 22, 2010, at 6:54 AM, Chas Emerick wrote:
>
> It is (as far as I can tell) an extremely unusual situation for someone to have fully configured a working project in Eclipse, only to want to export that configuration to another build system (e.g. Maven, gradle, ant, etc). The latter are almost always given precedence, as one (usually) wants to be able to build a project outside of eclipse (as well as inside), so the synchronization is generally thought to be unidirectional, with the build specification (the pom, the build.xml, whatever gradle uses, etc) as the font of all project configuration.
>
> That's not to say that m2 shouldn't perhaps provide that functionality (perhaps it already does somewhere?), but I suspect it'd be a crazy amount of work to aid a very few.
I start a project by firing up Eclipse/Counterclockwise, creating a new Clojure project, and writing some code. Then I want to spit out an applet that runs my code. Is this an extremely unusual situation? I don't "want" to export anything to Maven, gradle, ant, or anything else. In fact I'd be happy never to have to learn anything about any of those systems. I just want to produce an applet that runs my code, all of which already runs correctly (with all dependencies satisfied, etc.) in Eclipse. When I asked how to do that the answer seemed to be "use Maven." Okay, so I had m2 installed so I tried it and found that:
(1) It's really non-obvious how to get it to work correctly. Even though Eclipse already has all of the required dependency information, it isn't passing that along to Maven. I think that your blog post will help me to sort this out, and I'm grateful for that, but even so this seems like a lot more work than should be required.
(2) It's a trap door that leaves my Eclipse project in an un-runnable state. I can't run the code in a REPL anymore and I can't even undo the Mavenization. I have to start a new project from scratch.
This strikes me as an unsatisfactory situation for what I would expect to be a fairly common situation if Eclipse/ccw is to be used as a Clojure IDE: Someone starts a project in Eclipse/ccw and wants to get out an executable JAR.
Is it "starting a project in Eclipse/ccw" that you think will be extremely unusual? If Eclipse/ccw is my IDE that will be what I do 100% of the time. Or is it "wanting to produce an executable JAR"? Surely that's not unusual. How can this combination be extremely unusual?
At this point I think that the better answer for me would have been "use Fat JAR", and that's what I plan to do (haven't yet had the chance). But I gather that that's going to make something unnecessarily big and that "Use Maven" (or one of those other things -- I really don't care which!) is the better long term answer. But in that case we're back in the situation I described above, which is not good.
> I see where you're coming from, but Eclipse/maven/etc are not push-button tools intended for use (at least in Eclipse's case, in its standard configuration) by nonprofessionals. Describing a "typical" newcomer probably can't be done usefully (the array of project types and deployment scenarios being legion), so talking about "sensible defaults" is almost useless: whatever path one chooses, there will inevitably be serious pushback from those that do things differently, so the null hypothesis holds, and everyone is on their own.
>
> Case in point: ccw *could* provide defaults for some deployment orientation, plop a pom.xml into new projects, etc, but I'd be surprised if that ever happened. What about people that prefer gradle or ant or cake? Or those that do prefer maven, but who now need to triage the default pom.xml file (which almost certainly gets more things "wrong" as far as they're concerned as it gets right).
>
> This is a people problem, not a technical problem. As far as I can tell, the only known-good solution is immersive exposure to documentation, examples, and community.
If "make it go" (essentially "hello world" with an executable being produced at the end) requires immersive exposure to documentation, examples, and community then that is really not a good state of affairs and I hope that we can do better.
I would expect such immersion to be required if I had preferences for specific tools or ways of doing things and I wanted things done my way. But I don't. I just want it to work, any old way. If my IDE produces executables using gradle (which I know absolutely nothing about) that would be dandy with me, and if I later developed some sort of anti-gradle sentiments then I'd expect to have to learn stuff and work to make it work in some other way. But to provide no way to do it, just because different people might want to do it different ways, isn't helpful to anyone.
So I really disagree with you on this. This is, I know, a caricature, but imagine a word processing app that came with no GUI because hey, people have different GUI preferences and a lot of people are going to want things to look different. So here's a word processing app but if you really want to use it and actually see your document you have to immerse yourself in the documentation, examples, and community of GUI design and libraries. This is not helpful to the novelist who wants a word processor! On the other hand if you provide a word processor with a functioning GUI but also make it customizable, or even easy to swap in entirely different GUI components, then that's all for the good. I (and many others, including many who are long-term/professional programmers, but just not in this ecosystem) are like the novelists here. We want a system that allows us to write Clojure code and make it go (including producing an executable), and any default way of doing that that works will be great. Requiring immersive exposure to documentation, examples, and community to complete a basic step in "making it go" seems to me to be an unnecessary impediment to a large class of potential users.
-Lee
Laurent PETIT
Lee Spector
On Sep 22, 2010, at 8:40 AM, Laurent PETIT wrote:
>
> Please really see FatJar : http://fjep.sourceforge.net/
>
> I see that it allows to exclude some files / directories. I don't know whether it allows to exclude at the dependency level (e.g. exclude some jar).
> FatJar allows you to save on disk the configuration of the export, so you can put in in scm.
> The downside of this "all eclipse" approach is, as usual, that it's not usable outside Eclipse, e.g. in an automated build tool.
I definitely will. If I'm using Eclipse as my IDE from start to finish, which is my preference (to learn and stick to one tool as much as possible), then this downside isn't a problem.
> Concerning maven, ant, lein, gradle, etc., here is my current position:
> a. if somebody already knows maven, then he's using the command line or m2eclipse, he knows how to synchronize his Eclipse project, how to "create" an Eclipse project from a mavenized project with no Eclipse support (mvn eclipse:eclipse), etc. He doesn't need any specific maven support from ccw.
> b. It would be interesting if Eclipse had a "generic" way to manage dependencies (which versions, which are dev-only dependencies).
> b1. Eclipse does not have this "abstraction level" over all the dep management tools ecosystem. It's a fact. CCW will not create a new one. I just intend to use the most simple "declarative" system available. It will be lein's project.clj. Simple, stable, clojure code, pure clojure datastructures.
> c. ccw will also need some "persistent" storage for some project configurations. To cite just one: the list of namespaces that need AOT compilation (a feature that will appear in the future : when we're there, not all the project will be AOT compiled, only the explicitly mentioned namespaces).
> c1. Here again, lein to the rescue.
>
> Note that this does not necessarily imply, at this stage of the reasoning, that ccw will be using lein's implementation. Just lein's declarative formalism.
> But adding support for launching lein commands from ccw is also on the table.
>
> project.clj support could be bi-directional : your project.clj is modified => apply the modification to Eclipse's project .project and .classpath. You manually add a dependency to the java build path of your project (or the .project.clj .classpath.clj is modified due to m2eclipse having just tweaked the deps of the project and updated the .project/.classpath) => project.clj is updated with the dependency, with as much inferred information as possible ( the jar ends with -1.2.9.jar => infer a version information ; the M2_REPOSITORY folder is a parent of the jar's folder ? => infer the groupId and artifactId ; the jar's MANIFEST.MF contains a maven pom.xml, use it, etc...).
>
> In the future, even more interesting stuff will be able: open your project.clj, start to add a dependency: the code completion could do remote calls to pre-configured public repositories to help locate a new dependency ..., (but that's science fiction currently for ccw, heh) :-)
I don't yet understand all that that this implies, but it sounds good to me as long as a default way to make things work without specialized knowledge is maintained. FWIW I do like the lein-style Lispy representations, from what I've seen, and if I had to choose a declarative representation for dependencies etc. I'd go with that too.
Thanks so much,
-Lee
Chas Emerick
On Sep 22, 2010, at 8:05 AM, Lee Spector wrote:
> I start a project by firing up Eclipse/Counterclockwise, creating a
> new Clojure project, and writing some code. Then I want to spit out
> an applet that runs my code. Is this an extremely unusual situation?
> I don't "want" to export anything to Maven, gradle, ant, or anything
> else. In fact I'd be happy never to have to learn anything about any
> of those systems. I just want to produce an applet that runs my
> code, all of which already runs correctly (with all dependencies
> satisfied, etc.) in Eclipse. When I asked how to do that the answer
> seemed to be "use Maven."
Or "use XXXX", where XXXX is whatever build system you're comfortable
with. Make would do just fine as well, though I suspect there's no
integration between eclipse and make (though I wouldn't be shocked if
there was).
A few things though:
- Yes, deploying applets is very unusual. They're just jars of
course, which aren't unusual, but the mode of deployment is.
- Wanting the IDE to handle build and deployment tasks end-to-end is a
huge red flag to me. IDEs imply local environments, which imply
unportable builds (i.e. what builds on your machine is less likely to
build on mine, and simply won't build for someone that doesn't use
Eclipse, etc). This is why most people start with their build tools,
and synchronize the configuration for those with their IDE(s).
- The amount of configuration one does in Eclipse to do what you're
talking about (e.g. Clojure + processing) is absolutely trivial.
Pushing to have that small amount of work saved via a thoroughgoing
bidirectional synchronization feature in m2 is almost surely
unrealistic.
> This strikes me as an unsatisfactory situation for what I would
> expect to be a fairly common situation if Eclipse/ccw is to be used
> as a Clojure IDE: Someone starts a project in Eclipse/ccw and wants
> to get out an executable JAR.
>
> Is it "starting a project in Eclipse/ccw" that you think will be
> extremely unusual? If Eclipse/ccw is my IDE that will be what I do
> 100% of the time. Or is it "wanting to produce an executable JAR"?
> Surely that's not unusual. How can this combination be extremely
> unusual?
There's certainly nothing wrong with starting a project in Eclipse,
but I'd wager that wanting to go end-to-end within Eclipse is
extremely unusual (see point #2 above).
> If "make it go" (essentially "hello world" with an executable being
> produced at the end) requires immersive exposure to documentation,
> examples, and community then that is really not a good state of
> affairs and I hope that we can do better.
>
> I would expect such immersion to be required if I had preferences
> for specific tools or ways of doing things and I wanted things done
> my way. But I don't. I just want it to work, any old way. If my IDE
> produces executables using gradle (which I know absolutely nothing
> about) that would be dandy with me, and if I later developed some
> sort of anti-gradle sentiments then I'd expect to have to learn
> stuff and work to make it work in some other way. But to provide no
> way to do it, just because different people might want to do it
> different ways, isn't helpful to anyone.
I understand where you're coming from (e.g. the processing tool and
monolithic lisp implementations), but for better or worse, the wider
ecosystem in which Clojure operates (primarily the JVM right now) is
worlds away from that, and has had ~15 years to grow tools given a
philosophy of modularity and There's More Than One Way To Do It.
Using "pure" Clojure tools (like lein and cake) get one away from all
that craziness for the most part, but also locks one into a very
limited few modes of operation, with few clear paths out/up. Insofar
as such things get associated with Clojure itself or its tools (like
ccw) that's an unnecessary binding of orthogonal concerns, and
anathema to using Clojure as a general-purpose programming language IMO.
> So I really disagree with you on this. This is, I know, a
> caricature, but imagine a word processing app that came with no GUI
> because hey, people have different GUI preferences and a lot of
> people are going to want things to look different. So here's a word
> processing app but if you really want to use it and actually see
> your document you have to immerse yourself in the documentation,
> examples, and community of GUI design and libraries. This is not
> helpful to the novelist who wants a word processor! On the other
> hand if you provide a word processor with a functioning GUI but also
> make it customizable, or even easy to swap in entirely different GUI
> components, then that's all for the good. I (and many others,
> including many who are long-term/professional programmers, but just
> not in this ecosystem) are like the novelists here. We want a system
> that allows us to write Clojure code and make it go (including
> producing an executable), and any default way of doing that that
> works will be great. Requiring immersive exposure to documentation,
> examples, and community to complete a basic step in "making it go"
> seems to me to be an unnecessary impediment to a large class of
> potential users.
Yes, we're in basic disagreement. At root of this, I think, is the
question: "What does 'make it go' mean?". If you ask 100 programmers,
you'll likely hear 250 responses. If you can find defaults given a
situation like that, you've got yourself a goldmine.
At one time, there were only a few modes of distribution (essentially:
build executable for one, perhaps two platforms, send over the wire,
done). That time is long past though, and software developers cannot
afford to be strict domain experts that stick to their knitting and
write code: the modes of distribution of one's software are at least
as critical as the software itself. Beyond that, interests of quality
and continuity have pushed the development and adoption of practices
like continuous integration and deployment, which require a rigor
w.r.t. configuration management and build tooling as serious as one
pays to one's "real" domain.
To match up with your analogy, programmers are not simply novelists,
but must further concern themselves with printing, binding, and
channel distribution.
Within that context, I much prefer tools and practices that can ramp
from fairly simple cases (as described in my blog), up to the heights
of build automation, automated functional testing, and continuous
deployment. One should not have to switch horses at various stages of
the growth of a project just to accommodate changing tooling
requirements. Thus, I encourage the use of maven, which has (IMO) the
least uneven character along that spectrum; ant strains at more
sophisticated tasks, especially in larger projects; it appears that
gradle is well on its way to being competitive with maven in most if
not all circumstances.
</extemporaneousness>
Anyway. :-) Thank you for the perspective. It was very good for
motivating some further thought on this end.
- Chas
Laurent PETIT
Or "use XXXX", where XXXX is whatever build system you're comfortable with. Make would do just fine as well, though I suspect there's no integration between eclipse and make (though I wouldn't be shocked if there was).
On Sep 22, 2010, at 8:05 AM, Lee Spector wrote:
I start a project by firing up Eclipse/Counterclockwise, creating a new Clojure project, and writing some code. Then I want to spit out an applet that runs my code. Is this an extremely unusual situation? I don't "want" to export anything to Maven, gradle, ant, or anything else. In fact I'd be happy never to have to learn anything about any of those systems. I just want to produce an applet that runs my code, all of which already runs correctly (with all dependencies satisfied, etc.) in Eclipse. When I asked how to do that the answer seemed to be "use Maven."
A few things though:
- Yes, deploying applets is very unusual. They're just jars of course, which aren't unusual, but the mode of deployment is.
- Wanting the IDE to handle build and deployment tasks end-to-end is a huge red flag to me. IDEs imply local environments, which imply unportable builds (i.e. what builds on your machine is less likely to build on mine, and simply won't build for someone that doesn't use Eclipse, etc). This is why most people start with their build tools, and synchronize the configuration for those with their IDE(s).
- The amount of configuration one does in Eclipse to do what you're talking about (e.g. Clojure + processing) is absolutely trivial. Pushing to have that small amount of work saved via a thoroughgoing bidirectional synchronization feature in m2 is almost surely unrealistic.There's certainly nothing wrong with starting a project in Eclipse, but I'd wager that wanting to go end-to-end within Eclipse is extremely unusual (see point #2 above).
This strikes me as an unsatisfactory situation for what I would expect to be a fairly common situation if Eclipse/ccw is to be used as a Clojure IDE: Someone starts a project in Eclipse/ccw and wants to get out an executable JAR.
Is it "starting a project in Eclipse/ccw" that you think will be extremely unusual? If Eclipse/ccw is my IDE that will be what I do 100% of the time. Or is it "wanting to produce an executable JAR"? Surely that's not unusual. How can this combination be extremely unusual?
I understand where you're coming from (e.g. the processing tool and monolithic lisp implementations), but for better or worse, the wider ecosystem in which Clojure operates (primarily the JVM right now) is worlds away from that, and has had ~15 years to grow tools given a philosophy of modularity and There's More Than One Way To Do It.
If "make it go" (essentially "hello world" with an executable being produced at the end) requires immersive exposure to documentation, examples, and community then that is really not a good state of affairs and I hope that we can do better.
I would expect such immersion to be required if I had preferences for specific tools or ways of doing things and I wanted things done my way. But I don't. I just want it to work, any old way. If my IDE produces executables using gradle (which I know absolutely nothing about) that would be dandy with me, and if I later developed some sort of anti-gradle sentiments then I'd expect to have to learn stuff and work to make it work in some other way. But to provide no way to do it, just because different people might want to do it different ways, isn't helpful to anyone.
Using "pure" Clojure tools (like lein and cake) get one away from all that craziness for the most part, but also locks one into a very limited few modes of operation, with few clear paths out/up.
Insofar as such things get associated with Clojure itself or its tools (like ccw) that's an unnecessary binding of orthogonal concerns, and anathema to using Clojure as a general-purpose programming language IMO.
Yes, we're in basic disagreement. At root of this, I think, is the question: "What does 'make it go' mean?". If you ask 100 programmers, you'll likely hear 250 responses. If you can find defaults given a situation like that, you've got yourself a goldmine.
So I really disagree with you on this. This is, I know, a caricature, but imagine a word processing app that came with no GUI because hey, people have different GUI preferences and a lot of people are going to want things to look different. So here's a word processing app but if you really want to use it and actually see your document you have to immerse yourself in the documentation, examples, and community of GUI design and libraries. This is not helpful to the novelist who wants a word processor! On the other hand if you provide a word processor with a functioning GUI but also make it customizable, or even easy to swap in entirely different GUI components, then that's all for the good. I (and many others, including many who are long-term/professional programmers, but just not in this ecosystem) are like the novelists here. We want a system that allows us to write Clojure code and make it go (including producing an executable), and any default way of doing that that works will be great. Requiring immersive exposure to documentation, examples, and community to complete a basic step in "making it go" seems to me to be an unnecessary impediment to a large class of potential users.
At one time, there were only a few modes of distribution (essentially: build executable for one, perhaps two platforms, send over the wire, done). That time is long past though, and software developers cannot afford to be strict domain experts that stick to their knitting and write code: the modes of distribution of one's software are at least as critical as the software itself. Beyond that, interests of quality and continuity have pushed the development and adoption of practices like continuous integration and deployment, which require a rigor w.r.t. configuration management and build tooling as serious as one pays to one's "real" domain.
To match up with your analogy, programmers are not simply novelists, but must further concern themselves with printing, binding, and channel distribution.
Within that context, I much prefer tools and practices that can ramp from fairly simple cases (as described in my blog), up to the heights of build automation, automated functional testing, and continuous deployment. One should not have to switch horses at various stages of the growth of a project just to accommodate changing tooling requirements. Thus, I encourage the use of maven, which has (IMO) the least uneven character along that spectrum; ant strains at more sophisticated tasks, especially in larger projects; it appears that gradle is well on its way to being competitive with maven in most if not all circumstances.
</extemporaneousness>
Anyway. :-) Thank you for the perspective. It was very good for motivating some further thought on this end.
- Chas
--
You received this message because you are subscribed to the Google Groups "counterclockwise-users" group.
To post to this group, send email to clojured...@googlegroups.com.
Chas Emerick
> An easy way *out/up* of lein would be a working (if it's not already
> working, I don't know) lein plugin for one-way generation of a
> pom.xml from a project.clj (with the correct setting of clojure-
> maven-plugin for aot namespaces, etc., etc.).
I'd have done this myself a long time ago, if I weren't swamped
otherwise.
A contributing factor is that I unfortunately still don't entirely
grok lein et al. Eschewing tools because of syntax (i.e. running away
from something that uses XML or yaml or sexprs regardless of its
capabilities) doesn't make a stitch of sense to me.
*shrug*
- Chas
Chas Emerick
> So I really disagree with you on this.
thoughts about this conversation here:
http://cemerick.com/2010/09/22/wherein-i-feel-the-pain-of-being-a-generalist/
Hopefully I can be of more constructive help next time. :-)
- Chas
Lee Spector
Just read it and very much appreciate it!
In a more scrappy mode I have an unfinished reply to your previous message which I'll finish and send shortly (but note that it was written before I saw your post).
Lee Spector
On Sep 22, 2010, at 10:22 AM, Chas Emerick wrote:
> Or "use XXXX", where XXXX is whatever build system you're comfortable with. Make would do just fine as well, though I suspect there's no integration between eclipse and make (though I wouldn't be shocked if there was).
Yeah, but I'm not really comfortable with any in this ecosystem -- I'm coming into it for the sake of Clojure (the language, about which yes [added after reading your blog post] I am really very enthusiastic) and will happily adopt anything that works and is simple to set up, but I need guidance in figuring out what that is.
> - Yes, deploying applets is very unusual. They're just jars of course, which aren't unusual, but the mode of deployment is.
I *think* the whole applet thing is a red herring, and that the trick is just to get an executable jar. Right? And that's not unusual, so it would seem to be reasonable to build in *some* way of doing that. That said, there are a heck of a lot of applets out there so I'm not sure how you can say that deploying applets is very unusual.
> - Wanting the IDE to handle build and deployment tasks end-to-end is a huge red flag to me. IDEs imply local environments, which imply unportable builds (i.e. what builds on your machine is less likely to build on mine, and simply won't build for someone that doesn't use Eclipse, etc). This is why most people start with their build tools, and synchronize the configuration for those with their IDE(s).
Well we do clearly have different perspectives here (more on that below), but for what it's worth I usually don't care at all if my projects can't build in other environments. At least not until the project is quite mature. I write lots of small programs that usually begin and end with me, at least with respect to programming (although I may have many more users in some cases). If it can build on my machine, in my environment, I'll be happy. Not a good idea if I'm developing a big project as part of a team, I agree! But if I have to start with the goal of making it work for everyone, on every platform, before I can make it work on my own, then I'm unhappy.
> - The amount of configuration one does in Eclipse to do what you're talking about (e.g. Clojure + processing) is absolutely trivial. Pushing to have that small amount of work saved via a thoroughgoing bidirectional synchronization feature in m2 is almost surely unrealistic.
I'm not entirely sure what you're getting at here but I don't have a goal of "a thoroughgoing bidirectional synchronization feature in m2" unless that's the simplest way of starting a project in eclipse and getting an executable JAR out the other end.
> There's certainly nothing wrong with starting a project in Eclipse, but I'd wager that wanting to go end-to-end within Eclipse is extremely unusual (see point #2 above).
That's too bad, and I hope that I can convince you and/or others that it's worth changing this. Not that I would want to coerce anyone into using Eclipse (or any single environment) end-to-end, but it would be really nice to have *a* way to go end to end without navigating a range of options for various components and their combinations.
> I understand where you're coming from (e.g. the processing tool and monolithic lisp implementations), but for better or worse, the wider ecosystem in which Clojure operates (primarily the JVM right now) is worlds away from that, and has had ~15 years to grow tools given a philosophy of modularity and There's More Than One Way To Do It.
I think More Than One Way To Do It is lovely. But I also think At Least One Straightforward Way To Do It is something to aim for. Modular tools that can be recombined in myriad ways are awesome, but none of that means that it wouldn't be valuable to have one (or more than one, but at least one) clearly specified way of putting them together that will work for many purposes. I've worked in many environments, including not only several Lisps (& Scheme etc) and Processing but also various C and Pascal (& FORTRAN and APL!] environments etc. (yes, I'm dating myself), and never until my recent Clojure experience has it been such a major research/immersion process to figure out things like how to get one piece of my code to see another piece of my code. I realize that the software world has changed a lot recently, in several ways (mostly for the good!), and I see how that has led to the changes (improvements!) that we've seen in software development tools, many of which provide more yummy flexibility of various kinds. But that doesn't mean that it's necessarily impossible or undesirable to provide straightforward ways to do commonly needed things.
>
> Using "pure" Clojure tools (like lein and cake) get one away from all that craziness for the most part, but also locks one into a very limited few modes of operation, with few clear paths out/up. Insofar as such things get associated with Clojure itself or its tools (like ccw) that's an unnecessary binding of orthogonal concerns, and anathema to using Clojure as a general-purpose programming language IMO.
I would agree that tools should remain orthogonal to the language. But that doesn't mean that there shouldn't be reasonably comprehensive (or at least "end-to-end for one common path") tools.
> Yes, we're in basic disagreement. At root of this, I think, is the question: "What does 'make it go' mean?". If you ask 100 programmers, you'll likely hear 250 responses. If you can find defaults given a situation like that, you've got yourself a goldmine.
Isn't "produce an executable jar" a pretty decent default?
> At one time, there were only a few modes of distribution (essentially: build executable for one, perhaps two platforms, send over the wire, done). That time is long past though, and software developers cannot afford to be strict domain experts that stick to their knitting and write code: the modes of distribution of one's software are at least as critical as the software itself. Beyond that, interests of quality and continuity have pushed the development and adoption of practices like continuous integration and deployment, which require a rigor w.r.t. configuration management and build tooling as serious as one pays to one's "real" domain.
I see what you're saying but I still want to stick to my knitting! There are tools that come close to allowing me to do that (like Eclipse/ccw). I just want to nudge them in the direction of doing it a little more completely.
> To match up with your analogy, programmers are not simply novelists, but must further concern themselves with printing, binding, and channel distribution.
I think that's a seriously suboptimal vision for the future! If Philip K Dick had to be an expert at binding for his novels to be published then the world would be a poorer place. I want to focus my energy on algorithms for evolutionary computation, figuring out the limits to quantum computing, using cognitive models to understand how we think and feel, and making algorithmic art. I know that part of the cost of entry now is to muck with development environments, but I think it'll be a better day when authors *don't* have to master the chemistry of ink in order to produce their novels.
> Within that context, I much prefer tools and practices that can ramp from fairly simple cases (as described in my blog), up to the heights of build automation, automated functional testing, and continuous deployment. One should not have to switch horses at various stages of the growth of a project just to accommodate changing tooling requirements. Thus, I encourage the use of maven, which has (IMO) the least uneven character along that spectrum; ant strains at more sophisticated tasks, especially in larger projects; it appears that gradle is well on its way to being competitive with maven in most if not all circumstances.
>
> </extemporaneousness>
>
> Anyway. :-) Thank you for the perspective. It was very good for motivating some further thought on this end.
>
Likewise!
Laurent PETIT
Yeah, but I'm not really comfortable with any in this ecosystem -- I'm coming into it for the sake of Clojure (the language, about which yes [added after reading your blog post] I am really very enthusiastic) and will happily adopt anything that works and is simple to set up, but I need guidance in figuring out what that is.
On Sep 22, 2010, at 10:22 AM, Chas Emerick wrote:
> Or "use XXXX", where XXXX is whatever build system you're comfortable with. Make would do just fine as well, though I suspect there's no integration between eclipse and make (though I wouldn't be shocked if there was).
I *think* the whole applet thing is a red herring, and that the trick is just to get an executable jar. Right? And that's not unusual, so it would seem to be reasonable to build in *some* way of doing that. That said, there are a heck of a lot of applets out there so I'm not sure how you can say that deploying applets is very unusual.
> - Yes, deploying applets is very unusual. They're just jars of course, which aren't unusual, but the mode of deployment is.
I must disagree. If you're speaking about Java applets, those that are embedded in the browser, they are really in minority today. Web development via java applet has been abandoned by most actors (at least for enterprise dev) very quickly, in favor of java on the server / dhtml+javascript on the client.
Well we do clearly have different perspectives here (more on that below), but for what it's worth I usually don't care at all if my projects can't build in other environments. At least not until the project is quite mature. I write lots of small programs that usually begin and end with me, at least with respect to programming (although I may have many more users in some cases). If it can build on my machine, in my environment, I'll be happy. Not a good idea if I'm developing a big project as part of a team, I agree! But if I have to start with the goal of making it work for everyone, on every platform, before I can make it work on my own, then I'm unhappy.
> - Wanting the IDE to handle build and deployment tasks end-to-end is a huge red flag to me. IDEs imply local environments, which imply unportable builds (i.e. what builds on your machine is less likely to build on mine, and simply won't build for someone that doesn't use Eclipse, etc). This is why most people start with their build tools, and synchronize the configuration for those with their IDE(s).
This is an important point. It's almost the same problem for svn versus e.g. git when considering branches. Doing branches in svn was possible, but was not done : even if it was just a tiny little additional "cost" to use them with svn (longer paths to type, e.g. https://serveur/svn/repo/app1/branches/branch1 for svn versus branch1 for git), this cost was too high for a common usage.
It's possible that power users of maven today are like power users of subversion yesterday: they don't "see" this additional tiny cost, and so they don't understand why their less "able" friends looked at it with disgust. Maybe it's also the same in certain areas for clojure vs java ! :)
I'm not entirely sure what you're getting at here but I don't have a goal of "a thoroughgoing bidirectional synchronization feature in m2" unless that's the simplest way of starting a project in eclipse and getting an executable JAR out the other end.
> - The amount of configuration one does in Eclipse to do what you're talking about (e.g. Clojure + processing) is absolutely trivial. Pushing to have that small amount of work saved via a thoroughgoing bidirectional synchronization feature in m2 is almost surely unrealistic.
That's too bad, and I hope that I can convince you and/or others that it's worth changing this. Not that I would want to coerce anyone into using Eclipse (or any single environment) end-to-end, but it would be really nice to have *a* way to go end to end without navigating a range of options for various components and their combinations.
> There's certainly nothing wrong with starting a project in Eclipse, but I'd wager that wanting to go end-to-end within Eclipse is extremely unusual (see point #2 above).
I think More Than One Way To Do It is lovely. But I also think At Least One Straightforward Way To Do It is something to aim for. Modular tools that can be recombined in myriad ways are awesome, but none of that means that it wouldn't be valuable to have one (or more than one, but at least one) clearly specified way of putting them together that will work for many purposes. I've worked in many environments, including not only several Lisps (& Scheme etc) and Processing but also various C and Pascal (& FORTRAN and APL!] environments etc. (yes, I'm dating myself), and never until my recent Clojure experience has it been such a major research/immersion process to figure out things like how to get one piece of my code to see another piece of my code. I realize that the software world has changed a lot recently, in several ways (mostly for the good!), and I see how that has led to the changes (improvements!) that we've seen in software development tools, many of which provide more yummy flexibility of various kinds. But that doesn't mean that it's necessarily impossible or undesirable to provide straightforward ways to do commonly needed things.
> I understand where you're coming from (e.g. the processing tool and monolithic lisp implementations), but for better or worse, the wider ecosystem in which Clojure operates (primarily the JVM right now) is worlds away from that, and has had ~15 years to grow tools given a philosophy of modularity and There's More Than One Way To Do It.
I would agree that tools should remain orthogonal to the language. But that doesn't mean that there shouldn't be reasonably comprehensive (or at least "end-to-end for one common path") tools.
>
> Using "pure" Clojure tools (like lein and cake) get one away from all that craziness for the most part, but also locks one into a very limited few modes of operation, with few clear paths out/up. Insofar as such things get associated with Clojure itself or its tools (like ccw) that's an unnecessary binding of orthogonal concerns, and anathema to using Clojure as a general-purpose programming language IMO.
Isn't "produce an executable jar" a pretty decent default?
> Yes, we're in basic disagreement. At root of this, I think, is the question: "What does 'make it go' mean?". If you ask 100 programmers, you'll likely hear 250 responses. If you can find defaults given a situation like that, you've got yourself a goldmine.
Maybe not :) (in fact, really, I'd say no). My bet (and I'm not taking any risk at betting this) is that most projects today are some kinds of development of plugins for some application server. True for Eclipse/Netbeans/RCP development on the client side (and when not true, then the build process for getting an executable is waaaay more involved than just "producing a fat jar from an Eclipse project". True for web development towards servlet/JEE containers. True for enterprise development towards ESBs, EBJ (yuck!) servers, SOA servers (web servers really), etc.
But it's also true that it should be reasonably possible to apply simple heuristics to a project's content to automatically determine the "kind" of project we're facing. This could be automated. 90% of the cases => automatic, no user intervention. 5% of the cases, ambiguity, prompt the user for choosing among kind A, kind B, or specify the kind manually. 5% of the cases, ask the user to specify the kind manually.
I see what you're saying but I still want to stick to my knitting! There are tools that come close to allowing me to do that (like Eclipse/ccw). I just want to nudge them in the direction of doing it a little more completely.
> At one time, there were only a few modes of distribution (essentially: build executable for one, perhaps two platforms, send over the wire, done). That time is long past though, and software developers cannot afford to be strict domain experts that stick to their knitting and write code: the modes of distribution of one's software are at least as critical as the software itself. Beyond that, interests of quality and continuity have pushed the development and adoption of practices like continuous integration and deployment, which require a rigor w.r.t. configuration management and build tooling as serious as one pays to one's "real" domain.
I'll be willing to help you in this area. Hopefully, Chas will be refraining my enthusiasm and give an interesting counter point when you're bringing me too far :-)
I think that's a seriously suboptimal vision for the future! If Philip K Dick had to be an expert at binding for his novels to be published then the world would be a poorer place. I want to focus my energy on algorithms for evolutionary computation, figuring out the limits to quantum computing, using cognitive models to understand how we think and feel, and making algorithmic art. I know that part of the cost of entry now is to muck with development environments, but I think it'll be a better day when authors *don't* have to master the chemistry of ink in order to produce their novels.
> To match up with your analogy, programmers are not simply novelists, but must further concern themselves with printing, binding, and channel distribution.
Likewise!
> Within that context, I much prefer tools and practices that can ramp from fairly simple cases (as described in my blog), up to the heights of build automation, automated functional testing, and continuous deployment. One should not have to switch horses at various stages of the growth of a project just to accommodate changing tooling requirements. Thus, I encourage the use of maven, which has (IMO) the least uneven character along that spectrum; ant strains at more sophisticated tasks, especially in larger projects; it appears that gradle is well on its way to being competitive with maven in most if not all circumstances.
>
> </extemporaneousness>
>
> Anyway. :-) Thank you for the perspective. It was very good for motivating some further thought on this end.
>
-Lee
--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspe...@hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438
Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/
--
You received this message because you are subscribed to the Google Groups "counterclockwise-users" group.
To post to this group, send email to clojured...@googlegroups.com.
Chas Emerick
On Sep 22, 2010, at 3:18 PM, Lee Spector wrote:
>> Using "pure" Clojure tools (like lein and cake) get one away from
>> all that craziness for the most part, but also locks one into a
>> very limited few modes of operation, with few clear paths out/up.
>> Insofar as such things get associated with Clojure itself or its
>> tools (like ccw) that's an unnecessary binding of orthogonal
>> concerns, and anathema to using Clojure as a general-purpose
>> programming language IMO.
>
> I would agree that tools should remain orthogonal to the language.
> But that doesn't mean that there shouldn't be reasonably
> comprehensive (or at least "end-to-end for one common path") tools.
The "one common path" is the difficult part to find/define/get people
agree on.
Web applications are arguably the most common type of software built
in the Java ecosystem these days. For that, there is the whole .war
artifact / servlet app container deployment process. That's a very,
very well-worn path, supported well by every build tool....but,
AFAICT, no IDE (hrm, maybe Oracle JDeveloper?) attempts to provide an
end-to-end push-button process for that. The grails framework
simplifies things to a large extent by simply defining a lot of the
configuration by fiat (the oft-mentioned convention-over-
configuration), but the deployment process is still likely nontrivial
to a newcomer. NetBeans has a nifty deploy-to-server function (maybe
only for Glassfish and Tomcat?), but quite simply *no one* would use
it for more than fiddling and local development.
>> Yes, we're in basic disagreement. At root of this, I think, is the
>> question: "What does 'make it go' mean?". If you ask 100
>> programmers, you'll likely hear 250 responses. If you can find
>> defaults given a situation like that, you've got yourself a goldmine.
>
> Isn't "produce an executable jar" a pretty decent default?
No; I'd refer to Laurent's reply on this re: applets. "Executable"
jars are a bit of a misnomer to begin with. Thick-client applications
are almost uniformly deployed using either the NetBeans or Eclipse
RCPs, or using launcher frameworks like jsmooth. Applets have been
passed over by nearly everyone doing thin-client deployments, in favor
of flash, flex, and now javascript + canvas.
>> At one time, there were only a few modes of distribution
>> (essentially: build executable for one, perhaps two platforms, send
>> over the wire, done). That time is long past though, and software
>> developers cannot afford to be strict domain experts that stick to
>> their knitting and write code: the modes of distribution of one's
>> software are at least as critical as the software itself. Beyond
>> that, interests of quality and continuity have pushed the
>> development and adoption of practices like continuous integration
>> and deployment, which require a rigor w.r.t. configuration
>> management and build tooling as serious as one pays to one's "real"
>> domain.
>
> I see what you're saying but I still want to stick to my knitting!
> There are tools that come close to allowing me to do that (like
> Eclipse/ccw). I just want to nudge them in the direction of doing it
> a little more completely.
As you know from my post earlier today, we're in violent agreement on
the fundamental point here. :-)
>> To match up with your analogy, programmers are not simply
>> novelists, but must further concern themselves with printing,
>> binding, and channel distribution.
>
> I think that's a seriously suboptimal vision for the future! If
> Philip K Dick had to be an expert at binding for his novels to be
> published then the world would be a poorer place. I want to focus my
> energy on algorithms for evolutionary computation, figuring out the
> limits to quantum computing, using cognitive models to understand
> how we think and feel, and making algorithmic art. I know that part
> of the cost of entry now is to muck with development environments,
> but I think it'll be a better day when authors *don't* have to
> master the chemistry of ink in order to produce their novels.
The analogy breaks down pretty quickly insofar as the physical
manifestation of the novel has little to do with the effectiveness of
the material it delivers. When you're in the context of providing
scalable web services (for example), deployment and operational and
security concerns are at the heart of one's architecture and
development. The same is true (though to a lesser extent) when
building thick-client applications that need to run effectively on
multiple platforms, update themselves, provide remote usage statistics
when possible, etc.
But again, we're in fundamental agreement, and I suspect that goes way
beyond build tooling and such. Maybe we'll come up with something
sooner rather than later.
- Chas
Lee Spector
On Sep 22, 2010, at 3:42 PM, Laurent PETIT wrote:
>
> I must disagree. If you're speaking about Java applets, those that are embedded in the browser, they are really in minority today. Web development via java applet has been abandoned by most actors (at least for enterprise dev) very quickly, in favor of java on the server / dhtml+javascript on the client.
[and much later]
>> Isn't "produce an executable jar" a pretty decent default?
>
> Maybe not :) (in fact, really, I'd say no). My bet (and I'm not taking any risk at betting this) is that most projects today are some kinds of development of plugins for some application server. True for Eclipse/Netbeans/RCP development on the client side (and when not true, then the build process for getting an executable is waaaay more involved than just "producing a fat jar from an Eclipse project". True for web development towards servlet/JEE containers. True for enterprise development towards ESBs, EBJ (yuck!) servers, SOA servers (web servers really), etc.
I'm learning a lot here but I want to point out that all of the mention of enterprise development and plugin development and servers etc helps show how different our worlds/needs are. I write code for a bunch of different kinds of projects but none has anything whatever to do with enterprise development or these other things that you mention. And yet I'm pretty sure that Clojure is the best language going for just about everything that I do, for many of reasons ranging from all of the things that were right with previous Lisps to the many features of Lisp that Clojure improved and then also concurrency (I do some computationally intensive stuff) and the availability of the wide universe of java libraries. I realize that most of the current Clojure community *does* do development work that implies more immersion in the world that you're coming from (I recall seeing the survey that I think Chas conducted (?))... but as the community grows I think there will be more people like me looking for ways to write and run Clojure code.
I should also say that I'm not particularly wedded to applets per se. That's what Processing makes, so I thought it would be relatively simple to make applets from clj-processing. And they're fine for some of the things that I do, and they let me and my students show off our work and let others use some of our simple apps without requiring them to download and set up an IDE or to run things from a command line. It's possible that web deployment via something like Compojure would meet this kind of "make it go" need (and have other benefits besides), but I haven't taken that path yet because when I go to the Compojure getting started page the instructions are beautifully simple.... but based on lein. And I'm working in Eclipse/ccw, not knowing how to connect what I'm doing there to the lein way of doing things... which brings us back around to a much earlier stage of our discussion.
One more point: Running in the IDE or from a java command line is actually fine for many of the things that I do, and I CAN already do those things without build tools. FWIW for some of my work I've been writing code and doing test runs in Eclipse and then running from a command line on our cluster to do my real runs (with a very primitive shell script to start java processes on all of my nodes). So for this stuff I can already "make it go" without anything additional. But I can't make something that can be downloaded and double-clicked to run, or run in a browser (wherever the code actually runs -- for some of my projects I don't care), and it would be nice to do one or the other of those without intensive immersion in some new set of tools.
-Lee
Lee Spector
On Sep 22, 2010, at 3:42 PM, Laurent PETIT wrote:
>
That sounds nice but I don't think I care if it automatically infers what I want (and that might be messy), as long as it provides a straightforward way to choose what I want -- especially of one of the choices is something like "applet" or "simple compojure app" or something else that meets the needs I described in my previous message.
-Lee
Lee Spector
On Sep 22, 2010, at 4:36 PM, Chas Emerick wrote:
>>
>> I would agree that tools should remain orthogonal to the language. But that doesn't mean that there shouldn't be reasonably comprehensive (or at least "end-to-end for one common path") tools.
>
> The "one common path" is the difficult part to find/define/get people agree on.
I'm not suggesting that this be something that anyone has to agree on. Maybe I should have said "end-to-end for one possible path." I don't mean "one common path that everyone has to use" but rather "one preferably simple path that someone might conceivably want to use for end-to-end coding/deployment in some simple situation, and which newcomers might just be happy with if they don't have any specialized needs (and if they do then they can figure out what they should do differently later, but at least they'll know how one end-to-end path works, and what they need to fix, before they have to navigate those waters)."
> Web applications are arguably the most common type of software built in the Java ecosystem these days. For that, there is the whole .war artifact / servlet app container deployment process. That's a very, very well-worn path, supported well by every build tool....but, AFAICT, no IDE (hrm, maybe Oracle JDeveloper?) attempts to provide an end-to-end push-button process for that. The grails framework simplifies things to a large extent by simply defining a lot of the configuration by fiat (the oft-mentioned convention-over-configuration), but the deployment process is still likely nontrivial to a newcomer. NetBeans has a nifty deploy-to-server function (maybe only for Glassfish and Tomcat?), but quite simply *no one* would use it for more than fiddling and local development.
Well the IDE is indeed crucial for me. Or at least a few core features of an IDE, specifically language-aware indentation, a REPL, ease of setup and GUI access to most functionality (I know emacs and was working in that before Eclipse, but that's a bad road to go down for my teaching context), and (although I didn't realize this when I first started with Clojure) some kind of class path management.
The NetBeans function that you mention is intriguing, but if it's really as useless as you suggest then I guess it's not worth re-examining that option (which was my leading contender for a little while until I settled on ccw).
>
>>> Yes, we're in basic disagreement. At root of this, I think, is the question: "What does 'make it go' mean?". If you ask 100 programmers, you'll likely hear 250 responses. If you can find defaults given a situation like that, you've got yourself a goldmine.
>>
>> Isn't "produce an executable jar" a pretty decent default?
>
> No; I'd refer to Laurent's reply on this re: applets. "Executable" jars are a bit of a misnomer to begin with. Thick-client applications are almost uniformly deployed using either the NetBeans or Eclipse RCPs, or using launcher frameworks like jsmooth. Applets have been passed over by nearly everyone doing thin-client deployments, in favor of flash, flex, and now javascript + canvas.
As I replied to Laurent, I'd be happy with anything else in place of applets if there was an easy way to do it from within Eclipse, without learning too much other stuff. Whatever your favorite is, or somebody else's favorite is, or whatever is easiest to do. If it will let me deploy a simple application (let's say an interactive graphical version of hello world in which the graphics follow the mouse) in some straightforward way that doesn't require the user to set up Eclipse or use a command line, and preferably allows them to run the application in a browser, then I'd like to know about it.
> As you know from my post earlier today, we're in violent agreement on the fundamental point here. :-)
I hope it doesn't come to blows. You're bigger than me. But I know some AI Jiu Jitsu :-)
>
>>> To match up with your analogy, programmers are not simply novelists, but must further concern themselves with printing, binding, and channel distribution.
>>
>> I think that's a seriously suboptimal vision for the future! If Philip K Dick had to be an expert at binding for his novels to be published then the world would be a poorer place. I want to focus my energy on algorithms for evolutionary computation, figuring out the limits to quantum computing, using cognitive models to understand how we think and feel, and making algorithmic art. I know that part of the cost of entry now is to muck with development environments, but I think it'll be a better day when authors *don't* have to master the chemistry of ink in order to produce their novels.
>
> The analogy breaks down pretty quickly insofar as the physical manifestation of the novel has little to do with the effectiveness of the material it delivers. When you're in the context of providing scalable web services (for example), deployment and operational and security concerns are at the heart of one's architecture and development. The same is true (though to a lesser extent) when building thick-client applications that need to run effectively on multiple platforms, update themselves, provide remote usage statistics when possible, etc.
Fair enough, but I am *not* interested in providing scalable web services or building applications with the other features that you mention. If I were then I guess I would expect to have to learn about and use a bunch of the outside-of-Clojure and outside-of-the-IDE stuff that we've been discussing. But I'm not, and there will be others like me who aren't, and for us it'd be nice to have a simpler option of some sort. Even for those who *are* it'd probably be nice to have a simpler option to start with, from which they could deviate when it became clear that the simple option wouldn't scale sufficiently well or whatever else.
> But again, we're in fundamental agreement, and I suspect that goes way beyond build tooling and such. Maybe we'll come up with something sooner rather than later.
Hooray!
-Lee