自定义JHipster

Question

是否可以为组织定制/扩展JHipster？

由此，我的意思是拥有一个本地版本，可以创建一些具有特定于组织的功能的项目？例如，使用自定义身份验证方案（仍然依赖于Spring安全性），使用自定义样式（颜色，字体），添加某些Maven依赖项等等。

如果可以，可以在保留更新JHipster的可能性的同时更新JHipster不会覆盖这些扩展吗？

感谢。

Answer 1

以下是一般方法：

1. 首先，我们使用所有标准JHipster创建了一个空白项目 堆。使用的DBMS是Postgres。我们概述了基本数据结构 用jhipster实体生成工具，创造最重要的 我们还定义了基本的用户角色和权限 在标准的JHipster选项中。在这个阶段，我们没有付出很多 非常注重复杂的独特约束等细节， 业务限制，用户管理，JPA错误处理和 演示文稿等。刚开始创建一种主干。 CRUD页面都很标准。
2. 我们介绍了一些特定于域的业务逻辑。进行了基本的前端定制：品牌推广， 样式，一些自定义视图（仍广泛使用引导类）等.Jhipster生成的框架保持到位但扩展。我们在后端都稍微改变了授权逻辑 和前端，它是基于令牌的，具有某些令牌验证 规则。引入了用户友好的错误处理，允许用户使用 了解在各种条件下出现的业务限制。我们开始编写更复杂的单元测试来满足最近实现的业务逻辑。在这个阶段，实体大多是（~80％）手工制作，因为我们已经习惯了JHipster提供的数据结构，而且我们在CRUD REST控制器，页面和测试中有太多的自定义，涵盖了所有这些。使用liquibase：diff生成Liquibase更改日志并手动编辑。我们不会将此类实体添加到.jhipster文件夹中。
3. 由于对界面设计的要求越来越高且越来越严格，因此决定为最终用户交互引入单独的前端层。它部分地与jhipster生成的前端共享REST接口，但在项目结构方面完全独立。我们决定也将Angular用于新的前端层。实际上，它是一个具有单独的index.html，bower.json，Gruntfile.js等的子文件夹。同时我们继续改进业务逻辑，改进数据库结构，增加代码覆盖率，引入新的用户角色等。
4. ...

因此，我们为管理和数据管理目的提供了略微定制的“旧”JHipster前端。还有一个独立的“新”前端，采用定制设计来处理最终用户。 请注意：可以保留原始界面，将其自定义到某个限制并保留生成实体的可能性，并且只要合理，它在我们的项目中运行良好。

一些注意事项：

• pom.xml中的组件版本不断手动更新;
• 将maven依赖项手动添加到pom.xml;
• 将JS依赖项手动添加到index.html / bower.json / app.js;
• 如果您有复杂的前端脚本，那么处理生产配置文件的JS uglification可能会很棘手;
• 另一个困难的事情是保持liquibase脚本适用于spring-boot使用的DBMS和用于测试的H2;
• 根据特定于您项目的域逻辑，您可能会面临配置调优方面的一些问题。

我希望它有所帮助。

Answer 2

2.26.0版（2015年12月中旬）中引入的另一种方法是构建自己的模块，请参阅documentation。