In my opinion those 'repetitive' packages are not a problem. They are just packages after all. The developer that works with your API only only sees them.
Also it's not necessarily a problem that the developer can access your implementation classes. It's the same with Java itself: There are a lot of com.sun classes that can be used but that doesn't mean that you should. It makes porting to another Java runtime difficult.
It also depends a bit on the project. If you work with an architecture that cleanly separates the API from the implementation, the user of your API can't access the implementation. OSGi and Web services come to mind. In this case you can create two different libraries: the implementation and the API with the implementation depending on the API. The API contains all classes that are important for external users. That way separation is quite easy.
The third problem doesn't really exist. You can have different libraries that provide classes for the same packages. As long as you control the namespace and don't have duplicate classes in the same package everything is fine. A package is just a name, nothing else.
我在两个项目中使用相同的包名称。这两个项目构建为两个不同的 jar，并且 api jar 提供给需要访问（或编写插件）我的应用程序/系统的客户/开发人员。这些 jar 通常被命名为 myapplication.jar 和 myapplication_api.jar
I usually create two different (eclipse) projects for these kind of scenarios. One project contains the core, and that other project contains the api/interface-classes. The core project is dependent on the api project.
I use the same package names in both projects. The two projects are built to two different jars, and the api jar is given to the clients / developers who need to access (or write plugins) for my application/system. The jars are usually named e.g. myapplication.jar and myapplication_api.jar
发布评论
评论（2）
在我看来，那些“重复”的包不是问题。毕竟它们只是包裹。使用您的 API 的开发人员只能看到它们。
此外，开发人员可以访问您的实现类也不一定是问题。 Java 本身也是如此：有很多 com.sun 类可以使用，但这并不意味着您应该使用。它使得移植到另一个 Java 运行时变得困难。
这也有点取决于项目。如果您使用的架构将 API 与实现完全分离，则 API 的用户将无法访问实现。我想到了 OSGi 和 Web 服务。在这种情况下，您可以创建两个不同的库：实现和 API，其中实现取决于 API。 API 包含对外部用户重要的所有类。这样分离就很容易了。
第三个问题其实并不存在。您可以使用不同的库为相同的包提供类。只要您控制命名空间并且同一包中没有重复的类，一切都很好。包只是一个名称，没有别的。
In my opinion those 'repetitive' packages are not a problem. They are just packages after all. The developer that works with your API only only sees them.
Also it's not necessarily a problem that the developer can access your implementation classes. It's the same with Java itself: There are a lot of
com.sunclasses that can be used but that doesn't mean that you should. It makes porting to another Java runtime difficult.It also depends a bit on the project. If you work with an architecture that cleanly separates the API from the implementation, the user of your API can't access the implementation. OSGi and Web services come to mind. In this case you can create two different libraries: the implementation and the API with the implementation depending on the API. The API contains all classes that are important for external users. That way separation is quite easy.
The third problem doesn't really exist. You can have different libraries that provide classes for the same packages. As long as you control the namespace and don't have duplicate classes in the same package everything is fine. A package is just a name, nothing else.
我通常为此类场景创建两个不同的（eclipse）项目。一个项目包含核心，另一个项目包含 api/接口类。核心项目依赖于api项目。
我在两个项目中使用相同的包名称。这两个项目构建为两个不同的 jar，并且 api jar 提供给需要访问（或编写插件）我的应用程序/系统的客户/开发人员。这些 jar 通常被命名为 myapplication.jar 和 myapplication_api.jar
I usually create two different (eclipse) projects for these kind of scenarios. One project contains the core, and that other project contains the api/interface-classes. The core project is dependent on the api project.
I use the same package names in both projects. The two projects are built to two different jars, and the api jar is given to the clients / developers who need to access (or write plugins) for my application/system. The jars are usually named e.g. myapplication.jar and myapplication_api.jar