Maven命名约定

有关groupId,artifactId和版本的命名约定指南

  • groupId 将在所有项目中唯一标识您的项目,所以我们需要强制执行一个命名模式。它必须遵循软件包名称规则,这意味着必须至少作为您控制的域名,并且您可以根据需要创建任意数量的子组。查看有关软件包名称的更多信息。
    例如。org.apache.maven,org.apache.commons

    确定groupId粒度的一种好方法是使用项目结构。也就是说,如果当前项目是多模块项目,它应该向父项的groupId附加一个新的标识符。

    例如。org.apache.maven,org.apache.maven.plugins,org.apache.maven.reporting

  • artifactId 是没有版本的jar名称。如果你创建了它,那么你可以选择任何你想要的名字,用小写字母和没有奇怪的符号。如果它是第三方jar,则必须在分发jar时使用它的名称。
    例如。maven,commons-math

  • 版本如果你分发它,那么你可以选择任何典型的版本号码和点(1.0,1.1,1.0.1,…)。不要使用日期,因为它们通常与SNAPSHOT(夜间)版本相关联。如果它是第三方神器,无论它是什么,都必须使用它们的版本号,并且看起来很奇怪。
    例如。2.0,2.0.1,1.3.1


官网原文

地址: https://maven.apache.org/guides/mini/guide-naming-conventions.html(Maven命名约定)

    Guide to naming conventions on groupId, artifactId and version
    groupId will identify your project uniquely across all projects, so we need to enforce a naming schema. It has to follow the package name rules, what means that has to be at least as a domain name you control, and you can create as many subgroups as you want. Look at More information about package names.
    eg. org.apache.maven, org.apache.commons

    A good way to determine the granularity of the groupId is to use the project structure. That is, if the current project is a multiple module project, it should append a new identifier to the parent's groupId.

    eg. org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting

    artifactId is the name of the jar without version. If you created it then you can choose whatever name you want with lowercase letters and no strange symbols. If it's a third party jar you have to take the name of the jar as it's distributed.
    eg. maven, commons-math

    version if you distribute it then you can choose any typical version with numbers and dots (1.0, 1.1, 1.0.1, ...). Don't use dates as they are usually associated with SNAPSHOT (nightly) builds. If it's a third party artifact, you have to use their version number whatever it is, and as strange as it can look.
    eg. 2.0, 2.0.1, 1.3.1

Maven命名约定

Maven约定前后端交互接口主要是通过遵循一些约定来定义和管理前后端接口的交互方式。以下是一些常见的约定: 1. 接口路径规范:在前后端分离的开发模式中,通常将前后端接口分别部署在不同的服务器上。为了方便管理和调用接口,可以约定前后端接口路径的命名规范,例如使用/rest作为接口的前缀。 2. 接口参数规范:定义前后端接口参数的命名规范和数据类型。可以使用驼峰命名法来命名参数,同时确保前后端参数的数据类型一致,例如使用字符串、整数、布尔值等。 3. 接口返回结果规范:约定前后端接口返回结果的数据结构和格式。可以使用JSON作为数据格式,定义统一的返回数据结构,包括状态码、消息和数据等字段。同时,可以使用枚举类型来定义一些常用的状态码,如成功、失败等。 4. 接口文档规范:使用工具或框架生成接口文档,方便前后端开发人员查阅和理解接口的定义和使用方式。可以通过注释、注解或配置文件等方式将接口信息生成文档,并提供给前后端开发人员进行参考。 5. 接口版本管理:随着项目的迭代和升级,接口可能会发生变化。为了防止接口的兼容性问题,可以使用版本管理机制,如在接口路径中添加版本号,或使用请求头来指定接口版本。 综上所述,Maven约定前后端交互接口是为了提高前后端开发效率和接口管理的一种规范约定方式。通过遵循这些约定,可以减少开发人员之间的沟通成本,提高开发效率,同时也方便后期维护和接口升级。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值