Hi Dscho,<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">I also like the separation (obviously!).<br></blockquote>
<br>Great!<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
As to Maven: when I had to use it last time, it was very slow, but I am<br>
known to be impatient.<br></blockquote>
<br>Right, these full-featured build systems can be relatively slow when invoked from the command line. But they have amazing tools support, and integrate really well into IDEs. When developing with e.g. Eclipse, its incremental build feature is really fast and interactive, and you only need to invoke the Maven targets from the command line occasionally, so it's no big deal. And you can have a continuous integration system (e.g., Hudson) doing it on every commit for you, so you don't have to spend time testing it.<br>
<br>As usual for a command-line-based workflow with a text editor like vim or Emacs, there are many possible solutions, but not one "standard" one. Maybe it would make sense to get something like continuous background compilation working (e.g., <a href="http://chm.duquesne.free.fr/blog/?p=137">http://chm.duquesne.free.fr/blog/?p=137</a>). Or you can jump back to an IDE to check compile errors, then edit/fix in your editor of choice. Or for pure raw speed, you can set your classpath recursively to everything in ~/.m2, set :mak to run javac on the current file, and use an appropriate errorformat.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
I agree, though, that it solves an important problem: every source code<br>
repository of a non-trivial library seems to come with precompiled<br>
3rd-party components.</blockquote><div><br>Right, one of the great things is that you no longer have to keep all
these JAR files bogging down your SCM repository. Instead
you have a separate binary Maven repository intended for storing things
like JARs.<br><br></div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">And if you use several of such libraries, you may<br>
end up with different versions of the same 3rd-party component in the<br>
classpath. Not good (remember the JNA cleanup I did recently? That was<br>
_exactly_ that issue: jruby.jar's jna was hopelessly obsolete).<br></blockquote>
<br>*nod* With Maven the dependencies are all stated very explicitly and it is easy to check when this sort of thing starts happening. You can also easily ask Maven to check whether the declared dependencies match the actual ones (i.e., which projects import and use each other in practice).<br>
<br>Since we have not heard much from others, perhaps it would be easiest to get the imglib branches merged back together when I visit.<br><br>-Curtis<br><br><div class="gmail_quote">On Wed, Sep 29, 2010 at 7:52 PM, Johannes Schindelin <span dir="ltr"><<a href="mailto:Johannes.Schindelin@gmx.de" target="_blank">Johannes.Schindelin@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<div><br>
On Wed, 29 Sep 2010, Stephan Saalfeld wrote:<br>
<br>
> I like the separation and I am looking forward to check maven as a<br>
> builder. What about you, Steffi and Johannes?<br>
<br>
</div>I also like the separation (obviously!).<br>
<br>
As to Maven: when I had to use it last time, it was very slow, but I am<br>
known to be impatient.<br>
<br>
I agree, though, that it solves an important problem: every source code<br>
repository of a non-trivial library seems to come with precompiled<br>
3rd-party components. And if you use several of such libraries, you may<br>
end up with different versions of the same 3rd-party component in the<br>
classpath. Not good (remember the JNA cleanup I did recently? That was<br>
_exactly_ that issue: jruby.jar's jna was hopelessly obsolete).<br>
<br>
So I provided a script in Fiji (bin/maven.sh) which downloads and runs<br>
maven, exactly because it will be useful in the future.<br>
<br>
Ciao,<br>
Dscho<br>
<br>
P.S.: if you're interested why I made that script originally: I did it<br>
between when Albert mentioned that clojure-contrib is a Maven'ized Git<br>
repository now, and when Albert mentioned that clojure-contrib is no<br>
longer necessary for our Clojure stuff... ;-)<br>
<br>
</blockquote></div><br>