这篇博文最初发表于卢森堡的a talk at the ImageJ conference 2012。
＃＃ 介绍
似乎许多与Fiji相关的项目的名称都附有“2”…TrakEM2、ImgLib2、ImageJ2。为了不被抛在后面，斐济也会做同样的事情：斐济的下一个大版本将是 Fiji2 :-)
此外，选择“Fiji2”还有一个很好的技术理由。从一开始，Fiji 就致力于让 ImageJ 的使用变得更轻松——无论是对开发者还是用户来说。特别是对于开发人员来说，我们希望拥有一个良好的基础设施来帮助更快地开发更好的插件。作为其中的一部分，我们不仅探索了新的开发技术，例如使用 source code management tool，而且还致力于打造更灵活的核心。
作为示例，我们提供了一种运行某些插件的方法without a graphical desktop。不过，由于 ImageJ 1.x 的设计，这种“无头”模式只能适用于插件的子集。 Fiji 还开始解决 ImageJ 1.x 的其他问题，例如缺少 updater、强大的 editor for macros and scripts 或扩展点，例如添加新工具（ImageJ 1.46d 添加了 Fiji AbstractTool 框架的有限版本）。
令人高兴的是，这些和其他设计限制在下一代 ImageJ 中得到了解决！
ImageJ2
ImageJ2（感谢 NIH 的资助）提供了一种新的、模块化的、灵活的架构，它将在未来几十年为我们提供良好的服务。 Fiji 开始回馈模块，例如强大的数据处理库 ImgLib2、更新器和脚本编辑器，并且可以再次专注于生命科学，这是它最初的目的。与 Fiji 一样，ImageJ2 尽可能地迎合庞大且充满活力的 ImageJ 社区，默认用户界面看起来几乎与 ImageJ 1.x 的用户界面一模一样，这证明了这一点：
ImageJ2 screenshot
模块化架构
但在底层，ImageJ2 更加模块化。这也是我们斐济所需要的。作为示例，让我们看一下 Fiji 模块的子集：
Modules in Fiji
在此图表中，深蓝色框表示斐济的三个插件，浅蓝色框表示与斐济相关的三个项目，灰色框代表在斐济背景下使用但未积极开发的第三方项目。箭头显示“贡献功能”的关系。
显然，许多所描述的组件与其他组件共享它们的依赖关系。例如，3D Viewer和TrakEM2都依赖于ImgLib2。现在，ImageJ 1.x（以及许多为其编写的插件）试图避免这种依赖关系，因为强迫用户跟踪它们是不方便的。对于开发人员来说，缺点是他们必须再次实现与其他人提供的相同的功能。因此，这种支持通常是不完整的，有时错误会在代码中隐藏多年。
但在斐济，我们有 updater，这使得开发人员和用户都可以轻松地管理许多依赖项。
在通往 Fiji2 的道路上，我们还采用了 ImageJ2 对 Maven 的使用，它基本上是开发人员的更新程序，因为它可以轻松跟踪依赖项的不同版本并检查其源代码。它也优于以前的方法（Fiji Build System），后者不允许集成到许多可用的开发人员工具（例如Eclipse）中。
这种模块化架构使我们能够轻松集成许多第三方组件，例如机器学习库、数据库库、读/写 PDF 文件的库、强大的Bio-Formats 和SCIFIO 库等。
自动化测试
Fiji2 道路上另一个非常重要的一步是迁移到 ImageJ2 的组件配备了自动回归测试。也就是说，每次开发人员进行一些更改时，ImageJ2 的可信服务器 (Jenkins) 都会运行一系列函数来测试某些功能。每当这些测试出现问题时，开发人员都会收到通知，并可以在将相应组件上传到更新站点之前修复损坏的问题。
此过程帮助我们确保错误一旦修复，就不会再次出现。这也将使斐济对用户来说更加友好，因为他们不需要报告那么多错误，因为他们甚至不会看到它们。开发人员也可以运行这些测试，以便在更改到达服务器之前进行测试。在理想情况下，一切都是绿色的：
Automated regression testing
重复任务
使用 ImageJ2 的 Jenkins 还有更多好处：除了构建完整的 Fiji 和运行自动回归测试之外，Jenkins 还可以运行各种重复作业。其中一项工作保留最新的斐济版本并将其打包到我们所说的continuous releases中。
Continuous Fiji releases
其他任务涉及我们所有支持平台的keeping our source code repositories in sync、building the ImageJ launcher、密切关注 ImageJ 1.x 网站、deploying it as a Mavenized project 和 uploading the new ImageJ 1.x version to the update site immediately（从而确保每个 Fiji/ImageJ2 用户始终受益于最新的 ImageJ 1.x 版本）等。
项目管理
Fiji2 可能采用的开发工具（也受到 ImageJ2 的启发）是将其拆分为里程碑，而里程碑又拆分为目标（目标又拆分为单个任务），从而实现manage the project。它可以更轻松地组织和确定必须完成的事情的优先顺序。就像自动测试一样，它是ImageJ2开放过程的一部分：
ImageJ2 Project Management
斐济 vs 斐济2
下图最能说明 Fiji2 将发生的变化：
Fiji will become Fiji2
在子图 a 中显示了现状：斐济严重依赖 ImageJ 并贡献了 ImgLib2 和 ImageJ2 的更新程序。在子图 b 中，您可以看到未来：斐济将严重依赖 ImageJ2 来提供强大的核心以及可以运行任何现有 ImageJ 1.x 插件和宏的遗留模式。 ImageJ2 的所有改进，包括对源自斐济的组件的改进，都将使所有 ImageJ 用户受益。
到目前为止，我们已经集成了更新程序：
ImageJ2 updater
我们还集成了脚本编辑器的第一个版本，利用这个机会从头开始重新设计脚本基础架构：
ImageJ2 Script Editor
为了准备最终迁移到 Fiji2（默认情况下将打开 ImageJ2 的 GUI），我们将提供一个在 ImageJ2 和旧模式之间切换的命令。在 Fiji2 之前，默认用户界面仍为 ImageJ 1.x。
ImageJ2 legacy mode
这对你来说意味着什么？
除了通过 ImageJ2 的遗留模式完全支持 ImageJ 1.x 之外，Fiji 还将受益于 ImageJ2 的灵活设计。
由于 ImageJ2 插件基本上可以在任何地方运行（设计目标之一），因此越来越多的开发人员（甚至在 ImageJ 社区之外）可能会发现将他们的代码作为 ImageJ2 插件提供很有吸引力。
通过 NIH 的资助，ImageJ2 将为斐济提供强大、可靠和稳定的核心。
由于不再需要担心基础设施问题，斐济开发人员将能够更多地关注生命科学中的图像分析。
最终用户也将受益于更加模块化的方法：只需单击一下即可告诉 ImageJ 更新程序从预配置的更新站点列表中安装/更新。
