| Re: [starter-dev] Decision - use cases |
_______________________________________________I vote for A now, and after we are content with it, we can gradually go on to plan B.
Could we also consider adding a default runtime? I think most runtimes have this option that can be run from the maven command; one such example is TomEE.
I would say that it would be more appealing if the developer did not have to launch an IDE or install a runtime in order to run the structure once it had been generated.On Thu, Dec 15, 2022 at 5:28 AM Emily Jiang via starter-dev <starter-dev@xxxxxxxxxxx> wrote:Thank you Reza for pushing this forward! My vote is to start simple and then evolve it. Hence, approach A looks good to get started. I added some comments on Approach B and a minor comment on Approach A in the doc.ThanksEmilyOn Thu, Dec 15, 2022 at 4:23 AM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:_______________________________________________A gentle reminder to kindly weigh in. I would really like to resolve this, record a decision and move forward on Sunday.
Based on input so far, I believe the decision would be to implement approach A first and then evolve towards something like approach B later on.
On 12/11/2022 8:34 PM, Reza Rahman wrote:
As promised, here is my attempt to discuss this decision hopefully in an efficient, asynchronous way. The best way I could think of is an annotated screen mock up: https://docs.google.com/document/d/1ynoX-pZGV8zMYFJhpS7MrbnhcegdmzTijD9f7ZXrO8A/edit?usp=sharing. Hopefully this helps?
What do folks think?
On 12/7/2022 12:31 PM, reza_rahman@xxxxxxxxx wrote:
OK. Let me invest some time in formulating an efficient way we can discuss the details asynchronously. I may not have time to do that until the weekend unfortunately. I do think it’s best to do this to a reasonable extent to avoid needless churn later and allow us to focus on efficient delivery.
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Kito D. Mann <kito.mann@xxxxxxxxxxx>
Sent: Wednesday, December 7, 2022 12:01 PM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Decision - use cases
___
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.
Indeed the idea either way is to “build up” to a cehesive example (basically CRUD being the ceiling). The essential difference between A and B is basically one of granularity (and hence slightly more choices for B). Minimal/without Persistence just means a “hello world” REST endpoint that doesn’t really do anything.
By the choices, I literally mean the choices we want in the UI. Perhaps that’s an easier way to think about the requirements? If easier, I can try to create a quick screen mock-up with an outline of what would be produced for each option?
That could help. I imagine we could still do both without a lot of overhead. For any given starter, we supply the technologies + the use case. That way the user can access the starter either way... So if you pick "Minimal" you can choose which technologies you want to see a Minimal starter for. And vice versa._______________________________________________
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Kito D. Mann <kito.mann@xxxxxxxxxxx>
Sent: Tuesday, December 6, 2022 9:06 PM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Decision - use casesI can meet if necessary, but I agree that we should be able to do this asynchronously. That being said, I don't see A and B as mutually exclusive. For example, if someone chooses REST as a technology, couldn't the example be minimal or a CRUD app?
___
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 Tue, Dec 6, 2022 at 11:50 AM Reza Rahman <reza_rahman@xxxxxxxxx> wrote:
_______________________________________________I think let's wait a couple of days and look to see how we can schedule?
I also think asynchronous is not too hard. If my analysis seems correct enough, it's mostly about choosing one path or the other with any additional commentary needed:
* A: Choices based on mostly use case (and add lesser used use cases/technologies later): REST (minimal), REST CRUD , Web app CRUD
* B: Choices based purely on technology (and add lesser used technologies later): REST/Faces (choose one), JSON/XML (choose one for REST), Persistence, Validation, Test
On 12/6/2022 7:57 AM, Jeyvison Nascimento wrote:
That's fine for me. I think Ivar already sent some schedule options a few weeks ago
Em ter., 6 de dez. de 2022 12:47, Reza Rahman <reza_rahman@xxxxxxxxx> escreveu:
_______________________________________________I think this requires a bit more careful thought, input and discussion before it should be considered resolved. Is a face-to-face meeting with very committed folks the best way to properly resolve this topic so that the code can move forward with sound, documented consensus?
On 12/4/2022 4:05 PM, Reza Rahman wrote:
The votes are close enough such that I would certainly be OK with this approach (so the choices for now would be just minimal, REST CRUD or web app CRUD). It does allow us to leverage the existing work faster while still allowing for future evolution. This may actually also fit the underlying Jakarta EE ethos behind profiles better. What do others think?
The alternative is to try to introduce more granular per-technology choices on top of the existing CRUD/minimal code examples. Taking very basic things like CDI/JSON/transaction handling for granted (that is adding it whenever it makes sense) the choices could be something along these lines:
* REST (make choosing either this or Faces required?)
* Persistence
* Validation
* XML (make it an option instead of JSON?)
* Test
* Faces
For reference that will basically leave out things like the following (personally I think a lot if not all of this is out of scope for something geared towards smoothing out the beginner experience):
* Security
* Messaging
* Batch
* WebSocket
* Concurrency
On 12/4/2022 2:55 PM, Kito D. Mann wrote:
FYI there are already plans to work on Jakarta EE guides and revamp the tutorial, and as Reza mentioned, these are separate efforts from the Starter.
I hadn't seen the Helidon starter, but I took a look at it and I like it a lot, too. I'm tempted to play with it with my son while he's still into Pokemon 🙂
With respect to the use cases, I think we should should do this:
* Finalize the REST CRUD and Minimal use cases* Build scaffolding to easily allow stakeholders for individual specs to create per-technology use cases
And then the first per-technology use-case can be Faces CRUD (assuming there are resources available)/
___
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
_______________________________________________I think there is definitely a separate problem space for guides, the tutorial and examples (as does more of an end-to-end application like Cargo Tracker or Spring’s Pet Clinic) There is a tiny bit of overlap, but really not that much.
I too like the MicroProfile and Helidon starter approach better than the Spring starter approach. I think it’s relatively easily doable here too.
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of A N M Bazlur Rahman <bazlur@xxxxxxxxx>
Sent: Saturday, December 3, 2022 1:08 PM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Decision - use casesHaving examples per technology is a good idea, but Jeyvision mentioned that it would require much effort. That's true, but we now have a lot of contributors, and we can invite more people to join this project.
I like the Helidion starter better than the spring starter. Spring only adds dependencies—no code at all. However, spring has guides, which are also great.
I'm working on creating some guides, but the Helidion approach is way better.
![]()
On Sat, Dec 3, 2022 at 9:57 AM Jeyvison Nascimento <jeynoronha@xxxxxxxxx> wrote:
I still think we should have examples per technology but I understand that maybe it's better if it's a long-term goal since it will require a lot of effort.
I don't know how much cargo track uses the Jakarta technologies but if it has a good coverage of examples it may be a good first step.
Of course, things can run in parallel but if we're going for the per technology option we have to discuss if the examples will be independent , for example, or if the technology is just another layer in one single general example.
Em sex., 2 de dez. de 2022 às 00:49, Reza Rahman <reza_rahman@xxxxxxxxx> escreveu:
_______________________________________________As I had suspected, the decision on this particular topic is not straightforward. I have tried to tentatively summarize and tabulate the input (cell 4Q): https://docs.google.com/spreadsheets/d/1bthiYVjX_UK7Xp2qQmq93awPwVhVCDnprGdzeMtv_ow/edit?usp=sharing. I have not recorded anything in GitHub as I believe it is best to discuss a bit more.
A possible reasonable summary is that we should implement a minimal option as a "floor", and add options per technology (most likely including things like tests as an option too) with REST CRUD and/or web app CRUD (Faces) being the "ceiling" for now. Do folks think that's a reasonable way to proceed for now?
For full context here is a complete breakdown of collated input:
* Per technology - 9
* REST CRUD - 9
* Minimal - 8
* Web app CRUD (Faces) - 3
* JUnit tests - 2
* Integration tests - 2
* Allow addition of Archetypes external to project - 1
* Cargo Tracker - 1
* _javascript_ interface - 1
On 11/13/2022 4:13 PM, Reza Rahman wrote:
The recently committed Archetypes include a minimal "hello world" rest endpoint code example.
The prior direction some of the committers had been pursuing is to include two use cases the user can choose from - a minimal "hello world" rest endpoint as well as a REST CRUD code example. The REST CRUD code example makes use of an embedded database as well as a working JUnit test. The corresponding minimal Archetype is here: https://github.com/eclipse-ee4j/starter/tree/master/minimal-starter. The REST CRUD Archetype is here: https://github.com/eclipse-ee4j/starter/tree/master/rest-starter. A web app CRUD example using Faces had been in planning as a low priority. It can be noted that this is somewhat in line with the approach for the MicroProfile Starter.
Another possibility discussed early on but not pursued currently by any current committers is dynamically including examples in the generated code such as for security, batch, mail, WebSocket, etc. Yet another possibility is including Cargo Tracker in the Starter. It is worth noting that Cargo Tracker currently supports Payara with no short term committed plan or resources to support other runtimes.
On 11/13/2022 2:58 PM, Reza Rahman wrote:
As promised, I read through all the messages carefully and attempted to tabulate the decision record so far: https://docs.google.com/spreadsheets/d/1bthiYVjX_UK7Xp2qQmq93awPwVhVCDnprGdzeMtv_ow/edit?usp=sharing. Could everyone here kindly take a look and make sure I got it right? It would also be very helpful to fill in any gaps with your viewpoints (the entire sheet is editable).
I will now try to start separate threads on the distinct decision points so we can hopefully better structure the discussion, capture input for more traceable archival and achieve reasonable decision outcomes easier. I'll also outline the rationale for my own viewpoints separately.
On 11/12/2022 9:16 AM, reza_rahman@xxxxxxxxx wrote:
I am very grateful responsible folks from the community as well as current committers have taken the time to help us agree on directions. I believe more views from more folks will be forthcoming soon.
I think it will help to see where consensus is if I broke out each key question/decision into a separate thread. For each decision point, I will read each message carefully and include a tentative vote per decision/person that I will record and keep updated in a Google Sheet. Please do help me make sure I get it right.
I will also include my own views at this point. I think that may also help set additional context for folks that have not been very intimately involved in all the project activities so far.
From: starter-dev <starter-dev-bounces@xxxxxxxxxxx> on behalf of Jeyvison Nascimento <jeynoronha@xxxxxxxxx>
Sent: Saturday, November 12, 2022 7:39 AM
To: starter developer discussions <starter-dev@xxxxxxxxxxx>
Subject: Re: [starter-dev] Some updates on the progress made latelyWhile it's good to have a minimum archetype so we have a project bootstrapped and ready to be used, if wanna new developers to learn and understand how things are used, one of our goals has to be provide project with usage examples(for transactions, JPA, etc...) or else it will become a generator for people that already knows Jakarta EE and i think that's not the original proposition for this project.Wow, being here from the beginning i can say that is really awesome to see so many people involved on this =DI think the approach based on maven archetypes was a good way to get things going but I feel like this is something too much related to the Jakarta EE community. If we wanna reach other developers we should try to make things easier(or more build-tool agnostic).
The CLI could be a good addition but I don't see it as a MUST for now. I agree with Ondro that we should have a GUI to download the ZIP file and I submitted a proposal for that some time ago. I'll attach it here.
In summary: I agree we should have more examples with different apis, not just the minimum, and we should decouple the project generation from the maven archetype, hiding it behind a GUI.
In the future we can have Gradle as an option too, but I think these both above items will already require a lot of us.
Em sáb., 12 de nov. de 2022 às 07:02, Ivo Woltring <ivo@xxxxxxxxx> escreveu:
Like Bazlur I am very happy to be part of the community now. Forgot to mention that in the heat of the discussion :-)_______________________________________________
I also work a lot with junior developers. One of the first things they learn is how to work with maven as it is the most important build framework out there. Generating a project from the commandline with maven should not be a big problem for most. I do not see the added benefit if generating a zip first and making that the download. The only thing I can think of is that the user does not yet have maven installed. Hmm maybe it is a good idea :lol:Ondro I am interested in looking at that code of yours too :-)
Complete example projects are very useful. They teach a wow and the correct way. ButMaven archetypes ar not meant to generate complete example projects but working skeletons so you can add your own functionally easily. Copy and pasting a project to strip it down defeats the whole purpose I think.
I think that heaving complete examples is a great idea and they should be made, but in tutorial fashion like the spring guides. Not as part of an archetype. I don’t know if generating a zip in this case is necessary as it can just be a git project or many git projects.
I like the idea of a Cli. Kinda like ng does.Not only to generate a base but maybe even add e.g. a controller or somesuch.
I really like the basic starter as we have it now and I think a barebones starters should always be available because that is how I mostly start and that is a very good reason hehe
Ivo.
On 12 Nov 2022, at 07:21, Ondro Mihályi <mihalyi@xxxxxxxxxxx> wrote:
Hi, all,
It's great to see so much activity on the Starter project.
I like the approach the Starter project did initially, to get things started and simple - just generate a maven command line to execute. It was at the time when the Started project didn't have many contributors. And using maven archetypes is a good starting point.
But my vision for Starter resonates with other ideas mentioned in this thread:
- It would be good to provide an option to download a ZIP file generated from the archetype
- Provide example projects, or even make it possible to generate an example project by selecting the components that users are interested in (e.g. they select REST and CDI, and the generated project would create a REST service with a bean injected to it beans.xml file, and a corresponding README that describes how to build it and how the components are wired)
On top of that, I'd like to see a REST endpoint in Starter, so that ZIP file or Maven command line can be generated with a script or REST client that connects to the endpoint. This would allow writing a Starter CLI or IDE plugins, which would use the Starter webapp as the backend.
A few years ago, I started writing a Java app, that generates a ZIP file from any Maven archetype and I think it would nicely fit what is already in the Starter webapp. I'll check what's the state of this app and will try to contribute it to the Starter, so that we can generate ZIP files for download based on the archetypes.
Ondro
_______________________________________________On Sat, Nov 12, 2022 at 3:11 AM A N M Bazlur Rahman <bazlur@xxxxxxxxx> wrote:
_______________________________________________Hello everyone,
I am thrilled to be a part of this initiative and grateful to everyone who nominated/voted for me to be a committer.
I love what you have all said so far. I don’t necessarily disagree with any of Ivar’s points, but let me share my thoughts about it.
I work with junior developers so that I can see things from their perspective. We're all experienced developers here, so we don't have any trouble understanding and working through a low level of complexity. Everyone here knows the maven archetype like the back of their hand. But if we want to get new or less experienced developers to try out the Jakarta EE spec, I think it's a good way to stop them. There are already a lot of good alternatives that are pretty easy to use. One example is the spring boot starter. I can go to the website, download the project, and try it out even though I don't know anything about it.
If you already know about Maven and the Maven archetype, I don't think you need this starter project. You can use GitHub to find a sample project and start working on it.
From this point of view, I think the second option Ivar mentioned in the email is the best one.
So, essentially what I'm saying is:–
Let's make a website where we hide all the archetype stuff and let the user download a fully working sample along with a convenient runtime. The idea is that the user will download and run the sample, then hit the browser.
Since this is one of the major open-source projects I’m contributing to, I can assure my commitment.
Thank you,
-Bazlur
![]()
On Fri, Nov 11, 2022 at 11:49 AM Ralph Soika <ralph.soika@xxxxxxxxx> wrote:
_______________________________________________Hi all,
I followed this project and the discussion in the last view weeks. I also agree that this idea of a starter page is really great. And it's important to give new developers (who haven't been using Java EE for the last 10 years) a starting point.
For us here, everything that is on the starter page is completely clear and the "The Jakarta® EE Tutorial" explains the rest. But what I observe is that many new developers have absolutely no patience anymore. So I think it would be good to offer not only a selection of platforms, but also a small selection of minimalist project templates. For example, a simple RestAPI example with a Swagger UI or a minimal JPA example. Some time ago I had assembled something like this for a customer in a draft version including a Dockerfile to provide a simple start with a default runtime:
https://github.com/rsoika/ralphs-microservices
The goal was to show that Jakarta EE brings a lot of additional functionality if you combine it for example with Eclipse Microprofile. I don't know what you think about a Dockerfiles with a Wildfly or Payara Runtime? Or whether you consider Eclipse Microprofiles to be overloaded here?But I think that at least we should somehow give the profile/template selection a dynamically reloaded README.md file that explains a bit what the template consists of. It may be enough to point the developer to the corresponding sections in the "The Jakarta® EE Tutorial"
For example:This example contains a Rest Service called '/hello' which is defined in the class RestResource. You can add additional GET, POST and DELETE resources. Find out more about the Jakarta EE Rest API here.
If you want to load or store your data from a Database you can use the Jakarat EE Persistence API.
I know you think this is idiotic, but for many new developers these very simple hints are important to survive the first half hour ;-)
===
RalphAm 11.11.22 um 08:22 schrieb Ivar Grimstad:
Greetings Committers and Contributors,
I am super excited to see the starter project moving forward after a little standstill. There has been some great progress made lately! New contributors and committers are on board. We now have a simple UI available at https://start.jakarta.ee that generates a simple project for Jakarta EE 8, Jakarta EE 9.1, and Jakarta EE 10. The feedback I have received from the community when demoing it has been 100% positive.
The UI uses bare-minimum archetypes to generate the code. The next steps would be to add support for runtimes and possibly explore creating a CLI as an alternative to the Web UI.
In addition to the UI, there are also several archetypes that generate more extensive examples being worked on. Since everything is based on archetypes, adding these and potentially other archetypes created by the community should be fairly straightforward.
The archetypes for EE 8, 9.1, and 10 could be mashed together as one with the conditional logic inside the archetype. I am not sure if this is the right thing to do, though.Keep in mind that as we go forward with EE 11, 12, 13, ... the older versions won't need much attention. Sometimes, a little duplication is favorable over adding another branch in the logic (even if it is just another if-statement...).
The option of creating a server-based solution to generate the starter projects is still an option if someone wants to pursue this. It is always good to have options.Personally, I think the approach to base the starter on archetypes is a better and more flexible way to go. The only server needed is Maven Central, and that is already there and not our problem to maintain. And it provides the option for developers to consume the archetypes directly, via our UI, potentially a CLI, or directly in IDEs.
Ivar--
Ivar Grimstad
Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.
_______________________________________________ starter-dev mailing list starter-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev--
Imixs Software Solutions GmbH
Web: www.imixs.com Phone: +49 (0)89-452136 16
Timezone: Europe/Berlin - CET/CEST
Office: Agnes-Pockels-Bogen 1, 80992 München
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsführer: Gaby Heinle u. Ralph SoikaImixs is an open source company, read more: www.imixs.org
starter-dev mailing list
starter-dev@eclipseorg
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@eclipseorg
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@eclipseorg
To unsubscribe from this list, visit https://deveclipse.org/mailman/listinfo/starter-dev
--
Jeyvison Nascimento
_______________________________________________ starter-dev mailing list starter-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@eclipseorg
To unsubscribe from this list, visit https://dev.eclipseorg/mailman/listinfo/starter-dev
--
_______________________________________________Jeyvison Nascimento
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
_______________________________________________ starter-dev mailing list starter-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
_______________________________________________ starter-dev mailing list starter-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://deveclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
--_______________________________________________Thanks
Emily
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev
starter-dev mailing list
starter-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/starter-dev