Are the dependencies really OK?

[ctrueden]

Imagine someone wants to write an algorithm that operates on meshes in their code. They decide to use the Mesh interface, so they add a dependency on imglib2-mesh. Now, due to the fact that the mesh algorithms and file I/O routines are lumped in here, they inherit dependencies on:

• Trove – used by MeshConnectedComponents and MeshCursor
• SciJava Common – used by PLY and STL and XYZ and naive mesh—although as I said elsewhere I think we can get rid of this SJC dependency with minimal effort
• Apache Commons Math – used by marching cubes, for the Vector3D
• Guava – used by STL support, solely for the Strings.padEnd function
• jPLY – used by PLY support—-and it in turn depends on Apache Commons Lang

None of these dependencies are required for the core data structures to be functional—only for specific algorithms or file formats.

We could easily modularize this into multiple components with distinct dependencies, so that consumers can choose to depend only on what they need.

Once #1 and #2 are merged, I can file a PR getting rid of the Guava and SJC dependencies. I can also look at how feasible it would be to pull the Vector3D out of Apache Commons Math, so that we can purge that dependency as well.

But that still leaves Trove and jPLY... are we OK with this footprint?

[tinevez]

Yes that would be fantastic. jPLY we clearly cannot do without. Trove is no big deal.

I also saw your comments about the sorting routines, for which we could go to fastutils. I understand that it is a large dependency, but it ships a routine made and maintained by others, more competent. I would be in favor of including fastutil, but only when we meet issues with the interior test, later.

[ctrueden]

I am working on paring down the dependencies. Got rid of Guava no problem. I forked Vector3D into the codebase, but then when compile-testing I found that net.imglib2.mesh.alg.EllipsoidFitter and net.imglib2.mesh.alg.InertiaTensor use also the org.apache.commons.math3.linear package. So I'm going to leave the commons-math3 dependency for now.