[ImageJ-devel] [IMGLIB] moved algorithm and stats packages out of imglib2-core

[Curtis Rueden]

Hi Tobias,

I moved the net.imglib2.algorithm and net.imglib2.stats packages
> from the imglib2-core into the imglib2-algorithms sub-project (because
> thats where they should belong.)
>

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.

So, there are a couple of potential solutions:

1) Keep things like net.imglib2.stats in imglib2 core, so that it can
remain BSD licensed.

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.

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.

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.

Maybe it is time to split up imglib2-algorithms into multiple submodules? I
would be happy to do it, if we all agree.

Regards,
Curtis


On Wed, Feb 29, 2012 at 1:11 PM, Tobias Pietzsch <pietzsch at mpi-cbg.de>wrote:

> Hi all,
>
> I moved the net.imglib2.algorithm and net.imglib2.stats packages
> from the imglib2-core into the imglib2-algorithms sub-project (because
> thats where they should belong.)
>
> With regard to the interfaces and classes from the algorithm package,
> I think we should reconsider whether we need those at all. In particular
> for the MultiThreaded interface, I imagine that something similar can
> be accomplished using the standard java.util.concurrent package.
> For instance, (potentially) multi-threaded algorithms could be started
> with an ExecutorService argument.
>
> best regards,
> Tobias
>
> ______________________________**_________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/**listinfo/imagej-devel<http://imagej.net/mailman/listinfo/imagej-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120229/9cc82aae/attachment.html>