[ImageJ-devel] Imglib project organization & Bio-Formats support

[Curtis Rueden]

Hi Dscho,

I also like the separation (obviously!).
>

Great!

As to Maven: when I had to use it last time, it was very slow, but I am
> known to be impatient.
>

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.

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., http://chm.duquesne.free.fr/blog/?p=137). 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.

I agree, though, that it solves an important problem: every source code
> repository of a non-trivial library seems to come with precompiled
> 3rd-party components.


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.

And if you use several of such libraries, you may
> end up with different versions of the same 3rd-party component in the
> classpath. Not good (remember the JNA cleanup I did recently? That was
> _exactly_ that issue: jruby.jar's jna was hopelessly obsolete).
>

*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).

Since we have not heard much from others, perhaps it would be easiest to get
the imglib branches merged back together when I visit.

-Curtis

On Wed, Sep 29, 2010 at 7:52 PM, Johannes Schindelin <
Johannes.Schindelin at gmx.de> wrote:

> Hi,
>
> On Wed, 29 Sep 2010, Stephan Saalfeld wrote:
>
> > I like the separation and I am looking forward to check maven as a
> > builder.  What about you, Steffi and Johannes?
>
> I also like the separation (obviously!).
>
> As to Maven: when I had to use it last time, it was very slow, but I am
> known to be impatient.
>
> I agree, though, that it solves an important problem: every source code
> repository of a non-trivial library seems to come with precompiled
> 3rd-party components. And if you use several of such libraries, you may
> end up with different versions of the same 3rd-party component in the
> classpath. Not good (remember the JNA cleanup I did recently? That was
> _exactly_ that issue: jruby.jar's jna was hopelessly obsolete).
>
> So I provided a script in Fiji (bin/maven.sh) which downloads and runs
> maven, exactly because it will be useful in the future.
>
> Ciao,
> Dscho
>
> P.S.: if you're interested why I made that script originally: I did it
> between when Albert mentioned that clojure-contrib is a Maven'ized Git
> repository now, and when Albert mentioned that clojure-contrib is no
> longer necessary for our Clojure stuff... ;-)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20101011/ad936f69/attachment.html>