Jakarta EE中的规范范围

使用Eclipse Foundation Specification Process （EFSP），一个开放源代码规范项目就有一个专门的提交者项目团队来创建和维护一个或多个规范。创建和维护的周期跨越了该规范的多个版本，因此尽管各个成员可能来去去去，但团队仍然存在，由该团队负责创建的该规范的每个版本。

管理知识产权如何流经规范的第一步是定义规范所涵盖的工作范围。根据Eclipse 知识产权政策，需要很好地定义和捕获这一工作范围（称为作用域 ）。定义范围后，范围将被有效锁定（可以对范围进行更改，但很少更改，必须仔细管理；可以对规范的范围进行调整和更改，但这需要得到Jakarta EE工作组的规范委员会的批准）。

关于范围，EFSP声明：

除其他事项外，规范项目的范围旨在通知公司和个人，使他们可以确定是否对规范做出贡献。由于范围的改变可能会改变对项目的贡献的性质，因此对规格项目范围的改变必须得到规格委员会的绝大多数同意。

通常，范围声明不应太精确。相反，它应该广义地描述本说明书的意图。将范围声明视为执行摘要或“电梯提示”。

电梯间距：您的电梯门在地板上打开前有15秒钟的时间；告诉我您的规范所解决的问题。

作用域声明必须回答以下问题：该规范的实现有什么作用？范围声明必须是理想的，而不是试图在任何特定时间点捕获任何特定状态。范围声明不能只针对规范的任何特定版本计划的工作，而应定义规范旨在解决的问题空间。

例如：

Jakarta Batch提供了描述在Jakarta EE应用程序中执行和管理批处理过程的方法。

和：

Jakarta消息服务描述了Jakarta EE应用程序通过松散耦合的可靠异步通信服务创建，发送和接收消息的方法。

对于scope语句，可以假定读者对该领域有基本的了解。例如，期望读者理解“批处理”的含义是合理的。

我应该注意，上面介绍的两个示例只是形式的示例。我非常确定它们是有道理的，但是请项目团队与他们的社区合作以整理出最终形式。

在整个规范生命周期中，作用域都是“粘性”的：它涵盖了各个版本。任何特定开发周期的计划必须描述范围内的工作 ; 并且在检查点（进度和发布）审核中，项目团队必须准备证明规范描述（并通过相应的TCK测试）所描述的行为完全属于范围内（请注意，规范项目的开发生命周期为在Eclipse Foundation Specification Process分步指南中进行了介绍。

除了Eclipse知识产权政策和EFSP所要求的规范范围外，拥有并维护该规范的规范项目还需要一个项目范围 。我认为项目范围非常简单：特定的规范项目定义并维护了一个规范。

例如：

Jakarta Batch项目定义并维护Jakarta Batch规范和相关工件。

像规范范围一样，项目范围也应该是理想的。在这方面，规范项目永久负责特定的规范。另外相关的工件，如API和第三文化孩子可以在没有范围实际上是由该项目现在管理。

例如，今天，大多数针对Jakarta EE规范的TCK都已纳入Jakarta EE TCK项目。但是，随着时间的流逝，可能会分解单个怪兽TCK，并将各个TCK移至相应的规格项目。或不。关键是，无论当前在何处维护技术工件，它们有一天可能会成为规范项目的一部分，因此它们属于范围。

我应该备份一下，我们现在的意图是将我们管理着与各种规范相关的工件的“ Eclipse Project for ...”项目转变为实际的规范项目。作为这项工作的一部分，我们将Git存储库添加到这些项目中，以提供规范文档的目录（稍后将对此进行详细介绍）。目前，这些原型规范项目中有少数包含与多个规范相关的工件，因此我们必须理清对这些项目范围语句要做什么。

例如，我们可能会考虑将Jakarta EE Stable API的项目范围更改为简单的内容（请注意，我正在猜测将来的新项目名称）：

Jakarta EE稳定API提供了稳定的（旧式）Jakarta EE规范和相关工件的源头，这些规范和相关工件不再被积极开发。

但是，除了所有关于规范项目的讨论之外，我们的最初重点应该是描述规范本身的范围。考虑到这一点，EE4J PMC创建了一个项目委员会，其中包含一些问题来跟踪这项工作，我们将要求项目团队开始与他们的社区合作，将这些范围声明放在一起。如果您对特定规范的范围声明有任何想法，请权衡一下。

请注意，我们现在处于一种奇怪的状态。在我们努力重命名规范（以及相应的规范项目）时，尚不清楚我们应该称呼什么。您会注意到，已经创建的问题都使用了我们猜想最终将要使用的名称（有关“ 重命名Jakarta EE的Java EE规范”中的更多信息）。