Contributions to JHipster / JHipster Online by Microsoft

[Julien Dubois]

Hey everyone,

On the Microsoft side we're moving on doing a specific JHipster version for Azure.

I would like here to summarize what we would do, to have your feedback AND your agreement as this would impact JHipster Online (or not!).

Here's the idea:

- We do a specific blueprint for JHipster that has some specific Azure support (our libraries, specific connection Strings to databases, etc). Alternative option: this could be an update of the existing sub-generator, which is deprecated and could be maintained again. I'm expecting this to be quite light.

- We update JHipster Online for this specific Azure support. I want this to be in the main branch, and I believe you'll all be OK, as this also involves updating and maintaining everything (like moving the front end from Angular 9 to Angular 14). That's better maintenance for everyone.

Now the tricky part: we'll have one or two specific screens for Azure. For example, instead of having the "Generate application" page, we would have a very similar one but that generates only applications for Azure. Big question: should this be a flag at build time (so you could either build the "generic" JHipster Online or the "Azure" JHipster Online), or should those be 2 different menu items in the existing app (in JHipster Online, you would have 2 menu entries one "Generate Application" and one "Generate Application for Azure". This would be confusing, but the good part is that it kind of endorses JHipster Online, and it would directly linked and used by Microsoft users). I have no idea what is the best, or maybe you have another idea?

- To deploy the generated application to Azure, we would use NubesGen.com, so there will be a specific menu item and back end service that does a REST call to the NubesGen API, and merges the generated files with what JHipster generates.

What do you think?

--

Julien Dubois

Twitter: @juliendubois

[Matt Raible]

I like this idea! 

My only ask is that it’d be similar to the Okta support in that it’s not the default. The current defaults for a JHipster Online app are to download or push to Git AFAIK. 

Also, it’d be nice if this support was implemented in a way so other providers like AWS, GCP, and Digital Ocean could be added. I wouldn’t expect you to do this work, but we should document how someone might go about doing it with Azure as an example.

Cheers,

Matt

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CADNXADF-N%3Dop8Zpi99btf6HJAcBaKQE%2B%3DH1MQ-4CyUwxXvPTqw%40mail.gmail.com.

[Julien Dubois]

Thanks for the feedback.

So, this made me think a lot.

That’s not what my Microsoft colleagues had in mind, but what I would like to push is the following:

- We keep start.jhipster.tech the same, except for some technical improvements (like upgrading Angular to the latest version)

- Each technology (starting with Azure, but there could be more indeed, and that’s the point) only add a menu item on the left (like we have today for CI/CD for example.

- They do whatever they want in the page link to the menu item, but typically they would call a specific sub-generator that adds specific support for them.

That way it’s all cleanly separated.

WDYT?

[Deepu K Sasidharan]

Agree with Matt, we should not look like we are playing favorites

Thanks & Regards,

Deepu

To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/AA2EF34B-01BF-41D2-AF8C-5A52FC41D865%40gmail.com.

[Matt Raible]

This sounds good, but I also think we should document it. Is it possible to write the documentation before you implement it and then iterate on the docs as you go? Putting it in the project’s README is documentation enough for me.

Cheers,

Matt