[spring-projects/spring-boot]Spring-CLI:“packageName”参数与文档不一致,并且不符合其他参数的命名约定

2024-06-26 33 views
0
重现步骤:
  1. 在命令行中运行spring init --list。控制台中会出现依赖项和参数列表:
    
    ..... 
    (omitted for brevity)
    ....

参数 +-------------+------------------------------------------+-------------------------------+ | Id | 描述 | 默认值 | +-------------+-------------------------------------------+-----------------------------------------------+ | artifactId | 项目坐标(推断存档名称) | demo | | bootVersion | spring boot 版本 | 2.5.1 | | description | 项目描述 | Spring Boot 的演示项目 | | groupId | 项目坐标 | com.example | | javaVersion | 语言级别 | 11 | | 语言 | 编程语言 | java | | 名称 | 项目名称(推断应用程序名称) | demo | | packageName | 根包 | com.example.demo | | 包装 | 项目包装 | jar | | 类型 | 项目类型 | maven-project | | 版本 | 项目版本 | 0.0.1-SNAPSHOT | +-------------+-------------------------------------------+-----------------------------------------------+


2. Using the suggested docs, try to run init a spring app with a custom package name, e.g. : 

spring init --packageName=com.skryvets.demo spring-demo


### Expected result:

Spring app should be created. The following (or similar output) should be produced in the console:

使用https://start.spring.io上的服务 项目提取到 '/yourfolder/spring-demo'



### Actual result:

Spring app creation fails with the following message: `packageName is not a recognized option`

### Notes:
The reason I put "doesn't fit the naming convention of other parameters" in the description as it seems like all other options are "camel cased" whereas this particular one is dash separated. There are 2 way of fixing - either changing the docs or parameter name. I felt like changing the parameter is more appropriate in this case.

回答

3

我之所以在描述中加上“不符合其他参数的命名约定”,是因为似乎所有其他选项都是“驼峰式命名”,而这个特定的选项是用破折号分隔的。

java-versionboot-version也采用驼峰式命名法以遵循 CLI 的惯例,尽管groupIdartifactId不采用驼峰式命名法,但这样有点奇怪。

如果您运行,spring help init您将看到如何构建命令(使用简写,即-p包名称或全名)。这里有点令人困惑的是,服务器会返回一些它支持的“参数”,主要用于告诉您默认值。

9

java-version、boot-version 也采用了驼峰式命名法以遵循 CLI 的约定,但 groupId 和 articulateId 却没有采用驼峰式命名法,这有点奇怪。

您完全正确。即使记住几个参数也可能会有帮助,但知道哪个参数应该使用驼峰命名法,哪个参数不应该使用驼峰命名法,会使使用起来更加困难(除非您查看文档)。

谈论文档和--package-name特定参数。我看到您提到了spring help init,运行后我看到它输出--package-name。但是,我还通过触发()仔细检查了来自服务器的内容curl --request GET --url https://start.spring.io/ --header 'Accept: application/json',我发现了嵌套的 camelCased packageNamejson 对象。

似乎最好的选择是将服务器上的驼峰命名改为以破折号分隔。但是,很明显,这可能会破坏一些现有的客户端/集成。另一种方法是将来自服务器的所有驼峰命名映射到 CLI 中的以破折号分隔的参数。

我会等待您的反馈。非常感谢您查看此内容。

6

但是,我还通过触发(curl --request GET --url https://start.spring.io/ --header 'Accept: application/json')仔细检查了来自服务器的内容,我发现了嵌套的 camelCased packageName json 对象。

这是一个提供 API 契约的完全不同的端点。

正如我在回复中提到的,服务器会返回一些它支持的“参数”,主要用于告诉您有关默认值的信息。这些参数并非旨在映射到您可以使用 Sping CLI 的实际选项。可以说,如果是这样,我们应该将它们写为--package-name。一种改进方法是将 Id 列更改为名称,使其更加明显。或者,我们确实可以更改服务器上的内容以显示实际选项。我已标记以引起团队注意,以便从团队获得更多反馈。

8

在发出项目创建请求时,代码将 CLI 选项(短横线命名)映射到查询参数(驼峰命名)。我认为在显示信息时,需要以另一种方式映射init --help。可能还值得过滤此信息,以便仅在 CLI 支持时才显示选项及其默认值。

我们可能还应该修复 CLI 选项,以便所有多词选项都有 kebab-case 变体。具体来说,--artifactId和应该分别由和--groupId连接。CLI 选项的 camelCase 变体应该被弃用。--artifact-id--group-id

6

嗨,团队,想检查一下这个问题是否仍然可以贡献?当前里程碑是否预计同时允许 CLI 选项(kebab-case)和查询参数(camelCase)还是仅支持 CLI 选项(kebab-case)?期待您的反馈。

2

是的。上面的评论总结了我们想要做的事情。我们不能在没有弃用期的情况下停止支持某个选项,所以是的,这两个 CLI 选项都应该有效。如果您愿意,您可以提交 PR,我们可以从那里指导您。

3

嗨@snicoll,非常感谢。我已经打开了 PR 28138。由于这是我的第一个问题修复,请您指导我是否还有其他我可以贡献的内容。期待您的反馈!

8

结束并赞成#28138。

9

你好 @wilkinsona,请提供问题/PR,以取代 #28138 的修复?非常感谢

6

@vignesh1992 #28138 尚未被取代。我们将关闭此问题以支持您的 PR。

5

嗨@philwebb,非常感谢您的回复。这是我第一次为这个 repo 做贡献,我很想知道关于 PR 的反馈以及发布时的下一步措施。

1

@vignesh1992 我们希望很快就能实现它。