25

Is it be possible to customize/extend JHipster for an organization ?

By that, I mean having a local version that creates some projects with features that are specific to an organization ? For example, using a custom authentication scheme (that still relies on Spring security), using custom styles (colors, fonts), adding certain Maven dependencies and so on.

If this is possible, can it be done while retaining the possibility to update JHipster in such a way that an update of JHipster would not overwrite these extensions ?

Thanks.

ccc
  • 2,129
  • 4
  • 24
  • 31
  • 1
    Yes, this is possible, and it perfectly matches the project I am currently involved in. But detailed answer depends on what do you want from JHipster. It is a great tool for quick start, but we don't use JHipster itself in a full-grown application development. Just occasionally for fast entity creation. – dfche Dec 01 '15 at 22:28
  • 1
    @dftche: Well, that's exactly what I am thinking of: using JHipster for scaffolding: create the base structure, CRUD pages and entities. After that, continue with normal development, meaning implementing business logic, integrating with other apps and so on. Could you please share with me how exactly you're customising and using JHipster ? Would be greatly appreciated. Thanks. If you do, answer the question, rather than commenting, so I can give you credit for solving it. – ccc Dec 03 '15 at 00:03

2 Answers2

26

Here's the approach in general:

  1. First, we created a blank project with all standard JHipster stack. DBMS used is Postgres. We outlined the basic data structure with jhipster entity generation tool, creating the most important relations etc. We also defined the basic user roles and permissions within standard JHipster options. At this phase we didn't pay very much attention to the details such as complex unique constraints, business restrictions, user management, JPA errors handling and presentation etc. Just created a sort of backbone to start with. CRUD pages are all standart.
  2. We introduced some domain-specific business logic. Basic frontend customization was performed: branding, styles, some custom views (still used bootstrap classes extensively) etc. Jhipster-generated frame was kept in place but extended. We changed authorization logic a little bit on both backend and frontend, it's token-based with certain token validation rules. User-friendly error handling was introduced, allowing user to understand what business restrictions show up in various conditions. We started to write more complex unit tests to meet the business logic implemented recently. Entities are mostly (~80%) crafted manually at this stage, because we got used to the data structure offered by JHipster, and we had too much customization in CRUD REST controllers, pages and tests covering all that. Liquibase changelogs were generated with liquibase:diff and edited manually. We don't add such entities to .jhipster folder.
  3. Because of demands for interface design growing high and strict, it was decided to introduce separate frontend layer for end-user interaction. It partially shares REST interfaces with jhipster-generated frontend, but is absolutely independent in terms of project structure. We decided to use Angular for new frontend layer as well. In fact, it is a subfolder with separate index.html, bower.json, Gruntfile.js etc. At the same time we continued to improve business logic, refine db structure, increase code coverage, introduce new user roles etc.
  4. ...

So we have slightly customized "old" JHipster frontend for administration and data mangement purposes. And an independent "new" frontend with custom design to deal with end users. Please note: it IS possible to keep an original interface, customize it to some limit and preserve the possibility to generate entities, and it worked well in our project as far as it was justified.

Some notes:

  • Component versions in pom.xml were constantly updated by hand;
  • Maven dependencies were manually added to pom.xml;
  • JS dependencies were manually added to index.html/bower.json/app.js;
  • If you have complex frontend scripting, dealing with JS uglification for production profile may be tricky;
  • Another difficult thing is to keep liquibase scripts working for both DBMS used by spring-boot and H2 which is used for tests;
  • You'll probably face some problems with configuration tuning depending on domain logic specific for your project.

I hope it helps.

dfche
  • 3,403
  • 2
  • 24
  • 32
  • Thanks for the extensive reply. However, what you're describing is more or less what I am in the process of doing myself. I upvoted you answer, but can't mark the issue as solved because my question was related to customizing JHipster itself, meaning customizing the scaffolding generator. So when you use it to generate a new project, you have another start page, with some custom CSS, custom security and so on. Reason: if using JHipster to create multiple projects in a company, you won't waste time to change styling/branding in each, but have them already in the code generated by JHipster. – ccc Dec 09 '15 at 09:28
  • 1
    Oops, got you wrong. I have had a brief look into jhipster sources, and I think it's possible to customize it to your needs after cloning it (https://github.com/jhipster/generator-jhipster/blob/master/CONTRIBUTING.md#-generator-development-setup) – dfche Dec 09 '15 at 10:28
  • 1
    That's what I meant. However, I doubt many companies would want their generator in the public domain, so my full problem was: 1) customizing the sources of JHipster (I figured should be possible -this should be the easiest part, really); 2) hosting this customized JHipster on the internal network of a company, 3) while also ideally being able to update the code when JHipster is updated; continued .... – ccc Dec 10 '15 at 10:50
  • 1
    .... 4) making it possible for developers inside the company's network to side-load the customized version of JHipster via their locally installed npm. Today JH is installed via: npm install -g generator-jhipster, but I don't know if you can tell npm to load stuff from other repositories. I am quite new to npm, yeoman and this entire stack. Out of all these, I see 3 as nearly impossible, and 4 the most difficult of the rest. continued .... – ccc Dec 10 '15 at 10:53
  • 1
    ... But even if 3 can't be automated, if 1, 2 and 4 can be achieved, I think it would be a great thing, and it could simplify a lot the process of starting new projects in a company, especially one that develops a bunch of internal applications at the same time (instead of a mammoth one). In any case, thank you for the answers. I will mark your reply as the solution. And I should probably find the time to dig into the sources myself :) I find the project fascinating, especially because I dreamed of something like this for at least 2-3 years, but was too lazy to start implementing it myself. – ccc Dec 10 '15 at 10:56
  • 1
    Hope you'll arrange your workflow successfully. I'm also quite new to npm, so I cannot bring the details. Just found a couple of links related to local npm repos, may be this can help https://www.npmjs.com/package/sinopia Including JHipster updates in a local copy will require manual merge, I assume. And I do agree with you about JHipster in general, great project with responsive community! – dfche Dec 10 '15 at 11:35
  • Great find. On a first look, it seems to be exactly what I was looking for. Thanks again. – ccc Dec 10 '15 at 15:24
  • @dfche I'm considering something along the lines of your approach, especially since your (3) makes sense if the public UX is not shared by the JHipster UI itself. Did you end up creating a separate Maven module that depends upon the generated JHipster module? – Alan Aug 07 '17 at 18:06
  • @Alan you are right about this: "the public UX is not shared by the JHipster UI itself" But we didn't have a separate Maven module for public UI, just a separate folder in src/main/webapp with a JS frontend setup (bower and grunt config etc.) totally independent from JHipster-based frontend app. The backend is not divided in ancillary/public parts. A sole backend application interfaces are shared by both frontend instances. – dfche Aug 17 '17 at 08:54
12

Another approach that has been introduced in release 2.26.0 (mid december 2015) is to build your own modules, see documentation.

Later on in release 5.0.0 (mid 2018), JHipster has introduced a more powerful tool: blueprints, although it requires more effort than creating a module. With a blueprint, you can even replace the language/framework of the generated project, it has been successfully used for Kotlin, NodeJS and VueJS.

Gaël Marziou
  • 16,028
  • 4
  • 38
  • 49