V2EX › iseki 的所有回复 › 第 12 页 / 共 54 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 8 9 10 11 12 13 14 15 16 17 ... 54

❮

❯

2024 年 6 月 21 日

回复了 diagnostics 创建的主题 › Java › 有多少人还在用 Maven 构建项目？

@diagnostics 我只有一个迫不得已用 Maven 的项目用了 Maven ，那是因为目标平台用了 OSGi ，相关构建插件在 Gradle 中非常不成熟。我观测的也是，Maven 在构建和配置缓存的利用上非常不优化，我不确定 Maven 平台有没有提供这种能力。
Gradle 的一个大问题在于冷启动实在是太慢了，如果使用了 buildSrc (aka. convention precompiled plugin) 问题就更加严重，偏偏官方鼓励使用这个···

2024 年 6 月 21 日

回复了 diagnostics 创建的主题 › Java › 有多少人还在用 Maven 构建项目？

此外就是考虑到 Kotlin 这种编译比较缓慢的语言，我在实践中倾向于让每一个模块保持很小的体积，同时让依赖树尽量扁平，这样，IDE 更流畅，Gradle 自身的并发执行任务的能力也对我有很大帮助。

2024 年 6 月 21 日

回复了 diagnostics 创建的主题 › Java › 有多少人还在用 Maven 构建项目？

@31415926535x 模块之间的紧密度，在切分仓库和单一模块之间还有一个层级，这个层级刚好使用 Maven 的多模块和 Gradle 的多 Project 能力处理。每一个“模块”是一个编译单元，有时候编译单元的切分是必须的。
一般来说一个稍微复杂点的可扩展功能就必须切分为至少两个模块，模型与实现，比如一个叫 xxx-api 另一个叫 xxx-core 之类的。这时，两个模块都会被存储到制品仓库（比如 Maven Central ），而扩展模块只需要依赖 xxx-api 即可。

2024 年 6 月 20 日

回复了 diagnostics 创建的主题 › Java › 有多少人还在用 Maven 构建项目？

@31415926535x 多个版本库之间管理是额外的成本，git submodule 并不好用，特别是模块间关系紧密，连版本号都完全统一时。

2024 年 6 月 20 日

回复了 diagnostics 创建的主题 › Java › 有多少人还在用 Maven 构建项目？

@zhenjiachen Gradle 主要是冷启动比较慢，很大程度上这还是 Kotlin 导致的（因为要编译 kts 脚本和 buildSrc ，Kotlin 编译慢的离谱），后续的话，任务缓存和 daemon 等等机制理论上是非常高效的

2024 年 6 月 20 日

回复了 diagnostics 创建的主题 › Java › 有多少人还在用 Maven 构建项目？

@duanluan

> 2. 需要换个插件，description 、scm.url 等必填，不再支持快照版本。

破坏掉兼容性这一点太令人难以接受了，好在应该在未来相当一段时间旧的设施仍然可以使用。

2024 年 6 月 20 日

回复了 diagnostics 创建的主题 › Java › 有多少人还在用 Maven 构建项目？

@codingmiao 这个我倒是没有遇到过，Gradle 因为 API 经常不兼容，所以基本上都通过 wrapper 强行指定版本了······反而是 Maven 因为没这个问题，被人用上古版本炸过。

2024 年 6 月 20 日

回复了 diagnostics 创建的主题 › Java › 有多少人还在用 Maven 构建项目？

@duanluan 这是个大问题，此外新的仓库格式和协议是开放的吗，之前只看到了新的仓库，没想到这个他们也要改，这可改不得啊

2024 年 6 月 20 日

回复了 diagnostics 创建的主题 › Java › 有多少人还在用 Maven 构建项目？

我这边的需要灵活的定制构建流程，中间还杂糅了其他语言的构建打包··· Maven 插件我不会写，Gradle 用着还算凑合，虽然也有许多不尽如人意的地方

2024 年 6 月 17 日

回复了 iseki 创建的主题 › 全球工单系统 › 望京东能优化下自己的业务逻辑

那起码要为商家再次寄出准备好新的虚拟号吧🥺😣

2024 年 6 月 7 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

@iseki 从认证这个业务逻辑上当然不需要获取原始口令，也不该这么做

2024 年 6 月 6 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

@lesismal 按这种讲法就没什么可讨论的了。一切当然是可以改的，就算是碰到必须获取原始口令的设施你也可以说改造旧设施，那还有什么可说的呢。

2024 年 5 月 31 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

不是，举个例子 LDAP 登录，这是很常见的需求。业务逻辑是尝试使用搜索到的 DN 和用户提供的口令 Bind ，Bind 成功即为认证成功，这就必须把用户输入的原始口令发送过去。

2024 年 5 月 29 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

@lesismal 明文向后端传输虽然不好，但有时这是工程上成本刚好可以接受的方式。一来我刚才说了，很难设计一个有足够收益的非明文传输方案，二来就是有时候后端的某些设施只能接受明文。

2024 年 5 月 24 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

@lesismal 工程上多一行代码也是有成本的，不能做不划算的事。我可以接受口令在妥善的哈希后传递给后端，但我不能接受把口令 base64 之后传给后端，base64 在这里就是一个收益近乎为 0 的操作（即使它的成本很低），总结下来就是一句话，不做不必要的事。
避免向后端传递原始口令是有必要的（中间设施，日志系统，甚至后端服务本身都可以有缺陷和风险），但必须弄清该怎么做，而不是简单变换一下弄得一眼看不出来就完了。

2024 年 5 月 24 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

@lesismal 这文本复制的可真有意思，也怪我，下次用 Kotlin 风格的方式表达。
这个接口的风格是工程要求，你也可以看一下我在这条文本之后的跟帖，大概有这么个现实问题是不太好解决的，你可以给出你的解决方案讨论一下。

2024 年 5 月 24 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

也许可以在前端对口令完成一次困难哈希，但难度和风险在于这个哈希的算法和参数从此固定不能更改，也意味着日后所有的「客户端」都要能自主完成这套逻辑。

2024 年 5 月 24 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

此外再提及一点，许多密码基础设施提供的验证接口形如 verify(password, stored_credential) -> ok?，这里虽然没有明说（实际上也不可能要求） password 必须是用户的原始主口令，但一般确实可能影响到实践。

2024 年 5 月 24 日

回复了 lesismal 创建的主题 › 程序员 › HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

单从避免用户主口令泄露这件事上来说，要做一个可靠的方案成本比较高，前后端可能会有超过一个 RTT 的挑战响应机制。比如后端存储用用户主口令加密过的私钥，然后在用户代理（浏览器）中完成挑战响应，这样可以保证用户主口令不离开用户代理。
如果前端简单哈希一下，暂且不论能否提高安全性（加盐会很难做，固定的盐没有意义），哈希后的结果会不会缩减值空间，反过来降低安全性，可能也有待评估。

1 ... 8 9 10 11 12 13 14 15 16 17 ... 54

❮

❯