Hi Tobias,<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 moved the net.imglib2.algorithm and net.imglib2.stats packages<br>
from the imglib2-core into the imglib2-algorithms sub-project (because<br>
thats where they should belong.)<br></blockquote>
<br>The problem with moving things from core to algorithms right now is that implicitly, it changes the license from BSD to GPL. ImageJ2 cannot include imglib2-algorithms, because of this license difference.<br><br>So, there are a couple of potential solutions:<br>
<br>1) Keep things like net.imglib2.stats in imglib2 core, so that it can remain BSD licensed.<br><br>2) Split imglib2-algorithms into multiple components: imglib2-algorithms-bsd and imglib2-algorithms-gpl, for example. Then we can include imglib2-algorithms-bsd as a dependency for ImageJ2.<br>
<br>The thinking with net.imglib2.stats was that the histogram functionality is so common that it belongs in the "core" library. While modularity is nice, splitting things up too much runs the risk of confusing new developers who do not know why there are so many different JAR files. I agree with something Albert said a while back that one primary motivator for multiple JARs is to discriminate dependencies. That is, if some code depends on e.g. weka, and other code does not, there should be two Maven modules: one with a dependency on weka that includes the relevant code, and the other without such dependency that includes the rest.<br>
<br>The tricky bit is, the other primary motivator for multiple JARs is, as touched on above, licensing. We need to balance and reconcile those two needs. The most surefire solution is to have a separate module/JAR for each combination of licenses and dependencies—and hopefully that number of modules remains manageable.<br>
<br>Maybe it is time to split up imglib2-algorithms into multiple submodules? I would be happy to do it, if we all agree.<br><br>Regards,<br>Curtis<br><br><br><div class="gmail_quote">On Wed, Feb 29, 2012 at 1:11 PM, Tobias Pietzsch <span dir="ltr"><<a href="mailto:pietzsch@mpi-cbg.de">pietzsch@mpi-cbg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I moved the net.imglib2.algorithm and net.imglib2.stats packages<br>
from the imglib2-core into the imglib2-algorithms sub-project (because<br>
thats where they should belong.)<br>
<br>
With regard to the interfaces and classes from the algorithm package,<br>
I think we should reconsider whether we need those at all. In particular<br>
for the MultiThreaded interface, I imagine that something similar can<br>
be accomplished using the standard java.util.concurrent package.<br>
For instance, (potentially) multi-threaded algorithms could be started<br>
with an ExecutorService argument.<br>
<br>
best regards,<br>
Tobias<br>
<br>
______________________________<u></u>_________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net" target="_blank">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/<u></u>listinfo/imagej-devel</a><br>
</blockquote></div><br>