| Re: [starter-dev] App Service JBoss EAP for Hosting |
+1Ondro MihalyiDirector, Jakarta EE expertOmniFish - Jakarta EE Consulting & Support | www.omnifish.eeOmnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932On Tue, Nov 29, 2022 at 4:17 PM Kito D. Mann <kito.mann@xxxxxxxxxxx> wrote:+1 for me___Expert training and consulting: Cloud architecture, Java/Jakarta EE, Web Components, Angular* Enterprise development, front and back. Listen to Stackd Podcast.* Speak at conferences? Check out SpeakerTrax.On Mon, Nov 28, 2022 at 10:32 PM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:I am once again resurfacing this thread as it is related to the Faces discussion. Although it has taken me some time/effort to actually formalize permanent hosting, it is done now. Please let me know if we can move forward with this. If not, we need to figure out alternatives (though from my Cargo Tracker experience, better arrangements are hard to come by).
If we do the development and deployment as I suggest below, only the Eclipse Foundation admins need to know the Azure credentials and can set it up as GitHub secrets.
On 5/20/2022 4:52 PM, Reza Rahman wrote:
An important update on the back-end!
I talked with Ivar offline and we agreed the best hosting option is just to get a cloud sponsor (that's what I did for Cargo Tracker: https://github.com/eclipse-ee4j/cargotracker#cloud-demo). Fortunately, I got sponsorship from the JBoss EAP on App Service (https://azure.microsoft.com/en-us/blog/deploy-apps-seamlessly-with-red-hat-jboss-eap-on-azure-app-service-now-generally-available/) team. This means we can count on free JBoss EAP PaaS hosting on App Service (even if the usage for the starter is very high). What the team asks in exchange is a small linked image towards the bottom of the starter page that says something like "Powered by JBoss EAP on App Service". I hope that is OK.
We can use JAX-RS instead of just Servlet - significantly simplifying the code (https://mkyong.com/webservices/jax-rs/download-text-file-from-jax-rs/). We can also easily use something like @Schedule for file cleanup tasks, etc. The deployment can happen via Maven and GitHub Actions (again - what I do for Cargo Tracker): https://docs.microsoft.com/en-us/azure/app-service/quickstart-java?tabs=jbosseap&pivots=platform-linux.
For JUnit/TestContainers/Arquillian/local dev, we can just use WildFly. It has both suitable Docker images (https://quay.io/repository/wildfly/wildfly) and Arquillian connectors.
Let me know and I am happy to help with any of this. Expect the hosting account details some time next week.
On 5/6/2022 12:28 PM, Reza Rahman wrote:
Changing the subject line to try to decouple the conversation a bit.
Yes, I am suggesting running the Archetypes behind the scenes on the server side and simply doing a zip download. This also allows us to easily support Gradle by doing a Maven to Gradle conversion behind the scenes (https://www.baeldung.com/maven-convert-to-gradle). Bazlur believes this is pretty easy to do.
One key discussion is what back-end technology the Eclipse Foundation can easily support. One of the project committers or the lead (Ivar) will need to ask the Eclipse Foundation IT staff I believe.
I haven't done the full research on this yet, but I think you can use something like the Maven Invoker: https://maven.apache.org/shared/maven-invoker/ if the back-end is Java.
On 5/6/22 9:59 AM, Ivo Woltring wrote:
Hi all,
@Reza I actually think that seasoned devs will absolutely use the archetype if it is simple enough. That is the only reason I wrote mine. I use them all the time. I would actually say that junior programmers tend to copy and paste other projects to get a new one and seasoned programmers use archetypes. That is actually one of the reasons I am opposed to having too much in there.
Am I correct in understanding that we want to run the archetypes on a server and present a zip as download? I think that I am missing part of the conversation here?!
Have a nice weekend.Ivo.
On 6 May 2022, at 05:03, reza_rahman@xxxxxxxxx wrote:
To be honest, I am going to be very pleasantly surprised if any seasoned developers use the starter. My guess is that is where Ivo’s minimal template is most applicable. I kind of suspect the primary audience for the starter is newcomers or people evaluating Jakarta EE. That’s for who generating a good working example showcasing the basics really shines (that’s who gives the most glowing feedback for the Azure Functions Archetype).
100% agree it’s super important for the UI experience to be as beginner friendly as possible for the same reasons, so downloading a zip is the way to go.
Also 100% agree with regards to mvnw. I’ll add that in the next PR as an option.
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of A N M Bazlur Rahman <bazlur@xxxxxxxxx>
Sent: Thursday, May 5, 2022 8:20 PM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Starter archetypes / GUI / Issue #67I’m curious about one thing: who is our target audience for this starter project?
- Seasoned JavaEE developers/Spring developers
- Java developers with a few years of experience but who didn’t work with Jakarta EE
- Absolute Java beginner
By the way, for the absolute beginners, whatever we do, this is going to be difficult. They would even have difficulties understanding how maven works. In that case, UI is a kind of a must. And the UI has to provide downloadable zip I, in fact, work with junior developers, and over the year, I have found that, if something goes a bit difficult at the beginning, the motivation immediately goes negative, and they would want to try something else.
One more thing, can we also consider adding the Maven wrapper (mvnw)? That way, the developers don't even have to download the maven. If someone wants to just try out quickly, s/he doesn't have to go through the maven installation process.
Thanks.
![]()
On Thu, May 5, 2022 at 5:03 PM Jeyvison Nascimento <jeynoronha@xxxxxxxxx> wrote:
Oops, I completely forgot the end of the week was tomorrow. Then I'll try to have it finished by the weekend :)
Great. I’ll wait until tomorrow for any further input. Then I’ll start the merging process at the Archetype level.
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Ivo Woltring <ivo@xxxxxxxxx>He Reza,
Sent: Thursday, May 5, 2022 10:45 AM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Starter archetypes / GUI / Issue #67
Thanks for the tips!
Today I’ve:
- Updated my GUI (https://ivonet.github.io/archetype/) to EPLv2- Updated the most recent archetype (https://github.com/IvoNet/jakartaee9-payara-microprofile-archetype) to EPLv2 and did some small updates- Updated my blog (https://www.ivonet.nl/2022/05/05/javaee---jakarta-ee-initializr/) so that it will also be posted on https://jakartablogs.ee/ shortly.
A start has been made :-)
Have a nice evening.
Kind regards,
Ivo@ivonet
On 4 May 2022, at 23:40, Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
This is great. We should wait a tiny bit and unless there are objections from anyone else I suggest the following course of action, roughly in order.
* Could you kindly change all your potentially donated code to EPL: https://github.com/eclipse-ee4j/starter/blob/master/LICENSE? I believe this ensures basically no legal trouble. Please let us know when that is done?
* Since bringing in the minimal Archetype will involve some work, I suggest the most efficient way to get it done is for me to simply work on a PR. It will involve addressing the gaps I noted, adding support for multiple target runtimes as well as introducing Maven modules. I think I can easily do this by the end of this weekend. You and others can review the PR.
* As you are aware, Jeyvison has already started working on Jakarta EE 9 support. I think it's best to wait a bit for him to properly finish that work. So I will just stick to Jakarta EE 8 runtimes for my merge effort. Done the right way, adding Jakarta EE 9/10 support should be quite trivial.
* I think Ivo, it would be great if you could start the UI effort in parallel. I won't attempt to pull in the UI that is there now. I suggest starting a fresh thread on the UI (this one I think is already a bit convoluted). The first decision is actually choosing the backend technology. Ivar and the Eclipse Foundation should help guide us with that. The basic experience should be allowing the user to choose some high level functional parameters and letting them download a zip file that is ready to go I think. Whether we like it or not, Spring/Quarkus/MicroProfile starters are probably our baseline target experience to a large extent. That said, let's kindly discuss on a separate thread and hopefully others will also chime in with regards to the right direction.
P.S.: * I think we all can agree the MicroProfile/Jakarta EE situation is very unfortunate. Unless you have already done so, I suggest sharing your viewpoints here: https://accounts.eclipse.org/mailing-list/cn4j-alliance. I advise keeping modest expectations. Change in the "right direction" has been incredibly slow.
* If best practices, clean code and architecture is your passion, have you considered Eclipse Cargo Tracker: https://eclipse-ee4j.github.io/cargotracker/?
On 5/4/22 3:54 PM, Ivo Woltring wrote:
Hi Reza, Edwin, et all,
It is a darn shame that JakartaEE and Microprofile are still not together (just my humble opinion). The fact is that both are incomplete without the other. In my archetypes I have put them together because I think they should be. Having said that I completely understand that it may not be politically advisable at this time to combine them. The trouble is that Runtimes like Payara just give them to you even if you do not define them. As long as they are separate but open source projects they should be usable right? Spring uses every kind of dependency they need. Why shouldn’t we? But this discussion should not keep us from coming together and make something nice :-)
@Reza I agree with almost all your points on my code. It is clear that you took a good look at them :-)I tent to document my work with actually usable things. That is the reason behind the bash scripts. If something is a command why not make it executable? It brings its own form of documentation.I have indeed never integrated my code with github actions. I have never had the time te really dive into the actions and it is till on my todo list and some of my archetypes are from before github actions were launched :-). I will bump it up on my priority list.
I most certainly agree that most of the code should work on its own without docker. I am a docker fan and I made the archetypes in essence for myself… so docker is a logical choice for me. I hate installing software if I do not have to :-)
The license issue is IMHO solved easily right? I’ll just change them. I have that right or don’t I as the sole committer on my projects?
@Edwin I like your summary. And yes the state of my archetypes represent the need I had at the time. They are actually a very minor effort on my part, but as I have some users I feel obliged to update the archetype(s) now and again even if I am not actively working on or with them at this time. This is my main drive to start this discussion and hope to find a way to work together.
@Reza do you have an idea on what I can do to prepare for a more easy merge? I have no ego as far as my archetypes are concerned, we can do nothing, anything or everything to them as far as I am concerned. My ego emerges only on discussions pertaining clean code and best practices and the like 😄.
Is there a clear idea on what the UI needs to do?- will we be working with archetypes the user needs to run themselves or generate a zip like Spring does?- do we actually want the same thing as spring does?
Kind regards,Ivo.
On 4 May 2022, at 16:20, Edwin Derks <ederks85@xxxxxxxxx> wrote:
Hi Reza and all,
I have caught up with this thread but haven't found time to look at the code myself - yet. Though I would like to respond to your comments.
I think your summary/analysis is very sound and feel that I would make the same conclusions when diving into the project. After all, I know where the project came from so I have a bit of background knowledge. What I would like to say is that you are right that we need to fix some issues regarding the Jakarta EE/MicroProfile alignment, Maven and Docker relation and or dependencies in the project. The fact that the project is in a certain state and does or doesn't contain some features, is because it came from Ivo's mind to experiment with the full stack. It's not impossible to decouple things if effort is put into this, and Ivo agrees with this of course.
Please correct me if I'm wrong but I hope this project forms a solid base for starter efforts to come.
Kind regards,
Edwin
One additional detail to add - if we all agree the UI experience is not centered on surfacing the use of Archetypes that the user then needs to manually invoke themselves but should be more like what the Spring/Quarkus/MicroProfil/etc starter experience looks like, we still need to sort through what the backend technology for the UI will be. I suggest going with whatever is most easily provided by the Eclipse Foundation. Invoking an Archetype behind the scenes can be done with anything that can make a command line invocation on the server-side (could even be node.js if we want to stick to JS on the server-side too).
From: reza_rahman@xxxxxxxxx <reza_rahman@xxxxxxxxx>
Sent: Tuesday, May 3, 2022 10:54 PM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Starter archetypes / GUI / Issue #67As promised, I took some time to carefully take a look at Ivo’s work. I am sharing my thoughts on it. I hope other folks here also do a bit of analysis and chime in with their thoughts so we can move forward to deliver value for the community.
- I think the clearest alignment is with regards to bringing in the UI. I think the current UI code exposes too much of the underlying Archetypes. I think from a UI perspective, the fact that Archetypes are used under the hood at all are an implementation detail. The user should mostly be concerned with higher level functional parameters such as the generation use case (e.g. minimal/REST CRUD/JSF CRUD/etc), Jakarta EE version, target runtime, generated artifact metadata and so on. This is after all the experience for the Spring initializer, etc. However, overall I think these are minor deltas and UI code looks fairly sound.
- The code is definitely focused on minimal generation, just with a simple POM, Jakarta EE deployment descriptors and a very simple hello world REST endpoint. I don’t think it does any real harm to add this option to the starter here. Overall, the amount of additional code would be very small (perhaps in the order of a few hundred lines). I do think the nature of the generated code is different enough to warrant *one* separate Archetype with a robust post processing script that handles minor variants like target runtime and Jakarta EE version.
- The examples mix and match MicroProfile and Jakarta EE. Given the ongoing Jakarta EE and MicroProfile alignment conversations, I think we need to tread carefully here and maybe even ask for advise from the Jakarta EE steering committee/platform specification. For one, it makes the situation odd for runtimes like GlassFish. My inclination is to stick to vanilla Jakarta EE in this starter for now and just stay out of a potentially contentious conversation.
- The code makes no effort in trying to use Maven plugins to have a self-contained runtime experience right from Maven (e.g. mvn clean package tomee:run). Honestly I believe this is a mistake. With embedded runtimes like Spring Boot, Quarkus, etc developers expect to run/test applications right from Maven. I think even in a minimal starter project, having this is important in order to position Jakarta EE as something modern. This is what we have in the starter already for reference.
- The code really is quite dependent on Docker, going as far as making an assumption that users must have a Docker Hub account. Honestly I think this too is a usability mistake. Many developers are still very new to containers so needlessly aligning too much with Docker is a potential usability hazard that I don’t think we really need to get into. It should be mostly possible to use the starter without Docker at all and still have easily running code.
- The code has a number of scripts that abstract over relatively simple Docker commands. This can actually lead to the impression that using Jakarta EE with Docker is so difficult that you need scripts to deal with the complexity. I suggest we simply generate a Dockerfile and document the few relatively simple commands to build a Docker image that contains the Jakarta EE application and run the Docker image. This is what we have now for reference.
- The code does not utilize GitHub Actions or any other kind of automated sanity checks/tests. I think we absolutely need that for a distributed project with many potential contributors.
- There is no index page and the documentation is quite minimal. Since we have quite a bit more visibility as an official Jakarta EE umbrella project, we will obviously need to improve that.
If this all seems reasonable to most folks here, I am happy to begin working on a PR to basically merge the efforts (I may need a tiny bit of help with the UI as I am not that proficient with JS yet). I think this is small enough to just be a few evenings’ effort. I could get it done by the end of the weekend so we can keep focusing on forward progress delivering more releases.
From: reza_rahman@xxxxxxxxx <reza_rahman@xxxxxxxxx>
Sent: Tuesday, May 3, 2022 8:50 AM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Starter archetypes / GUI / Issue #67Unfortunately with the popularity of the Spring initializer, I am afraid we have no choice but to have a UI. I do believe at least initially we need to focus on a simple UI. Certainly trying to present a “components” view of Jakarta EE is something we should prioritize lower at this time. I think it’s best to just evolve features including the UI over time. Part of the reason the project was stuck for so long is a lot of analysis paralysis around requirements and the UI. I think we should remain in a different gear now and focus a bit more on delivering working releases, even if incremental.
I do have to say that personally I believe a command line is all you need because the array of options indeed could be quite small. That’s why I would prefer we kept a mindset of being somewhat agnostic of a UI. Luckily as a side effect the IDE experience also remains nice as most IDEs have pretty good support for Maven Archetypes. It’s fairy easy to support all three pathways equally without too much work.
With regards to Gradle, I spoke with Bazlur and we feel we could easily do this without too much hassle using Maven to Gradle converters behind the scenes. The plan was to look at this once we have delivered a few more solid releases.
I should add that I am not necessarily totally against having a more minimal project generation option. What I am having trouble visualizing is what exact content is worth putting into a minimal option. Just a pom does not feel like it’s worth the effort because of the nature of Jakarta EE. Perhaps looking at what Ivo has might help. I will try to do