Reshuffle packages. - Githubissues

This PR has two goals:

It aims at integrating the 'revised' package into a sensible package hierarchy.
It aims at decoupling the generic Mastodon interfaces and mother classes from the Mamut classes that implement them, and are specific to a runnable application.

Here is the logic for the second point. In this repo you will find 1) Mastodon base classes and 2) the classes for the MaMuT application.

Mastodon base classes.

There are base classes and interfaces to derive and implement to create an application (or 'app') specific to a topic. What we call 'topic' could be 'segment, track and lineage cells objects in 2D'. The name of these classes is normally prefixed with MastodonSomething.

These classes are like abstract classes. By themselves, they cannot be made to something an end-user can run. The core classes of an app would derive a model for instance from a org.mastodon.app.MastodonAppModel and derive an org.mastodon.model.AbstractSpot to store location of objects.

The MaMuT application.

These classes are part of an app, whose topic is 'tracking and lineaging cells, with cells represented as ellipsoids'.

This app is the final and central application of Mastodon. When end-users and us speak of Mastodon, we mean this one. It is based on the org.mastodon.mamut.importer.Model and on org.mastodon.mamut.importer.Spot.

Because this app is the successor of the MaMuT project (Wolff, Tinevez, Pietzsch et al, 2018) the classes of this app are called MaMuTSomething.

With this commit:

They are all located in the org.mastodon.mamut package.
None of the Mastodon base classes depend on these classes.

To achieve the last point, I had to move many classes around, and introduce some specific interface hierarchy. For instance, there is now a package org.mastodon.app.plugin, that defines interfaces for a generic plugin system, and that is implemented for the MaMuT app in org.mastodon.mamut.plugin.

mastodon-sc / mastodon

Reshuffle packages. #121